* Re: [PATCH] Documentation: dmaengine: clean up description of dmatest usage
From: Vinod Koul @ 2019-07-05 6:50 UTC (permalink / raw)
To: Hook, Gary
Cc: dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org
In-Reply-To: <156140130017.28986.2649022716558702933.stgit@taos>
On 24-06-19, 18:35, Hook, Gary wrote:
> Fix the formatting of the multi-channel test usage example. Call out
> the note about parameter ordering and add detail on the settings of
> parameters for the new version of dmatest.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH v2 1/2] Documentation: perf: Update documentation for ThunderX2 PMU uncore driver
From: Ganapatrao Kulkarni @ 2019-07-05 9:12 UTC (permalink / raw)
To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Will.Deacon@arm.com, mark.rutland@arm.com, corbet@lwn.net,
Jayachandran Chandrasekharan Nair, rrichter@marvell.coma,
Jan Glauber, gklkml16@gmail.com
In-Reply-To: <1562317967-16329-1-git-send-email-gkulkarni@marvell.com>
Add documentation for Cavium Coherent Processor Interconnect (CCPI2) PMU.
Signed-off-by: Ganapatrao Kulkarni <gkulkarni@marvell.com>
---
Documentation/perf/thunderx2-pmu.txt | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/Documentation/perf/thunderx2-pmu.txt b/Documentation/perf/thunderx2-pmu.txt
index dffc57143736..01315b3d4ad9 100644
--- a/Documentation/perf/thunderx2-pmu.txt
+++ b/Documentation/perf/thunderx2-pmu.txt
@@ -2,24 +2,26 @@ Cavium ThunderX2 SoC Performance Monitoring Unit (PMU UNCORE)
=============================================================
The ThunderX2 SoC PMU consists of independent, system-wide, per-socket
-PMUs such as the Level 3 Cache (L3C) and DDR4 Memory Controller (DMC).
+PMUs such as the Level 3 Cache (L3C), DDR4 Memory Controller (DMC) and
+Cavium Coherent Processor Interconnect (CCPI2).
The DMC has 8 interleaved channels and the L3C has 16 interleaved tiles.
Events are counted for the default channel (i.e. channel 0) and prorated
to the total number of channels/tiles.
-The DMC and L3C support up to 4 counters. Counters are independently
-programmable and can be started and stopped individually. Each counter
-can be set to a different event. Counters are 32-bit and do not support
-an overflow interrupt; they are read every 2 seconds.
+The DMC and L3C support up to 4 counters, while the CCPI2 supports up to 8
+counters. Counters are independently programmable to different events and
+can be started and stopped individually. None of the counters support an
+overflow interrupt. DMC and L3C counters are 32-bit and read every 2 seconds.
+The CCPI2 counters are 64-bit and assumed not to overflow in normal operation.
PMU UNCORE (perf) driver:
The thunderx2_pmu driver registers per-socket perf PMUs for the DMC and
-L3C devices. Each PMU can be used to count up to 4 events
-simultaneously. The PMUs provide a description of their available events
-and configuration options under sysfs, see
-/sys/devices/uncore_<l3c_S/dmc_S/>; S is the socket id.
+L3C devices. Each PMU can be used to count up to 4 (DMC/L3C) or up to 8
+(CCPI2) events simultaneously. The PMUs provide a description of their
+available events and configuration options under sysfs, see
+/sys/devices/uncore_<l3c_S/dmc_S/ccpi2_S/>; S is the socket id.
The driver does not support sampling, therefore "perf record" will not
work. Per-task perf sessions are also not supported.
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/2] drivers/perf: Add CCPI2 PMU support in ThunderX2 UNCORE driver.
From: Ganapatrao Kulkarni @ 2019-07-05 9:12 UTC (permalink / raw)
To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Will.Deacon@arm.com, mark.rutland@arm.com, corbet@lwn.net,
Jayachandran Chandrasekharan Nair, rrichter@marvell.coma,
Jan Glauber, gklkml16@gmail.com
In-Reply-To: <1562317967-16329-1-git-send-email-gkulkarni@marvell.com>
CCPI2 is a low-latency high-bandwidth serial interface for connecting
ThunderX2 processors. This patch adds support to capture CCPI2 perf events.
Signed-off-by: Ganapatrao Kulkarni <gkulkarni@marvell.com>
---
drivers/perf/thunderx2_pmu.c | 248 ++++++++++++++++++++++++++++++-----
1 file changed, 214 insertions(+), 34 deletions(-)
diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c
index 43d76c85da56..af5bf35e0f24 100644
--- a/drivers/perf/thunderx2_pmu.c
+++ b/drivers/perf/thunderx2_pmu.c
@@ -17,22 +17,31 @@
*/
#define TX2_PMU_MAX_COUNTERS 4
+
#define TX2_PMU_DMC_CHANNELS 8
#define TX2_PMU_L3_TILES 16
#define TX2_PMU_HRTIMER_INTERVAL (2 * NSEC_PER_SEC)
-#define GET_EVENTID(ev) ((ev->hw.config) & 0x1f)
-#define GET_COUNTERID(ev) ((ev->hw.idx) & 0x3)
+#define GET_EVENTID(ev, mask) ((ev->hw.config) & mask)
+#define GET_COUNTERID(ev, mask) ((ev->hw.idx) & mask)
/* 1 byte per counter(4 counters).
* Event id is encoded in bits [5:1] of a byte,
*/
#define DMC_EVENT_CFG(idx, val) ((val) << (((idx) * 8) + 1))
+/* bits[3:0] to select counters, are indexed from 8 to 15. */
+#define CCPI2_COUNTER_OFFSET 8
+
#define L3C_COUNTER_CTL 0xA8
#define L3C_COUNTER_DATA 0xAC
#define DMC_COUNTER_CTL 0x234
#define DMC_COUNTER_DATA 0x240
+#define CCPI2_PERF_CTL 0x108
+#define CCPI2_COUNTER_CTL 0x10C
+#define CCPI2_COUNTER_SEL 0x12c
+#define CCPI2_COUNTER_DATA_L 0x130
+
/* L3C event IDs */
#define L3_EVENT_READ_REQ 0xD
#define L3_EVENT_WRITEBACK_REQ 0xE
@@ -51,15 +60,23 @@
#define DMC_EVENT_READ_TXNS 0xF
#define DMC_EVENT_MAX 0x10
+#define CCPI2_EVENT_REQ_PKT_SENT 0x3D
+#define CCPI2_EVENT_SNOOP_PKT_SENT 0x65
+#define CCPI2_EVENT_DATA_PKT_SENT 0x105
+#define CCPI2_EVENT_GIC_PKT_SENT 0x12D
+#define CCPI2_EVENT_MAX 0x200
+
enum tx2_uncore_type {
PMU_TYPE_L3C,
PMU_TYPE_DMC,
+ PMU_TYPE_CCPI2,
PMU_TYPE_INVALID,
};
+
/*
- * pmu on each socket has 2 uncore devices(dmc and l3c),
- * each device has 4 counters.
+ * pmu on each socket has 3 uncore devices(dmc, l3ci and ccpi2),
+ * dmc and l3c has 4 counters and ccpi2 8.
*/
struct tx2_uncore_pmu {
struct hlist_node hpnode;
@@ -69,12 +86,14 @@ struct tx2_uncore_pmu {
int node;
int cpu;
u32 max_counters;
+ u32 counters_mask;
u32 prorate_factor;
u32 max_events;
+ u32 events_mask;
u64 hrtimer_interval;
void __iomem *base;
DECLARE_BITMAP(active_counters, TX2_PMU_MAX_COUNTERS);
- struct perf_event *events[TX2_PMU_MAX_COUNTERS];
+ struct perf_event **events;
struct device *dev;
struct hrtimer hrtimer;
const struct attribute_group **attr_groups;
@@ -92,7 +111,21 @@ static inline struct tx2_uncore_pmu *pmu_to_tx2_pmu(struct pmu *pmu)
return container_of(pmu, struct tx2_uncore_pmu, pmu);
}
-PMU_FORMAT_ATTR(event, "config:0-4");
+#define TX2_PMU_FORMAT_ATTR(_var, _name, _format) \
+static ssize_t \
+__tx2_pmu_##_var##_show(struct device *dev, \
+ struct device_attribute *attr, \
+ char *page) \
+{ \
+ BUILD_BUG_ON(sizeof(_format) >= PAGE_SIZE); \
+ return sprintf(page, _format "\n"); \
+} \
+ \
+static struct device_attribute format_attr_##_var = \
+ __ATTR(_name, 0444, __tx2_pmu_##_var##_show, NULL)
+
+TX2_PMU_FORMAT_ATTR(event, event, "config:0-4");
+TX2_PMU_FORMAT_ATTR(event_ccpi2, event, "config:0-9");
static struct attribute *l3c_pmu_format_attrs[] = {
&format_attr_event.attr,
@@ -104,6 +137,11 @@ static struct attribute *dmc_pmu_format_attrs[] = {
NULL,
};
+static struct attribute *ccpi2_pmu_format_attrs[] = {
+ &format_attr_event_ccpi2.attr,
+ NULL,
+};
+
static const struct attribute_group l3c_pmu_format_attr_group = {
.name = "format",
.attrs = l3c_pmu_format_attrs,
@@ -114,6 +152,11 @@ static const struct attribute_group dmc_pmu_format_attr_group = {
.attrs = dmc_pmu_format_attrs,
};
+static const struct attribute_group ccpi2_pmu_format_attr_group = {
+ .name = "format",
+ .attrs = ccpi2_pmu_format_attrs,
+};
+
/*
* sysfs event attributes
*/
@@ -164,6 +207,19 @@ static struct attribute *dmc_pmu_events_attrs[] = {
NULL,
};
+TX2_EVENT_ATTR(req_pktsent, CCPI2_EVENT_REQ_PKT_SENT);
+TX2_EVENT_ATTR(snoop_pktsent, CCPI2_EVENT_SNOOP_PKT_SENT);
+TX2_EVENT_ATTR(data_pktsent, CCPI2_EVENT_DATA_PKT_SENT);
+TX2_EVENT_ATTR(gic_pktsent, CCPI2_EVENT_GIC_PKT_SENT);
+
+static struct attribute *ccpi2_pmu_events_attrs[] = {
+ &tx2_pmu_event_attr_req_pktsent.attr.attr,
+ &tx2_pmu_event_attr_snoop_pktsent.attr.attr,
+ &tx2_pmu_event_attr_data_pktsent.attr.attr,
+ &tx2_pmu_event_attr_gic_pktsent.attr.attr,
+ NULL,
+};
+
static const struct attribute_group l3c_pmu_events_attr_group = {
.name = "events",
.attrs = l3c_pmu_events_attrs,
@@ -174,6 +230,11 @@ static const struct attribute_group dmc_pmu_events_attr_group = {
.attrs = dmc_pmu_events_attrs,
};
+static const struct attribute_group ccpi2_pmu_events_attr_group = {
+ .name = "events",
+ .attrs = ccpi2_pmu_events_attrs,
+};
+
/*
* sysfs cpumask attributes
*/
@@ -213,11 +274,23 @@ static const struct attribute_group *dmc_pmu_attr_groups[] = {
NULL
};
+static const struct attribute_group *ccpi2_pmu_attr_groups[] = {
+ &ccpi2_pmu_format_attr_group,
+ &pmu_cpumask_attr_group,
+ &ccpi2_pmu_events_attr_group,
+ NULL
+};
+
static inline u32 reg_readl(unsigned long addr)
{
return readl((void __iomem *)addr);
}
+static inline u32 reg_readq(unsigned long addr)
+{
+ return readq((void __iomem *)addr);
+}
+
static inline void reg_writel(u32 val, unsigned long addr)
{
writel(val, (void __iomem *)addr);
@@ -245,33 +318,58 @@ static void init_cntr_base_l3c(struct perf_event *event,
struct tx2_uncore_pmu *tx2_pmu)
{
struct hw_perf_event *hwc = &event->hw;
+ u32 cmask;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ cmask = tx2_pmu->counters_mask;
/* counter ctrl/data reg offset at 8 */
hwc->config_base = (unsigned long)tx2_pmu->base
- + L3C_COUNTER_CTL + (8 * GET_COUNTERID(event));
+ + L3C_COUNTER_CTL + (8 * GET_COUNTERID(event, cmask));
hwc->event_base = (unsigned long)tx2_pmu->base
- + L3C_COUNTER_DATA + (8 * GET_COUNTERID(event));
+ + L3C_COUNTER_DATA + (8 * GET_COUNTERID(event, cmask));
}
static void init_cntr_base_dmc(struct perf_event *event,
struct tx2_uncore_pmu *tx2_pmu)
{
struct hw_perf_event *hwc = &event->hw;
+ u32 cmask;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ cmask = tx2_pmu->counters_mask;
hwc->config_base = (unsigned long)tx2_pmu->base
+ DMC_COUNTER_CTL;
/* counter data reg offset at 0xc */
hwc->event_base = (unsigned long)tx2_pmu->base
- + DMC_COUNTER_DATA + (0xc * GET_COUNTERID(event));
+ + DMC_COUNTER_DATA + (0xc * GET_COUNTERID(event, cmask));
+}
+
+static void init_cntr_base_ccpi2(struct perf_event *event,
+ struct tx2_uncore_pmu *tx2_pmu)
+{
+ struct hw_perf_event *hwc = &event->hw;
+ u32 cmask;
+
+ cmask = tx2_pmu->counters_mask;
+
+ hwc->config_base = (unsigned long)tx2_pmu->base
+ + CCPI2_COUNTER_CTL + (4 * GET_COUNTERID(event, cmask));
+ hwc->event_base = (unsigned long)tx2_pmu->base;
}
static void uncore_start_event_l3c(struct perf_event *event, int flags)
{
- u32 val;
+ u32 val, emask;
struct hw_perf_event *hwc = &event->hw;
+ struct tx2_uncore_pmu *tx2_pmu;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ emask = tx2_pmu->events_mask;
/* event id encoded in bits [07:03] */
- val = GET_EVENTID(event) << 3;
+ val = GET_EVENTID(event, emask) << 3;
reg_writel(val, hwc->config_base);
local64_set(&hwc->prev_count, 0);
reg_writel(0, hwc->event_base);
@@ -284,10 +382,17 @@ static inline void uncore_stop_event_l3c(struct perf_event *event)
static void uncore_start_event_dmc(struct perf_event *event, int flags)
{
- u32 val;
+ u32 val, cmask, emask;
struct hw_perf_event *hwc = &event->hw;
- int idx = GET_COUNTERID(event);
- int event_id = GET_EVENTID(event);
+ struct tx2_uncore_pmu *tx2_pmu;
+ int idx, event_id;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ cmask = tx2_pmu->counters_mask;
+ emask = tx2_pmu->events_mask;
+
+ idx = GET_COUNTERID(event, cmask);
+ event_id = GET_EVENTID(event, emask);
/* enable and start counters.
* 8 bits for each counter, bits[05:01] of a counter to set event type.
@@ -302,9 +407,14 @@ static void uncore_start_event_dmc(struct perf_event *event, int flags)
static void uncore_stop_event_dmc(struct perf_event *event)
{
- u32 val;
+ u32 val, cmask;
struct hw_perf_event *hwc = &event->hw;
- int idx = GET_COUNTERID(event);
+ struct tx2_uncore_pmu *tx2_pmu;
+ int idx;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ cmask = tx2_pmu->counters_mask;
+ idx = GET_COUNTERID(event, cmask);
/* clear event type(bits[05:01]) to stop counter */
val = reg_readl(hwc->config_base);
@@ -312,6 +422,31 @@ static void uncore_stop_event_dmc(struct perf_event *event)
reg_writel(val, hwc->config_base);
}
+static void uncore_start_event_ccpi2(struct perf_event *event, int flags)
+{
+ u32 emask;
+ struct hw_perf_event *hwc = &event->hw;
+ struct tx2_uncore_pmu *tx2_pmu;
+
+ tx2_pmu = pmu_to_tx2_pmu(event->pmu);
+ emask = tx2_pmu->events_mask;
+
+ /* Bit [09:00] to set event id, set level and type to 1 */
+ reg_writel((3 << 10) |
+ GET_EVENTID(event, emask), hwc->config_base);
+ /* reset[4], enable[0] and start[1] counters */
+ reg_writel(0x13, hwc->event_base + CCPI2_PERF_CTL);
+ local64_set(&event->hw.prev_count, 0ULL);
+}
+
+static void uncore_stop_event_ccpi2(struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+
+ /* disable and stop counter */
+ reg_writel(0, hwc->event_base + CCPI2_PERF_CTL);
+}
+
static void tx2_uncore_event_update(struct perf_event *event)
{
s64 prev, delta, new = 0;
@@ -319,20 +454,30 @@ static void tx2_uncore_event_update(struct perf_event *event)
struct tx2_uncore_pmu *tx2_pmu;
enum tx2_uncore_type type;
u32 prorate_factor;
+ u32 cmask, emask;
tx2_pmu = pmu_to_tx2_pmu(event->pmu);
type = tx2_pmu->type;
+ cmask = tx2_pmu->counters_mask;
+ emask = tx2_pmu->events_mask;
prorate_factor = tx2_pmu->prorate_factor;
-
- new = reg_readl(hwc->event_base);
- prev = local64_xchg(&hwc->prev_count, new);
-
- /* handles rollover of 32 bit counter */
- delta = (u32)(((1UL << 32) - prev) + new);
+ if (type == PMU_TYPE_CCPI2) {
+ reg_writel(CCPI2_COUNTER_OFFSET +
+ GET_COUNTERID(event, cmask),
+ hwc->event_base + CCPI2_COUNTER_SEL);
+ new = reg_readq(hwc->event_base + CCPI2_COUNTER_DATA_L);
+ prev = local64_xchg(&hwc->prev_count, new);
+ delta = new - prev;
+ } else {
+ new = reg_readl(hwc->event_base);
+ prev = local64_xchg(&hwc->prev_count, new);
+ /* handles rollover of 32 bit counter */
+ delta = (u32)(((1UL << 32) - prev) + new);
+ }
/* DMC event data_transfers granularity is 16 Bytes, convert it to 64 */
if (type == PMU_TYPE_DMC &&
- GET_EVENTID(event) == DMC_EVENT_DATA_TRANSFERS)
+ GET_EVENTID(event, emask) == DMC_EVENT_DATA_TRANSFERS)
delta = delta/4;
/* L3C and DMC has 16 and 8 interleave channels respectively.
@@ -351,6 +496,7 @@ static enum tx2_uncore_type get_tx2_pmu_type(struct acpi_device *adev)
} devices[] = {
{"CAV901D", PMU_TYPE_L3C},
{"CAV901F", PMU_TYPE_DMC},
+ {"CAV901E", PMU_TYPE_CCPI2},
{"", PMU_TYPE_INVALID}
};
@@ -380,7 +526,8 @@ static bool tx2_uncore_validate_event(struct pmu *pmu,
* Make sure the group of events can be scheduled at once
* on the PMU.
*/
-static bool tx2_uncore_validate_event_group(struct perf_event *event)
+static bool tx2_uncore_validate_event_group(struct perf_event *event,
+ int max_counters)
{
struct perf_event *sibling, *leader = event->group_leader;
int counters = 0;
@@ -403,7 +550,7 @@ static bool tx2_uncore_validate_event_group(struct perf_event *event)
* If the group requires more counters than the HW has,
* it cannot ever be scheduled.
*/
- return counters <= TX2_PMU_MAX_COUNTERS;
+ return counters <= max_counters;
}
@@ -439,7 +586,7 @@ static int tx2_uncore_event_init(struct perf_event *event)
hwc->config = event->attr.config;
/* Validate the group */
- if (!tx2_uncore_validate_event_group(event))
+ if (!tx2_uncore_validate_event_group(event, tx2_pmu->max_counters))
return -EINVAL;
return 0;
@@ -456,8 +603,9 @@ static void tx2_uncore_event_start(struct perf_event *event, int flags)
tx2_pmu->start_event(event, flags);
perf_event_update_userpage(event);
- /* Start timer for first event */
- if (bitmap_weight(tx2_pmu->active_counters,
+ /* Start timer for first non ccpi2 event */
+ if (tx2_pmu->type != PMU_TYPE_CCPI2 &&
+ bitmap_weight(tx2_pmu->active_counters,
tx2_pmu->max_counters) == 1) {
hrtimer_start(&tx2_pmu->hrtimer,
ns_to_ktime(tx2_pmu->hrtimer_interval),
@@ -495,7 +643,8 @@ static int tx2_uncore_event_add(struct perf_event *event, int flags)
if (hwc->idx < 0)
return -EAGAIN;
- tx2_pmu->events[hwc->idx] = event;
+ if (tx2_pmu->events)
+ tx2_pmu->events[hwc->idx] = event;
/* set counter control and data registers base address */
tx2_pmu->init_cntr_base(event, tx2_pmu);
@@ -510,14 +659,17 @@ static void tx2_uncore_event_del(struct perf_event *event, int flags)
{
struct tx2_uncore_pmu *tx2_pmu = pmu_to_tx2_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
+ u32 cmask;
+ cmask = tx2_pmu->counters_mask;
tx2_uncore_event_stop(event, PERF_EF_UPDATE);
/* clear the assigned counter */
- free_counter(tx2_pmu, GET_COUNTERID(event));
+ free_counter(tx2_pmu, GET_COUNTERID(event, cmask));
perf_event_update_userpage(event);
- tx2_pmu->events[hwc->idx] = NULL;
+ if (tx2_pmu->events)
+ tx2_pmu->events[hwc->idx] = NULL;
hwc->idx = -1;
}
@@ -580,8 +732,12 @@ static int tx2_uncore_pmu_add_dev(struct tx2_uncore_pmu *tx2_pmu)
cpu_online_mask);
tx2_pmu->cpu = cpu;
- hrtimer_init(&tx2_pmu->hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
- tx2_pmu->hrtimer.function = tx2_hrtimer_callback;
+ /* CCPI2 counters are 64 bit counters, no overflow */
+ if (tx2_pmu->type != PMU_TYPE_CCPI2) {
+ hrtimer_init(&tx2_pmu->hrtimer,
+ CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ tx2_pmu->hrtimer.function = tx2_hrtimer_callback;
+ }
ret = tx2_uncore_pmu_register(tx2_pmu);
if (ret) {
@@ -654,8 +810,10 @@ static struct tx2_uncore_pmu *tx2_uncore_pmu_init_dev(struct device *dev,
switch (tx2_pmu->type) {
case PMU_TYPE_L3C:
tx2_pmu->max_counters = TX2_PMU_MAX_COUNTERS;
+ tx2_pmu->counters_mask = 0x3;
tx2_pmu->prorate_factor = TX2_PMU_L3_TILES;
tx2_pmu->max_events = L3_EVENT_MAX;
+ tx2_pmu->events_mask = 0x1f;
tx2_pmu->hrtimer_interval = TX2_PMU_HRTIMER_INTERVAL;
tx2_pmu->attr_groups = l3c_pmu_attr_groups;
tx2_pmu->name = devm_kasprintf(dev, GFP_KERNEL,
@@ -663,11 +821,15 @@ static struct tx2_uncore_pmu *tx2_uncore_pmu_init_dev(struct device *dev,
tx2_pmu->init_cntr_base = init_cntr_base_l3c;
tx2_pmu->start_event = uncore_start_event_l3c;
tx2_pmu->stop_event = uncore_stop_event_l3c;
+ tx2_pmu->events = devm_kzalloc(dev, tx2_pmu->max_counters *
+ sizeof(*tx2_pmu->events), GFP_KERNEL);
break;
case PMU_TYPE_DMC:
tx2_pmu->max_counters = TX2_PMU_MAX_COUNTERS;
+ tx2_pmu->counters_mask = 0x3;
tx2_pmu->prorate_factor = TX2_PMU_DMC_CHANNELS;
tx2_pmu->max_events = DMC_EVENT_MAX;
+ tx2_pmu->events_mask = 0x1f;
tx2_pmu->hrtimer_interval = TX2_PMU_HRTIMER_INTERVAL;
tx2_pmu->attr_groups = dmc_pmu_attr_groups;
tx2_pmu->name = devm_kasprintf(dev, GFP_KERNEL,
@@ -675,6 +837,23 @@ static struct tx2_uncore_pmu *tx2_uncore_pmu_init_dev(struct device *dev,
tx2_pmu->init_cntr_base = init_cntr_base_dmc;
tx2_pmu->start_event = uncore_start_event_dmc;
tx2_pmu->stop_event = uncore_stop_event_dmc;
+ tx2_pmu->events = devm_kzalloc(dev, tx2_pmu->max_counters *
+ sizeof(*tx2_pmu->events), GFP_KERNEL);
+ break;
+ case PMU_TYPE_CCPI2:
+ /* CCPI2 has 8 counters */
+ tx2_pmu->max_counters = 8;
+ tx2_pmu->counters_mask = 0x7;
+ tx2_pmu->prorate_factor = 1;
+ tx2_pmu->max_events = CCPI2_EVENT_MAX;
+ tx2_pmu->events_mask = 0x1ff;
+ tx2_pmu->attr_groups = ccpi2_pmu_attr_groups;
+ tx2_pmu->name = devm_kasprintf(dev, GFP_KERNEL,
+ "uncore_ccpi2_%d", tx2_pmu->node);
+ tx2_pmu->init_cntr_base = init_cntr_base_ccpi2;
+ tx2_pmu->start_event = uncore_start_event_ccpi2;
+ tx2_pmu->stop_event = uncore_stop_event_ccpi2;
+ tx2_pmu->events = NULL;
break;
case PMU_TYPE_INVALID:
devm_kfree(dev, tx2_pmu);
@@ -744,7 +923,8 @@ static int tx2_uncore_pmu_offline_cpu(unsigned int cpu,
if (cpu != tx2_pmu->cpu)
return 0;
- hrtimer_cancel(&tx2_pmu->hrtimer);
+ if (tx2_pmu->type != PMU_TYPE_CCPI2)
+ hrtimer_cancel(&tx2_pmu->hrtimer);
cpumask_copy(&cpu_online_mask_temp, cpu_online_mask);
cpumask_clear_cpu(cpu, &cpu_online_mask_temp);
new_cpu = cpumask_any_and(
--
2.17.1
^ permalink raw reply related
* [PATCH v2 0/2] Add CCPI2 PMU support
From: Ganapatrao Kulkarni @ 2019-07-05 9:12 UTC (permalink / raw)
To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Will.Deacon@arm.com, mark.rutland@arm.com, corbet@lwn.net,
Jayachandran Chandrasekharan Nair, rrichter@marvell.coma,
Jan Glauber, gklkml16@gmail.com
Add Cavium Coherent Processor Interconnect (CCPI2) PMU
support in ThunderX2 Uncore driver.
v2: Updated with review comments [1]
[1] https://lkml.org/lkml/2019/6/14/965
v1: initial patch
Ganapatrao Kulkarni (2):
Documentation: perf: Update documentation for ThunderX2 PMU uncore
driver
drivers/perf: Add CCPI2 PMU support in ThunderX2 UNCORE driver.
Documentation/perf/thunderx2-pmu.txt | 20 ++-
drivers/perf/thunderx2_pmu.c | 248 +++++++++++++++++++++++----
2 files changed, 225 insertions(+), 43 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH 41/43] docs: extcon: convert it to ReST and move to acpi dir
From: Rafael J. Wysocki @ 2019-07-05 9:41 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, MyungJoo Ham, Chanwoo Choi, Len Brown,
linux-acpi
In-Reply-To: <bce6d8c98a188ec5f0efe78962aa12839c7442e9.1561723980.git.mchehab+samsung@kernel.org>
On Friday, June 28, 2019 2:20:37 PM CEST Mauro Carvalho Chehab wrote:
> The intel-int3496.txt file is a documentation for an ACPI driver.
>
> There's no reason to keep it on a separate directory.
>
> So, instead of keeping it on some random location, move it
> to a sub-directory inside the ACPI documentation dir,
> renaming it to .rst.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> .../acpi/extcon-intel-int3496.rst} | 14 ++++++++++----
> Documentation/firmware-guide/acpi/index.rst | 1 +
> MAINTAINERS | 6 +++---
> 3 files changed, 14 insertions(+), 7 deletions(-)
> rename Documentation/{extcon/intel-int3496.txt => firmware-guide/acpi/extcon-intel-int3496.rst} (66%)
>
> diff --git a/Documentation/extcon/intel-int3496.txt b/Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> similarity index 66%
> rename from Documentation/extcon/intel-int3496.txt
> rename to Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> index 8155dbc7fad3..5137ca834b54 100644
> --- a/Documentation/extcon/intel-int3496.txt
> +++ b/Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> @@ -1,5 +1,6 @@
> +=====================================================
> Intel INT3496 ACPI device extcon driver documentation
> ------------------------------------------------------
> +=====================================================
>
> The Intel INT3496 ACPI device extcon driver is a driver for ACPI
> devices with an acpi-id of INT3496, such as found for example on
> @@ -13,15 +14,20 @@ between an USB host and an USB peripheral controller.
> The ACPI devices exposes this functionality by returning an array with up
> to 3 gpio descriptors from its ACPI _CRS (Current Resource Settings) call:
>
> -Index 0: The input gpio for the id-pin, this is always present and valid
> -Index 1: The output gpio for enabling Vbus output from the device to the otg
> +======= =====================================================================
> +Index 0 The input gpio for the id-pin, this is always present and valid
> +Index 1 The output gpio for enabling Vbus output from the device to the otg
> port, write 1 to enable the Vbus output (this gpio descriptor may
> be absent or invalid)
> -Index 2: The output gpio for muxing of the data pins between the USB host and
> +Index 2 The output gpio for muxing of the data pins between the USB host and
> the USB peripheral controller, write 1 to mux to the peripheral
> controller
> +======= =====================================================================
>
> There is a mapping between indices and GPIO connection IDs as follows
> +
> + ======= =======
> id index 0
> vbus index 1
> mux index 2
> + ======= =======
> diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst
> index ae609eec4679..90c90d42d9ad 100644
> --- a/Documentation/firmware-guide/acpi/index.rst
> +++ b/Documentation/firmware-guide/acpi/index.rst
> @@ -24,3 +24,4 @@ ACPI Support
> acpi-lid
> lpit
> video_extension
> + extcon-intel-int3496
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fd6fab0dec77..2cf8abf6d48e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -321,7 +321,7 @@ F: drivers/pnp/pnpacpi/
> F: include/linux/acpi.h
> F: include/linux/fwnode.h
> F: include/acpi/
> -F: Documentation/acpi/
> +F: Documentation/firmware-guide/acpi/
> F: Documentation/ABI/testing/sysfs-bus-acpi
> F: Documentation/ABI/testing/configfs-acpi
> F: drivers/pci/*acpi*
> @@ -4896,7 +4896,7 @@ S: Maintained
> F: Documentation/
> F: scripts/kernel-doc
> X: Documentation/ABI/
> -X: Documentation/acpi/
> +X: Documentation/firmware-guide/acpi/
> X: Documentation/devicetree/
> X: Documentation/i2c/
> X: Documentation/media/
> @@ -6073,7 +6073,7 @@ S: Maintained
> F: drivers/extcon/
> F: include/linux/extcon/
> F: include/linux/extcon.h
> -F: Documentation/extcon/
> +F: Documentation/firmware-guide/acpi/extcon-intel-int3496.rst
> F: Documentation/devicetree/bindings/extcon/
>
> EXYNOS DP DRIVER
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] tpm: Document UEFI event log quirks
From: Jarkko Sakkinen @ 2019-07-05 10:11 UTC (permalink / raw)
To: linux-kernel, linux-integrity, linux-doc
Cc: tweek, matthewgarrett, Jonathan Corbet
In-Reply-To: <20190703161109.22935-1-jarkko.sakkinen@linux.intel.com>
> +| Authors:
> +| Stefan Berger <stefanb@linux.vnet.ibm.com>
I was looking how the rst formatting went from Stefan's
document. This one is authored by me.
/Jarkko
^ permalink raw reply
* Re: [PATCH] tpm: Document UEFI event log quirks
From: Jarkko Sakkinen @ 2019-07-05 10:15 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel, linux-integrity, linux-doc
Cc: tweek, matthewgarrett, Jonathan Corbet
In-Reply-To: <6acf78df-b168-14d3-fea4-9a9d2945e77f@infradead.org>
On Wed, 2019-07-03 at 09:45 -0700, Randy Dunlap wrote:
> > +This introduces another problem: nothing guarantees that it is not
> > +called before the stub gets to run. Thus, it needs to copy the final
> > +events table preboot size to the custom configuration table so that
> > +kernel offset it later on.
>
> ? kernel can offset it later on.
EFI stub calculates the total size of the events in the final events
table at the time.
Later on, TPM driver uses this offset to copy only the events that
were actually generated after ExitBootServices():
/*
* Copy any of the final events log that didn't also end up in the
* main log. Events can be logged in both if events are generated
* between GetEventLog() and ExitBootServices().
*/
memcpy((void *)log->bios_event_log + log_size,
final_tbl->events + log_tbl->final_events_preboot_size,
efi_tpm_final_log_size);
What would be a better way to describe this?
/Jarkko
^ permalink raw reply
* Re: [PATCH] tpm: Document UEFI event log quirks
From: Jarkko Sakkinen @ 2019-07-05 10:26 UTC (permalink / raw)
To: Jordan Hand, linux-kernel, linux-integrity, linux-doc
Cc: tweek, matthewgarrett, Jonathan Corbet
In-Reply-To: <dacf145d-49e0-16e5-5963-415bab1884e1@linux.microsoft.com>
On Wed, 2019-07-03 at 10:08 -0700, Jordan Hand wrote:
> > +This introduces another problem: nothing guarantees that it is not
> > +called before the stub gets to run. Thus, it needs to copy the final
> > +events table preboot size to the custom configuration table so that
> > +kernel offset it later on.
>
> This doesn't really explain what the size will be used for. Matthew's
> patch description for "tpm: Don't duplicate events from the final event
> log in the TCG2 log" outlines this well. You could maybe word it
> differently but I think the information is necessary:
>
> "We can avoid this problem by looking at the size of the Final Event Log
> just before we call ExitBootServices() and exporting this to the main
> kernel. The kernel can then skip over all events that occured before
> ExitBootServices() and only append events that were not also logged to
> the main log."
Not exactly sure what is missing from my paragraph. The way I see it has
more information as it states what is used at as the vessel for
exportation (the custom configuration table).
Maybe something like:
"Thus, it nees to save the final events table size at the time to the
custom configuration table so that the TPM driver can later on skip the
events generated during the preboot time."
/Jarkko
^ permalink raw reply
* Re: [PATCH 1/3] docs: s390: restore important non-kdoc parts of s390dbf.rst
From: Christian Borntraeger @ 2019-07-05 10:53 UTC (permalink / raw)
To: Steffen Maier, linux-doc
Cc: linux-s390, Mauro Carvalho Chehab, Mauro Carvalho Chehab,
Heiko Carstens, Vasily Gorbik, linux-kernel
In-Reply-To: <1562149189-1417-2-git-send-email-maier@linux.ibm.com>
On 03.07.19 12:19, Steffen Maier wrote:
> Complements previous ("s390: include/asm/debug.h add kerneldoc markups")
> which seemed to have dropped important non-kdoc parts such as
> user space interface (level, size, flush)
> as well as views and caution regarding strings in the sprintf view.
>
> Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> Documentation/s390/s390dbf.rst | 339 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 339 insertions(+)
>
> diff --git a/Documentation/s390/s390dbf.rst b/Documentation/s390/s390dbf.rst
> index d2595b548879..01d66251643d 100644
> --- a/Documentation/s390/s390dbf.rst
> +++ b/Documentation/s390/s390dbf.rst
> @@ -112,6 +112,345 @@ Kernel Interfaces:
> Predefined views:
> -----------------
>
> +extern struct debug_view debug_hex_ascii_view;
> +
> +extern struct debug_view debug_raw_view;
> +
> +extern struct debug_view debug_sprintf_view;
> +
> +Examples
> +--------
> +
> +::
> +
> + /*
> + * hex_ascii- + raw-view Example
> + */
> +
> + #include <linux/init.h>
> + #include <asm/debug.h>
> +
> + static debug_info_t* debug_info;
> +
> + static int init(void)
> + {
> + /* register 4 debug areas with one page each and 4 byte data field */
> +
> + debug_info = debug_register ("test", 1, 4, 4 );
> + debug_register_view(debug_info,&debug_hex_ascii_view);
> + debug_register_view(debug_info,&debug_raw_view);
> +
> + debug_text_event(debug_info, 4 , "one ");
> + debug_int_exception(debug_info, 4, 4711);
> + debug_event(debug_info, 3, &debug_info, 4);
> +
> + return 0;
> + }
> +
> + static void cleanup(void)
> + {
> + debug_unregister (debug_info);
> + }
> +
> + module_init(init);
> + module_exit(cleanup);
> +
> +::
> +
> + /*
> + * sprintf-view Example
> + */
> +
> + #include <linux/init.h>
> + #include <asm/debug.h>
> +
> + static debug_info_t* debug_info;
> +
> + static int init(void)
> + {
> + /* register 4 debug areas with one page each and data field for */
> + /* format string pointer + 2 varargs (= 3 * sizeof(long)) */
> +
> + debug_info = debug_register ("test", 1, 4, sizeof(long) * 3);
> + debug_register_view(debug_info,&debug_sprintf_view);
> +
> + debug_sprintf_event(debug_info, 2 , "first event in %s:%i\n",__FILE__,__LINE__);
> + debug_sprintf_exception(debug_info, 1, "pointer to debug info: %p\n",&debug_info);
> +
> + return 0;
> + }
> +
> + static void cleanup(void)
> + {
> + debug_unregister (debug_info);
> + }
> +
> + module_init(init);
> + module_exit(cleanup);
> +
> +Debugfs Interface
> +-----------------
> +Views to the debug logs can be investigated through reading the corresponding
> +debugfs-files:
> +
> +Example::
> +
> + > ls /sys/kernel/debug/s390dbf/dasd
> + flush hex_ascii level pages raw
> + > cat /sys/kernel/debug/s390dbf/dasd/hex_ascii | sort -k2,2 -s
> + 00 00974733272:680099 2 - 02 0006ad7e 07 ea 4a 90 | ....
> + 00 00974733272:682210 2 - 02 0006ade6 46 52 45 45 | FREE
> + 00 00974733272:682213 2 - 02 0006adf6 07 ea 4a 90 | ....
> + 00 00974733272:682281 1 * 02 0006ab08 41 4c 4c 43 | EXCP
> + 01 00974733272:682284 2 - 02 0006ab16 45 43 4b 44 | ECKD
> + 01 00974733272:682287 2 - 02 0006ab28 00 00 00 04 | ....
> + 01 00974733272:682289 2 - 02 0006ab3e 00 00 00 20 | ...
> + 01 00974733272:682297 2 - 02 0006ad7e 07 ea 4a 90 | ....
> + 01 00974733272:684384 2 - 00 0006ade6 46 52 45 45 | FREE
> + 01 00974733272:684388 2 - 00 0006adf6 07 ea 4a 90 | ....
> +
> +See section about predefined views for explanation of the above output!
> +
> +Changing the debug level
> +------------------------
> +
> +Example::
> +
> +
> + > cat /sys/kernel/debug/s390dbf/dasd/level
> + 3
> + > echo "5" > /sys/kernel/debug/s390dbf/dasd/level
> + > cat /sys/kernel/debug/s390dbf/dasd/level
> + 5
> +
> +Flushing debug areas
> +--------------------
> +Debug areas can be flushed with piping the number of the desired
> +area (0...n) to the debugfs file "flush". When using "-" all debug areas
> +are flushed.
> +
> +Examples:
> +
> +1. Flush debug area 0::
> +
> + > echo "0" > /sys/kernel/debug/s390dbf/dasd/flush
> +
> +2. Flush all debug areas::
> +
> + > echo "-" > /sys/kernel/debug/s390dbf/dasd/flush
> +
> +Changing the size of debug areas
> +------------------------------------
> +It is possible the change the size of debug areas through piping
> +the number of pages to the debugfs file "pages". The resize request will
> +also flush the debug areas.
> +
> +Example:
> +
> +Define 4 pages for the debug areas of debug feature "dasd"::
> +
> + > echo "4" > /sys/kernel/debug/s390dbf/dasd/pages
> +
> +Stooping the debug feature
> +--------------------------
> +Example:
> +
> +1. Check if stopping is allowed::
> +
> + > cat /proc/sys/s390dbf/debug_stoppable
> +
> +2. Stop debug feature::
> +
> + > echo 0 > /proc/sys/s390dbf/debug_active
> +
> +lcrash Interface
> +----------------
> +It is planned that the dump analysis tool lcrash gets an additional command
> +'s390dbf' to display all the debug logs. With this tool it will be possible
> +to investigate the debug logs on a live system and with a memory dump after
> +a system crash.
> +
> +Investigating raw memory
> +------------------------
> +One last possibility to investigate the debug logs at a live
> +system and after a system crash is to look at the raw memory
> +under VM or at the Service Element.
> +It is possible to find the anker of the debug-logs through
> +the 'debug_area_first' symbol in the System map. Then one has
> +to follow the correct pointers of the data-structures defined
> +in debug.h and find the debug-areas in memory.
> +Normally modules which use the debug feature will also have
> +a global variable with the pointer to the debug-logs. Following
> +this pointer it will also be possible to find the debug logs in
> +memory.
> +
> +For this method it is recommended to use '16 * x + 4' byte (x = 0..n)
> +for the length of the data field in debug_register() in
> +order to see the debug entries well formatted.
> +
> +
> +Predefined Views
> +----------------
> +
> +There are three predefined views: hex_ascii, raw and sprintf.
> +The hex_ascii view shows the data field in hex and ascii representation
> +(e.g. '45 43 4b 44 | ECKD').
> +The raw view returns a bytestream as the debug areas are stored in memory.
> +
> +The sprintf view formats the debug entries in the same way as the sprintf
> +function would do. The sprintf event/exception functions write to the
> +debug entry a pointer to the format string (size = sizeof(long))
> +and for each vararg a long value. So e.g. for a debug entry with a format
> +string plus two varargs one would need to allocate a (3 * sizeof(long))
> +byte data area in the debug_register() function.
> +
> +IMPORTANT:
> + Using "%s" in sprintf event functions is dangerous. You can only
> + use "%s" in the sprintf event functions, if the memory for the passed string
> + is available as long as the debug feature exists. The reason behind this is
> + that due to performance considerations only a pointer to the string is stored
> + in the debug feature. If you log a string that is freed afterwards, you will
> + get an OOPS when inspecting the debug feature, because then the debug feature
> + will access the already freed memory.
> +
> +NOTE:
> + If using the sprintf view do NOT use other event/exception functions
> + than the sprintf-event and -exception functions.
> +
> +The format of the hex_ascii and sprintf view is as follows:
> +
> +- Number of area
> +- Timestamp (formatted as seconds and microseconds since 00:00:00 Coordinated
> + Universal Time (UTC), January 1, 1970)
> +- level of debug entry
> +- Exception flag (* = Exception)
> +- Cpu-Number of calling task
> +- Return Address to caller
> +- data field
> +
> +The format of the raw view is:
> +
> +- Header as described in debug.h
> +- datafield
> +
> +A typical line of the hex_ascii view will look like the following (first line
> +is only for explanation and will not be displayed when 'cating' the view):
> +
> +area time level exception cpu caller data (hex + ascii)
> +--------------------------------------------------------------------------
> +00 00964419409:440690 1 - 00 88023fe
> +
> +
> +Defining views
> +--------------
> +
> +Views are specified with the 'debug_view' structure. There are defined
> +callback functions which are used for reading and writing the debugfs files::
> +
> + struct debug_view {
> + char name[DEBUG_MAX_PROCF_LEN];
> + debug_prolog_proc_t* prolog_proc;
> + debug_header_proc_t* header_proc;
> + debug_format_proc_t* format_proc;
> + debug_input_proc_t* input_proc;
> + void* private_data;
> + };
> +
> +where::
> +
> + typedef int (debug_header_proc_t) (debug_info_t* id,
> + struct debug_view* view,
> + int area,
> + debug_entry_t* entry,
> + char* out_buf);
> +
> + typedef int (debug_format_proc_t) (debug_info_t* id,
> + struct debug_view* view, char* out_buf,
> + const char* in_buf);
> + typedef int (debug_prolog_proc_t) (debug_info_t* id,
> + struct debug_view* view,
> + char* out_buf);
> + typedef int (debug_input_proc_t) (debug_info_t* id,
> + struct debug_view* view,
> + struct file* file, const char* user_buf,
> + size_t in_buf_size, loff_t* offset);
> +
> +
> +The "private_data" member can be used as pointer to view specific data.
> +It is not used by the debug feature itself.
> +
> +The output when reading a debugfs file is structured like this::
> +
> + "prolog_proc output"
> +
> + "header_proc output 1" "format_proc output 1"
> + "header_proc output 2" "format_proc output 2"
> + "header_proc output 3" "format_proc output 3"
> + ...
> +
> +When a view is read from the debugfs, the Debug Feature calls the
> +'prolog_proc' once for writing the prolog.
> +Then 'header_proc' and 'format_proc' are called for each
> +existing debug entry.
> +
> +The input_proc can be used to implement functionality when it is written to
> +the view (e.g. like with 'echo "0" > /sys/kernel/debug/s390dbf/dasd/level).
> +
> +For header_proc there can be used the default function
> +debug_dflt_header_fn() which is defined in debug.h.
> +and which produces the same header output as the predefined views.
> +E.g::
> +
> + 00 00964419409:440761 2 - 00 88023ec
> +
> +In order to see how to use the callback functions check the implementation
> +of the default views!
> +
> +Example::
> +
> + #include <asm/debug.h>
> +
> + #define UNKNOWNSTR "data: %08x"
> +
> + const char* messages[] =
> + {"This error...........\n",
> + "That error...........\n",
> + "Problem..............\n",
> + "Something went wrong.\n",
> + "Everything ok........\n",
> + NULL
> + };
> +
> + static int debug_test_format_fn(
> + debug_info_t * id, struct debug_view *view,
> + char *out_buf, const char *in_buf
> + )
> + {
> + int i, rc = 0;
> +
> + if(id->buf_size >= 4) {
> + int msg_nr = *((int*)in_buf);
> + if(msg_nr < sizeof(messages)/sizeof(char*) - 1)
> + rc += sprintf(out_buf, "%s", messages[msg_nr]);
> + else
> + rc += sprintf(out_buf, UNKNOWNSTR, msg_nr);
> + }
> + out:
> + return rc;
> + }
> +
> + struct debug_view debug_test_view = {
> + "myview", /* name of view */
> + NULL, /* no prolog */
> + &debug_dflt_header_fn, /* default header for each entry */
> + &debug_test_format_fn, /* our own format function */
> + NULL, /* no input function */
> + NULL /* no private data */
> + };
> +
> +test:
> +=====
> +
> ::
>
> debug_info_t *debug_info;
>
^ permalink raw reply
* Re: [PATCH 2/3] docs: s390: unify and update s390dbf kdocs at debug.c
From: Christian Borntraeger @ 2019-07-05 10:54 UTC (permalink / raw)
To: Steffen Maier, linux-doc
Cc: linux-s390, Mauro Carvalho Chehab, Mauro Carvalho Chehab,
Heiko Carstens, Vasily Gorbik, linux-kernel
In-Reply-To: <1562149189-1417-3-git-send-email-maier@linux.ibm.com>
On 03.07.19 12:19, Steffen Maier wrote:
> For non-static-inlines, debug.c already had non-compliant function
> header docs. So move the pure prototype kdocs of
> ("s390: include/asm/debug.h add kerneldoc markups")
> from debug.h to debug.c and merge them with the old function docs.
> Also, I had the impression that kdoc typically is at the implementation
> in the compile unit rather than at the prototype in the header file.
>
> While at it, update the short kdoc description to distinguish the
> different functions. And a few more consistency cleanups.
>
> Added a new kdoc for debug_set_critical() since debug.h comments it
> as part of the API.
>
> Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> Documentation/s390/s390dbf.rst | 1 +
> arch/s390/include/asm/debug.h | 112 ++++++-----------------------------------
> arch/s390/kernel/debug.c | 105 +++++++++++++++++++++++++++++++-------
> 3 files changed, 102 insertions(+), 116 deletions(-)
>
> diff --git a/Documentation/s390/s390dbf.rst b/Documentation/s390/s390dbf.rst
> index 01d66251643d..be42892b159e 100644
> --- a/Documentation/s390/s390dbf.rst
> +++ b/Documentation/s390/s390dbf.rst
> @@ -107,6 +107,7 @@ will stay deactivated.
> Kernel Interfaces:
> ------------------
>
> +.. kernel-doc:: arch/s390/kernel/debug.c
> .. kernel-doc:: arch/s390/include/asm/debug.h
>
> Predefined views:
> diff --git a/arch/s390/include/asm/debug.h b/arch/s390/include/asm/debug.h
> index 02c36eedd780..310134015541 100644
> --- a/arch/s390/include/asm/debug.h
> +++ b/arch/s390/include/asm/debug.h
> @@ -95,77 +95,19 @@ debug_entry_t *debug_exception_common(debug_info_t *id, int level,
>
> /* Debug Feature API: */
>
> -/**
> - * debug_register() - allocates memory for a debug log.
> - *
> - * @name: Name of debug log (e.g. used for debugfs entry)
> - * @pages: Number of pages, which will be allocated per area
> - * @nr_areas: Number of debug areas
> - * @buf_size: Size of data area in each debug entry
> - *
> - * Return:
> - * - Handler for generated debug area
> - * - %NULL if register failed
> - *
> - * Must not be called within an interrupt handler.
> - */
> debug_info_t *debug_register(const char *name, int pages, int nr_areas,
> int buf_size);
>
> -/**
> - * debug_register_mode() - allocates memory for a debug log.
> - *
> - * @name: Name of debug log (e.g. used for debugfs entry)
> - * @pages: Number of pages, which will be allocated per area
> - * @nr_areas: Number of debug areas
> - * @buf_size: Size of data area in each debug entry
> - * @mode: File mode for debugfs files. E.g. S_IRWXUGO
> - * @uid: User ID for debugfs files. Currently only 0 is supported.
> - * @gid: Group ID for debugfs files. Currently only 0 is supported.
> - *
> - * Return:
> - * - Handler for generated debug area
> - * - %NULL if register failed
> - *
> - * Must not be called within an interrupt handler
> - */
> debug_info_t *debug_register_mode(const char *name, int pages, int nr_areas,
> int buf_size, umode_t mode, uid_t uid,
> gid_t gid);
>
> -/**
> - * debug_unregister() - frees memory for a debug log and removes all
> - * registered debug
> - * views.
> - *
> - * @id: handle for debug log
> - *
> - * Return:
> - * none
> - *
> - * Must not be called within an interrupt handler
> - */
> void debug_unregister(debug_info_t *id);
>
> -/**
> - * debug_set_level() - Sets new actual debug level if new_level is valid.
> - *
> - * @id: handle for debug log
> - * @new_level: new debug level
> - *
> - * Return:
> - * none
> - */
> void debug_set_level(debug_info_t *id, int new_level);
>
> void debug_set_critical(void);
>
> -/**
> - * debug_stop_all() - stops the debug feature if stopping is allowed.
> - *
> - * Return:
> - * - none
> - */
> void debug_stop_all(void);
>
> /**
> @@ -184,7 +126,7 @@ static inline bool debug_level_enabled(debug_info_t *id, int level)
> }
>
> /**
> - * debug_event() - writes debug entry to active debug area
> + * debug_event() - writes binary debug entry to active debug area
> * (if level <= actual debug level)
> *
> * @id: handle for debug log
> @@ -194,6 +136,7 @@ static inline bool debug_level_enabled(debug_info_t *id, int level)
> *
> * Return:
> * - Address of written debug entry
> + * - %NULL if error
> */
> static inline debug_entry_t *debug_event(debug_info_t *id, int level,
> void *data, int length)
> @@ -204,7 +147,7 @@ static inline debug_entry_t *debug_event(debug_info_t *id, int level,
> }
>
> /**
> - * debug_int_event() - writes debug entry to active debug area
> + * debug_int_event() - writes unsigned integer debug entry to active debug area
> * (if level <= actual debug level)
> *
> * @id: handle for debug log
> @@ -226,12 +169,12 @@ static inline debug_entry_t *debug_int_event(debug_info_t *id, int level,
> }
>
> /**
> - * debug_long_event() - writes debug entry to active debug area
> + * debug_long_event() - writes unsigned long debug entry to active debug area
> * (if level <= actual debug level)
> *
> * @id: handle for debug log
> * @level: debug level
> - * @tag: integer value for debug entry
> + * @tag: long integer value for debug entry
> *
> * Return:
> * - Address of written debug entry
> @@ -248,7 +191,7 @@ static inline debug_entry_t *debug_long_event(debug_info_t *id, int level,
> }
>
> /**
> - * debug_text_event() - writes debug entry in ascii format to active
> + * debug_text_event() - writes string debug entry in ascii format to active
> * debug area (if level <= actual debug level)
> *
> * @id: handle for debug log
> @@ -306,9 +249,9 @@ static inline debug_entry_t *debug_text_event(debug_info_t *id, int level,
> })
>
> /**
> - * debug_exception() - writes debug entry to active debug area
> - * (if level <= actual debug level) and switches
> - * to next debug area
> + * debug_exception() - writes binary debug entry to active debug area
> + * (if level <= actual debug level)
> + * and switches to next debug area
> *
> * @id: handle for debug log
> * @level: debug level
> @@ -328,7 +271,7 @@ static inline debug_entry_t *debug_exception(debug_info_t *id, int level,
> }
>
> /**
> - * debug_int_exception() - writes debug entry to active debug area
> + * debug_int_exception() - writes unsigned int debug entry to active debug area
> * (if level <= actual debug level)
> * and switches to next debug area
> *
> @@ -351,13 +294,13 @@ static inline debug_entry_t *debug_int_exception(debug_info_t *id, int level,
> }
>
> /**
> - * debug_long_exception() - writes debug entry to active debug area
> + * debug_long_exception() - writes long debug entry to active debug area
> * (if level <= actual debug level)
> * and switches to next debug area
> *
> * @id: handle for debug log
> * @level: debug level
> - * @tag: integer value for debug entry
> + * @tag: long integer value for debug entry
> *
> * Return:
> * - Address of written debug entry
> @@ -374,9 +317,9 @@ static inline debug_entry_t *debug_long_exception (debug_info_t *id, int level,
> }
>
> /**
> - * debug_text_exception() - writes debug entry in ascii format to active
> + * debug_text_exception() - writes string debug entry in ascii format to active
> * debug area (if level <= actual debug level)
> - * and switches to next debug
> + * and switches to next debug area
> * area
> *
> * @id: handle for debug log
> @@ -407,7 +350,7 @@ static inline debug_entry_t *debug_text_exception(debug_info_t *id, int level,
> /**
> * debug_sprintf_exception() - writes debug entry with format string and
> * varargs (longs) to active debug area
> - * (if level $<=$ actual debug level)
> + * (if level <= actual debug level)
> * and switches to next debug area.
> *
> * @_id: handle for debug log
> @@ -435,33 +378,8 @@ static inline debug_entry_t *debug_text_exception(debug_info_t *id, int level,
> __ret; \
> })
>
> -/**
> - * debug_register_view() - registers new debug view and creates debugfs
> - * dir entry
> - *
> - * @id: handle for debug log
> - * @view: pointer to debug view struct
> - *
> - * Return:
> - * - 0 : ok
> - * - < 0: Error
> - */
> int debug_register_view(debug_info_t *id, struct debug_view *view);
>
> -/**
> - * debug_unregister_view()
> - *
> - * @id: handle for debug log
> - * @view: pointer to debug view struct
> - *
> - * Return:
> - * - 0 : ok
> - * - < 0: Error
> - *
> - *
> - * unregisters debug view and removes debugfs dir entry
> - */
> -
> int debug_unregister_view(debug_info_t *id, struct debug_view *view);
>
> /*
> diff --git a/arch/s390/kernel/debug.c b/arch/s390/kernel/debug.c
> index 0ebf08c3b35e..70a44bad625f 100644
> --- a/arch/s390/kernel/debug.c
> +++ b/arch/s390/kernel/debug.c
> @@ -647,11 +647,23 @@ static int debug_close(struct inode *inode, struct file *file)
> return 0; /* success */
> }
>
> -/*
> - * debug_register_mode:
> - * - Creates and initializes debug area for the caller
> - * The mode parameter allows to specify access rights for the s390dbf files
> - * - Returns handle for debug area
> +/**
> + * debug_register_mode() - creates and initializes debug area.
> + *
> + * @name: Name of debug log (e.g. used for debugfs entry)
> + * @pages_per_area: Number of pages, which will be allocated per area
> + * @nr_areas: Number of debug areas
> + * @buf_size: Size of data area in each debug entry
> + * @mode: File mode for debugfs files. E.g. S_IRWXUGO
> + * @uid: User ID for debugfs files. Currently only 0 is supported.
> + * @gid: Group ID for debugfs files. Currently only 0 is supported.
> + *
> + * Return:
> + * - Handle for generated debug area
> + * - %NULL if register failed
> + *
> + * Allocates memory for a debug log.
> + * Must not be called within an interrupt handler.
> */
> debug_info_t *debug_register_mode(const char *name, int pages_per_area,
> int nr_areas, int buf_size, umode_t mode,
> @@ -681,10 +693,21 @@ debug_info_t *debug_register_mode(const char *name, int pages_per_area,
> }
> EXPORT_SYMBOL(debug_register_mode);
>
> -/*
> - * debug_register:
> - * - creates and initializes debug area for the caller
> - * - returns handle for debug area
> +/**
> + * debug_register() - creates and initializes debug area with default file mode.
> + *
> + * @name: Name of debug log (e.g. used for debugfs entry)
> + * @pages_per_area: Number of pages, which will be allocated per area
> + * @nr_areas: Number of debug areas
> + * @buf_size: Size of data area in each debug entry
> + *
> + * Return:
> + * - Handle for generated debug area
> + * - %NULL if register failed
> + *
> + * Allocates memory for a debug log.
> + * The debugfs file mode access permisions are read and write for user.
> + * Must not be called within an interrupt handler.
> */
> debug_info_t *debug_register(const char *name, int pages_per_area,
> int nr_areas, int buf_size)
> @@ -694,9 +717,13 @@ debug_info_t *debug_register(const char *name, int pages_per_area,
> }
> EXPORT_SYMBOL(debug_register);
>
> -/*
> - * debug_unregister:
> - * - give back debug area
> +/**
> + * debug_unregister() - give back debug area.
> + *
> + * @id: handle for debug log
> + *
> + * Return:
> + * none
> */
> void debug_unregister(debug_info_t *id)
> {
> @@ -745,9 +772,14 @@ static int debug_set_size(debug_info_t *id, int nr_areas, int pages_per_area)
> return rc;
> }
>
> -/*
> - * debug_set_level:
> - * - set actual debug level
> +/**
> + * debug_set_level() - Sets new actual debug level if new_level is valid.
> + *
> + * @id: handle for debug log
> + * @new_level: new debug level
> + *
> + * Return:
> + * none
> */
> void debug_set_level(debug_info_t *id, int new_level)
> {
> @@ -873,6 +905,14 @@ static int s390dbf_procactive(struct ctl_table *table, int write,
>
> static struct ctl_table_header *s390dbf_sysctl_header;
>
> +/**
> + * debug_stop_all() - stops the debug feature if stopping is allowed.
> + *
> + * Return:
> + * - none
> + *
> + * Currently used in case of a kernel oops.
> + */
> void debug_stop_all(void)
> {
> if (debug_stoppable)
> @@ -880,6 +920,17 @@ void debug_stop_all(void)
> }
> EXPORT_SYMBOL(debug_stop_all);
>
> +/**
> + * debug_set_critical() - event/exception functions try lock instead of spin.
> + *
> + * Return:
> + * - none
> + *
> + * Currently used in case of stopping all CPUs but the current one.
> + * Once in this state, functions to write a debug entry for an
> + * event or exception no longer spin on the debug area lock,
> + * but only try to get it and fail if they do not get the lock.
> + */
> void debug_set_critical(void)
> {
> debug_critical = 1;
> @@ -1036,8 +1087,16 @@ debug_entry_t *__debug_sprintf_exception(debug_info_t *id, int level, char *stri
> }
> EXPORT_SYMBOL(__debug_sprintf_exception);
>
> -/*
> - * debug_register_view:
> +/**
> + * debug_register_view() - registers new debug view and creates debugfs
> + * dir entry
> + *
> + * @id: handle for debug log
> + * @view: pointer to debug view struct
> + *
> + * Return:
> + * - 0 : ok
> + * - < 0: Error
> */
> int debug_register_view(debug_info_t *id, struct debug_view *view)
> {
> @@ -1077,8 +1136,16 @@ int debug_register_view(debug_info_t *id, struct debug_view *view)
> }
> EXPORT_SYMBOL(debug_register_view);
>
> -/*
> - * debug_unregister_view:
> +/**
> + * debug_unregister_view() - unregisters debug view and removes debugfs
> + * dir entry
> + *
> + * @id: handle for debug log
> + * @view: pointer to debug view struct
> + *
> + * Return:
> + * - 0 : ok
> + * - < 0: Error
> */
> int debug_unregister_view(debug_info_t *id, struct debug_view *view)
> {
>
^ permalink raw reply
* Re: [PATCH 3/3] docs: s390: s390dbf: typos and formatting, update crash command
From: Christian Borntraeger @ 2019-07-05 10:54 UTC (permalink / raw)
To: Steffen Maier, linux-doc
Cc: linux-s390, Mauro Carvalho Chehab, Mauro Carvalho Chehab,
Heiko Carstens, Vasily Gorbik, linux-kernel
In-Reply-To: <1562149189-1417-4-git-send-email-maier@linux.ibm.com>
On 03.07.19 12:19, Steffen Maier wrote:
> Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> Documentation/s390/s390dbf.rst | 122 +++++++++++++++++++++++------------------
> 1 file changed, 68 insertions(+), 54 deletions(-)
>
> diff --git a/Documentation/s390/s390dbf.rst b/Documentation/s390/s390dbf.rst
> index be42892b159e..cdb36842b898 100644
> --- a/Documentation/s390/s390dbf.rst
> +++ b/Documentation/s390/s390dbf.rst
> @@ -23,7 +23,8 @@ The debug feature may also very useful for kernel and driver development.
> Design:
> -------
> Kernel components (e.g. device drivers) can register themselves at the debug
> -feature with the function call debug_register(). This function initializes a
> +feature with the function call :c:func:`debug_register()`.
> +This function initializes a
> debug log for the caller. For each debug log exists a number of debug areas
> where exactly one is active at one time. Each debug area consists of contiguous
> pages in memory. In the debug areas there are stored debug entries (log records)
> @@ -44,8 +45,9 @@ The debug areas themselves are also ordered in form of a ring buffer.
> When an exception is thrown in the last debug area, the following debug
> entries are then written again in the very first area.
>
> -There are three versions for the event- and exception-calls: One for
> -logging raw data, one for text and one for numbers.
> +There are four versions for the event- and exception-calls: One for
> +logging raw data, one for text, one for numbers (unsigned int and long),
> +and one for sprintf-like formatted strings.
>
> Each debug entry contains the following data:
>
> @@ -56,29 +58,29 @@ Each debug entry contains the following data:
> - Flag, if entry is an exception or not
>
> The debug logs can be inspected in a live system through entries in
> -the debugfs-filesystem. Under the toplevel directory "s390dbf" there is
> +the debugfs-filesystem. Under the toplevel directory "``s390dbf``" there is
> a directory for each registered component, which is named like the
> corresponding component. The debugfs normally should be mounted to
> -/sys/kernel/debug therefore the debug feature can be accessed under
> -/sys/kernel/debug/s390dbf.
> +``/sys/kernel/debug`` therefore the debug feature can be accessed under
> +``/sys/kernel/debug/s390dbf``.
>
> The content of the directories are files which represent different views
> to the debug log. Each component can decide which views should be
> -used through registering them with the function debug_register_view().
> +used through registering them with the function :c:func:`debug_register_view()`.
> Predefined views for hex/ascii, sprintf and raw binary data are provided.
> It is also possible to define other views. The content of
> a view can be inspected simply by reading the corresponding debugfs file.
>
> All debug logs have an actual debug level (range from 0 to 6).
> -The default level is 3. Event and Exception functions have a 'level'
> +The default level is 3. Event and Exception functions have a :c:data:`level`
> parameter. Only debug entries with a level that is lower or equal
> than the actual level are written to the log. This means, when
> writing events, high priority log entries should have a low level
> value whereas low priority entries should have a high one.
> The actual debug level can be changed with the help of the debugfs-filesystem
> -through writing a number string "x" to the 'level' debugfs file which is
> +through writing a number string "x" to the ``level`` debugfs file which is
> provided for every debug log. Debugging can be switched off completely
> -by using "-" on the 'level' debugfs file.
> +by using "-" on the ``level`` debugfs file.
>
> Example::
>
> @@ -86,21 +88,21 @@ Example::
>
> It is also possible to deactivate the debug feature globally for every
> debug log. You can change the behavior using 2 sysctl parameters in
> -/proc/sys/s390dbf:
> +``/proc/sys/s390dbf``:
>
> There are currently 2 possible triggers, which stop the debug feature
> -globally. The first possibility is to use the "debug_active" sysctl. If
> -set to 1 the debug feature is running. If "debug_active" is set to 0 the
> +globally. The first possibility is to use the ``debug_active`` sysctl. If
> +set to 1 the debug feature is running. If ``debug_active`` is set to 0 the
> debug feature is turned off.
>
> The second trigger which stops the debug feature is a kernel oops.
> That prevents the debug feature from overwriting debug information that
> happened before the oops. After an oops you can reactivate the debug feature
> -by piping 1 to /proc/sys/s390dbf/debug_active. Nevertheless, its not
> +by piping 1 to ``/proc/sys/s390dbf/debug_active``. Nevertheless, it's not
> suggested to use an oopsed kernel in a production environment.
>
> If you want to disallow the deactivation of the debug feature, you can use
> -the "debug_stoppable" sysctl. If you set "debug_stoppable" to 0 the debug
> +the ``debug_stoppable`` sysctl. If you set ``debug_stoppable`` to 0 the debug
> feature cannot be stopped. If the debug feature is already stopped, it
> will stay deactivated.
>
> @@ -113,16 +115,18 @@ Kernel Interfaces:
> Predefined views:
> -----------------
>
> -extern struct debug_view debug_hex_ascii_view;
> +.. code-block:: c
>
> -extern struct debug_view debug_raw_view;
> + extern struct debug_view debug_hex_ascii_view;
>
> -extern struct debug_view debug_sprintf_view;
> + extern struct debug_view debug_raw_view;
> +
> + extern struct debug_view debug_sprintf_view;
>
> Examples
> --------
>
> -::
> +.. code-block:: c
>
> /*
> * hex_ascii- + raw-view Example
> @@ -131,15 +135,15 @@ Examples
> #include <linux/init.h>
> #include <asm/debug.h>
>
> - static debug_info_t* debug_info;
> + static debug_info_t *debug_info;
>
> static int init(void)
> {
> /* register 4 debug areas with one page each and 4 byte data field */
>
> - debug_info = debug_register ("test", 1, 4, 4 );
> - debug_register_view(debug_info,&debug_hex_ascii_view);
> - debug_register_view(debug_info,&debug_raw_view);
> + debug_info = debug_register("test", 1, 4, 4 );
> + debug_register_view(debug_info, &debug_hex_ascii_view);
> + debug_register_view(debug_info, &debug_raw_view);
>
> debug_text_event(debug_info, 4 , "one ");
> debug_int_exception(debug_info, 4, 4711);
> @@ -150,13 +154,13 @@ Examples
>
> static void cleanup(void)
> {
> - debug_unregister (debug_info);
> + debug_unregister(debug_info);
> }
>
> module_init(init);
> module_exit(cleanup);
>
> -::
> +.. code-block:: c
>
> /*
> * sprintf-view Example
> @@ -165,15 +169,15 @@ Examples
> #include <linux/init.h>
> #include <asm/debug.h>
>
> - static debug_info_t* debug_info;
> + static debug_info_t *debug_info;
>
> static int init(void)
> {
> /* register 4 debug areas with one page each and data field for */
> /* format string pointer + 2 varargs (= 3 * sizeof(long)) */
>
> - debug_info = debug_register ("test", 1, 4, sizeof(long) * 3);
> - debug_register_view(debug_info,&debug_sprintf_view);
> + debug_info = debug_register("test", 1, 4, sizeof(long) * 3);
> + debug_register_view(debug_info, &debug_sprintf_view);
>
> debug_sprintf_event(debug_info, 2 , "first event in %s:%i\n",__FILE__,__LINE__);
> debug_sprintf_exception(debug_info, 1, "pointer to debug info: %p\n",&debug_info);
> @@ -183,7 +187,7 @@ Examples
>
> static void cleanup(void)
> {
> - debug_unregister (debug_info);
> + debug_unregister(debug_info);
> }
>
> module_init(init);
> @@ -252,7 +256,7 @@ Define 4 pages for the debug areas of debug feature "dasd"::
>
> > echo "4" > /sys/kernel/debug/s390dbf/dasd/pages
>
> -Stooping the debug feature
> +Stopping the debug feature
> --------------------------
> Example:
>
> @@ -264,10 +268,11 @@ Example:
>
> > echo 0 > /proc/sys/s390dbf/debug_active
>
> -lcrash Interface
> +crash Interface
> ----------------
> -It is planned that the dump analysis tool lcrash gets an additional command
> -'s390dbf' to display all the debug logs. With this tool it will be possible
> +The ``crash`` tool since v5.1.0 has a built-in command
> +``s390dbf`` to display all the debug logs or export them to the file system.
> +With this tool it is possible
> to investigate the debug logs on a live system and with a memory dump after
> a system crash.
>
> @@ -276,8 +281,8 @@ Investigating raw memory
> One last possibility to investigate the debug logs at a live
> system and after a system crash is to look at the raw memory
> under VM or at the Service Element.
> -It is possible to find the anker of the debug-logs through
> -the 'debug_area_first' symbol in the System map. Then one has
> +It is possible to find the anchor of the debug-logs through
> +the ``debug_area_first`` symbol in the System map. Then one has
> to follow the correct pointers of the data-structures defined
> in debug.h and find the debug-areas in memory.
> Normally modules which use the debug feature will also have
> @@ -286,7 +291,7 @@ this pointer it will also be possible to find the debug logs in
> memory.
>
> For this method it is recommended to use '16 * x + 4' byte (x = 0..n)
> -for the length of the data field in debug_register() in
> +for the length of the data field in :c:func:`debug_register()` in
> order to see the debug entries well formatted.
>
>
> @@ -295,7 +300,7 @@ Predefined Views
>
> There are three predefined views: hex_ascii, raw and sprintf.
> The hex_ascii view shows the data field in hex and ascii representation
> -(e.g. '45 43 4b 44 | ECKD').
> +(e.g. ``45 43 4b 44 | ECKD``).
> The raw view returns a bytestream as the debug areas are stored in memory.
>
> The sprintf view formats the debug entries in the same way as the sprintf
> @@ -335,18 +340,20 @@ The format of the raw view is:
> - datafield
>
> A typical line of the hex_ascii view will look like the following (first line
> -is only for explanation and will not be displayed when 'cating' the view):
> +is only for explanation and will not be displayed when 'cating' the view)::
>
> -area time level exception cpu caller data (hex + ascii)
> ---------------------------------------------------------------------------
> -00 00964419409:440690 1 - 00 88023fe
> + area time level exception cpu caller data (hex + ascii)
> + --------------------------------------------------------------------------
> + 00 00964419409:440690 1 - 00 88023fe
>
>
> Defining views
> --------------
>
> Views are specified with the 'debug_view' structure. There are defined
> -callback functions which are used for reading and writing the debugfs files::
> +callback functions which are used for reading and writing the debugfs files:
> +
> +.. code-block:: c
>
> struct debug_view {
> char name[DEBUG_MAX_PROCF_LEN];
> @@ -357,7 +364,9 @@ callback functions which are used for reading and writing the debugfs files::
> void* private_data;
> };
>
> -where::
> +where:
> +
> +.. code-block:: c
>
> typedef int (debug_header_proc_t) (debug_info_t* id,
> struct debug_view* view,
> @@ -395,10 +404,10 @@ Then 'header_proc' and 'format_proc' are called for each
> existing debug entry.
>
> The input_proc can be used to implement functionality when it is written to
> -the view (e.g. like with 'echo "0" > /sys/kernel/debug/s390dbf/dasd/level).
> +the view (e.g. like with ``echo "0" > /sys/kernel/debug/s390dbf/dasd/level``).
>
> For header_proc there can be used the default function
> -debug_dflt_header_fn() which is defined in debug.h.
> +:c:func:`debug_dflt_header_fn()` which is defined in debug.h.
> and which produces the same header output as the predefined views.
> E.g::
>
> @@ -407,7 +416,9 @@ E.g::
> In order to see how to use the callback functions check the implementation
> of the default views!
>
> -Example::
> +Example:
> +
> +.. code-block:: c
>
> #include <asm/debug.h>
>
> @@ -423,21 +434,20 @@ Example::
> };
>
> static int debug_test_format_fn(
> - debug_info_t * id, struct debug_view *view,
> + debug_info_t *id, struct debug_view *view,
> char *out_buf, const char *in_buf
> )
> {
> int i, rc = 0;
>
> - if(id->buf_size >= 4) {
> + if (id->buf_size >= 4) {
> int msg_nr = *((int*)in_buf);
> - if(msg_nr < sizeof(messages)/sizeof(char*) - 1)
> + if (msg_nr < sizeof(messages) / sizeof(char*) - 1)
> rc += sprintf(out_buf, "%s", messages[msg_nr]);
> else
> rc += sprintf(out_buf, UNKNOWNSTR, msg_nr);
> }
> - out:
> - return rc;
> + return rc;
> }
>
> struct debug_view debug_test_view = {
> @@ -452,13 +462,17 @@ Example::
> test:
> =====
>
> -::
> +.. code-block:: c
>
> debug_info_t *debug_info;
> + int i;
> ...
> - debug_info = debug_register ("test", 0, 4, 4 ));
> + debug_info = debug_register("test", 0, 4, 4);
> debug_register_view(debug_info, &debug_test_view);
> - for(i = 0; i < 10; i ++) debug_int_event(debug_info, 1, i);
> + for (i = 0; i < 10; i ++)
> + debug_int_event(debug_info, 1, i);
> +
> +::
>
> > cat /sys/kernel/debug/s390dbf/test/myview
> 00 00964419734:611402 1 - 00 88042ca This error...........
>
^ permalink raw reply
* Re: [PATCH 2/3] docs: s390: unify and update s390dbf kdocs at debug.c
From: Vasily Gorbik @ 2019-07-05 12:27 UTC (permalink / raw)
To: Steffen Maier
Cc: linux-doc, linux-s390, Mauro Carvalho Chehab,
Mauro Carvalho Chehab, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-kernel
In-Reply-To: <1562149189-1417-3-git-send-email-maier@linux.ibm.com>
On Wed, Jul 03, 2019 at 12:19:48PM +0200, Steffen Maier wrote:
> For non-static-inlines, debug.c already had non-compliant function
> header docs. So move the pure prototype kdocs of
> ("s390: include/asm/debug.h add kerneldoc markups")
> from debug.h to debug.c and merge them with the old function docs.
> Also, I had the impression that kdoc typically is at the implementation
> in the compile unit rather than at the prototype in the header file.
>
> While at it, update the short kdoc description to distinguish the
> different functions. And a few more consistency cleanups.
>
> Added a new kdoc for debug_set_critical() since debug.h comments it
> as part of the API.
>
> Signed-off-by: Steffen Maier <maier@linux.ibm.com>
> ---
> Documentation/s390/s390dbf.rst | 1 +
> arch/s390/include/asm/debug.h | 112 ++++++-----------------------------------
> arch/s390/kernel/debug.c | 105 +++++++++++++++++++++++++++++++-------
> 3 files changed, 102 insertions(+), 116 deletions(-)
>
Applied with "permisions->permissions" and couple of whitespaces removed, thanks.
^ permalink raw reply
* Re: [PATCH 0/3] docs: s390: restore content and update s390dbf.rst
From: Vasily Gorbik @ 2019-07-05 12:28 UTC (permalink / raw)
To: Steffen Maier
Cc: linux-doc, linux-s390, Mauro Carvalho Chehab,
Mauro Carvalho Chehab, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, linux-kernel
In-Reply-To: <1562149189-1417-1-git-send-email-maier@linux.ibm.com>
On Wed, Jul 03, 2019 at 12:19:46PM +0200, Steffen Maier wrote:
> This is based on top of the 3 s390 patches Heiko already queued on our
> s390 features branch.
> [("Re: [PATCH v3 00/33] Convert files to ReST - part 1")
> https://www.spinics.net/lists/linux-doc/msg66137.html
> https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/log/Documentation/s390?h=features]
>
> If I was not mistaken, some documentation was accidentally lost
> and patch 1 restores it.
>
> After having looked closer, I came up with patches 2 and 3.
> Rendered successfully on a current Fedora 30 and it looks good:
> $ make SPHINXDIRS="s390" htmldocs
>
> Steffen Maier (3):
> docs: s390: restore important non-kdoc parts of s390dbf.rst
> docs: s390: unify and update s390dbf kdocs at debug.c
> docs: s390: s390dbf: typos and formatting, update crash command
>
> Documentation/s390/s390dbf.rst | 390 +++++++++++++++++++++++++++++++++++++++--
> arch/s390/include/asm/debug.h | 112 ++----------
> arch/s390/kernel/debug.c | 105 +++++++++--
> 3 files changed, 473 insertions(+), 134 deletions(-)
>
> --
> 1.8.3.1
>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v12 01/11] MODSIGN: Export module signature definitions
From: Philipp Rudo @ 2019-07-05 13:00 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: Jessica Yu, linux-integrity, linux-security-module, keyrings,
linux-crypto, linuxppc-dev, linux-doc, linux-kernel, Mimi Zohar,
Dmitry Kasatkin, James Morris, Serge E. Hallyn, David Howells,
David Woodhouse, Herbert Xu, David S. Miller, Jonathan Corbet,
AKASHI, Takahiro, Heiko Carstens, linux-s390
In-Reply-To: <874l41ocf5.fsf@morokweng.localdomain>
Hi Thiago,
On Thu, 04 Jul 2019 15:57:34 -0300
Thiago Jung Bauermann <bauerman@linux.ibm.com> wrote:
> Hello Philipp,
>
> Philipp Rudo <prudo@linux.ibm.com> writes:
>
> > Hi Thiago,
> >
> >
> > On Thu, 04 Jul 2019 03:42:57 -0300
> > Thiago Jung Bauermann <bauerman@linux.ibm.com> wrote:
> >
> >> Jessica Yu <jeyu@kernel.org> writes:
> >>
> >> > +++ Thiago Jung Bauermann [27/06/19 23:19 -0300]:
> >> >>IMA will use the module_signature format for append signatures, so export
> >> >>the relevant definitions and factor out the code which verifies that the
> >> >>appended signature trailer is valid.
> >> >>
> >> >>Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it
> >> >>and be able to use mod_check_sig() without having to depend on either
> >> >>CONFIG_MODULE_SIG or CONFIG_MODULES.
> >> >>
> >> >>Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> >> >>Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> >> >>Cc: Jessica Yu <jeyu@kernel.org>
> >> >>---
> >> >> include/linux/module.h | 3 --
> >> >> include/linux/module_signature.h | 44 +++++++++++++++++++++++++
> >> >> init/Kconfig | 6 +++-
> >> >> kernel/Makefile | 1 +
> >> >> kernel/module.c | 1 +
> >> >> kernel/module_signature.c | 46 ++++++++++++++++++++++++++
> >> >> kernel/module_signing.c | 56 +++++---------------------------
> >> >> scripts/Makefile | 2 +-
> >> >> 8 files changed, 106 insertions(+), 53 deletions(-)
> >> >>
> >> >>diff --git a/include/linux/module.h b/include/linux/module.h
> >> >>index 188998d3dca9..aa56f531cf1e 100644
> >> >>--- a/include/linux/module.h
> >> >>+++ b/include/linux/module.h
> >> >>@@ -25,9 +25,6 @@
> >> >> #include <linux/percpu.h>
> >> >> #include <asm/module.h>
> >> >>
> >> >>-/* In stripped ARM and x86-64 modules, ~ is surprisingly rare. */
> >> >>-#define MODULE_SIG_STRING "~Module signature appended~\n"
> >> >>-
> >> >
> >> > Hi Thiago, apologies for the delay.
> >>
> >> Hello Jessica, thanks for reviewing the patch!
> >>
> >> > It looks like arch/s390/kernel/machine_kexec_file.c also relies on
> >> > MODULE_SIG_STRING being defined, so module_signature.h will need to be
> >> > included there too, otherwise we'll run into a compilation error.
> >>
> >> Indeed. Thanks for spotting that. The patch below fixes it. It's
> >> identical to the previous version except for the changes in
> >> arch/s390/kernel/machine_kexec_file.c and their description in the
> >> commit message. I'm also copying some s390 people in this email.
> >
> > to me the s390 part looks good but for one minor nit.
>
> Thanks for the prompt review!
>
> > In arch/s390/Kconfig KEXEC_VERIFY_SIG currently depends on
> > SYSTEM_DATA_VERIFICATION. I'd prefer when you update this to the new
> > MODULE_SIG_FORMAT. It shouldn't make any difference right now, as we don't
> > use mod_check_sig in our code path. But it could cause problems in the future,
> > when more code might be shared.
>
> Makes sense. Here is the updated patch with the Kconfig change.
>
The patch looks good now.
Thanks a lot
PHilipp
^ permalink raw reply
* [Linux-kernel-mentees] [PATCH] Doc : fs : move xfs.txt to admin-guide
From: Sheriff Esseson @ 2019-07-05 13:14 UTC (permalink / raw)
To: skhan
Cc: darrick.wong, linux-xfs, corbet, linux-doc, linux-kernel,
linux-kernel-mentees
As suggested by Matthew Wilcox, xfs.txt is primarily a guide on available
options when setting up an XFS. This makes it appropriate to be placed under
the admin-guide tree.
Thus, move xfs.txt to admin-guide and fix broken references.
Signed-off-by: Sheriff Esseson <sheriffesseson@gmail.com>
---
The reference to xfs.txt from dax.txt in itself is not looking good. Maybe, we
need something more inspirational.
Documentation/{filesystems => admin-guide}/xfs.txt | 0
Documentation/filesystems/dax.txt | 2 +-
MAINTAINERS | 2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename Documentation/{filesystems => admin-guide}/xfs.txt (100%)
diff --git a/Documentation/filesystems/xfs.txt b/Documentation/admin-guide/xfs.txt
similarity index 100%
rename from Documentation/filesystems/xfs.txt
rename to Documentation/admin-guide/xfs.txt
diff --git a/Documentation/filesystems/dax.txt b/Documentation/filesystems/dax.txt
index 6d2c0d340..b2b19738b 100644
--- a/Documentation/filesystems/dax.txt
+++ b/Documentation/filesystems/dax.txt
@@ -76,7 +76,7 @@ exposure of uninitialized data through mmap.
These filesystems may be used for inspiration:
- ext2: see Documentation/filesystems/ext2.txt
- ext4: see Documentation/filesystems/ext4/
-- xfs: see Documentation/filesystems/xfs.txt
+- xfs: see Documentation/admin-guide/xfs.txt
Handling Media Errors
diff --git a/MAINTAINERS b/MAINTAINERS
index 01a52fc96..fc309b0a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17374,7 +17374,7 @@ L: linux-xfs@vger.kernel.org
W: http://xfs.org/
T: git git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git
S: Supported
-F: Documentation/filesystems/xfs.txt
+F: Documentation/admin-guide/xfs.txt
F: fs/xfs/
XILINX AXI ETHERNET DRIVER
--
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
2.22.0
^ permalink raw reply related
* [PATCH] docs/pinctrl: fix compile errors in example code
From: Luca Ceresoli @ 2019-07-05 14:30 UTC (permalink / raw)
To: linux-gpio
Cc: Luca Ceresoli, Linus Walleij, Jonathan Corbet, linux-doc,
linux-kernel
The code in the example does not build for a few trivial errors: type
mismatch in callback, missing semicolon. Fix them to help newcomers using
the example as a starting point.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
Documentation/driver-api/pinctl.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/driver-api/pinctl.rst b/Documentation/driver-api/pinctl.rst
index 2bb1bc484278..3d2deaf48841 100644
--- a/Documentation/driver-api/pinctl.rst
+++ b/Documentation/driver-api/pinctl.rst
@@ -638,8 +638,8 @@ group of pins would work something like this::
}
static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector,
- unsigned ** const pins,
- unsigned * const num_pins)
+ const unsigned ** pins,
+ unsigned * num_pins)
{
*pins = (unsigned *) foo_groups[selector].pins;
*num_pins = foo_groups[selector].num_pins;
@@ -705,7 +705,7 @@ group of pins would work something like this::
{
u8 regbit = (1 << selector + group);
- writeb((readb(MUX)|regbit), MUX)
+ writeb((readb(MUX)|regbit), MUX);
return 0;
}
--
2.22.0
^ permalink raw reply related
* [PATCH] Documentation: usb: convert usb-help to rst
From: Phong Tran @ 2019-07-05 18:55 UTC (permalink / raw)
To: corbet, gregkh, skhan, mchehab
Cc: linux-kernel-mentees, linux-usb, linux-doc, linux-kernel,
Phong Tran
Add new index.rst and change usb-help.txt format
to rst.
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
---
Documentation/index.rst | 1 +
Documentation/usb/index.rst | 22 ++++++++++++++++++++++
Documentation/usb/{usb-help.txt => usb-help.rst} | 1 -
3 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 Documentation/usb/index.rst
rename Documentation/usb/{usb-help.txt => usb-help.rst} (97%)
diff --git a/Documentation/index.rst b/Documentation/index.rst
index a7566ef62411..4e7498f39063 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -102,6 +102,7 @@ needed).
vm/index
bpf/index
misc-devices/index
+ usb/index
Architecture-specific documentation
-----------------------------------
diff --git a/Documentation/usb/index.rst b/Documentation/usb/index.rst
new file mode 100644
index 000000000000..5688ceaf0826
--- /dev/null
+++ b/Documentation/usb/index.rst
@@ -0,0 +1,22 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Linux USB Subsystem Documentation
+===================================
+
+.. only:: html
+
+ .. class:: toc-title
+
+ Table of Contents
+
+.. toctree::
+ :maxdepth: 2
+
+ usb-help
+
+.. only:: html and subproject
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/usb/usb-help.txt b/Documentation/usb/usb-help.rst
similarity index 97%
rename from Documentation/usb/usb-help.txt
rename to Documentation/usb/usb-help.rst
index dc23ecd4d802..03abc4e501ae 100644
--- a/Documentation/usb/usb-help.txt
+++ b/Documentation/usb/usb-help.rst
@@ -1,4 +1,3 @@
-==============
USB references
==============
--
2.11.0
^ permalink raw reply related
* [PATCH] Documentation: dev-tools: Fixed an outdated directory path in gcov.rst
From: Jeffrin Jose T @ 2019-07-05 19:02 UTC (permalink / raw)
To: oberpar, corbet, linux-doc
Cc: linux-kernel, clang-built-linux, Jeffrin Jose T
Fixed an outdated directory path inside gcov related documentation
which is part of an example that shows the way in which the gcov
command should be used in that context
Signed-off-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in>
---
Documentation/dev-tools/gcov.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/dev-tools/gcov.rst b/Documentation/dev-tools/gcov.rst
index 46aae52a41d0..e3d262d8c7de 100644
--- a/Documentation/dev-tools/gcov.rst
+++ b/Documentation/dev-tools/gcov.rst
@@ -8,7 +8,7 @@ To get coverage data for a specific file, change to the kernel build
directory and use gcov with the ``-o`` option as follows (requires root)::
# cd /tmp/linux-out
- # gcov -o /sys/kernel/debug/gcov/tmp/linux-out/kernel spinlock.c
+ # gcov -o /sys/kernel/debug/gcov/tmp/linux-out/kernel/locking spinlock.c
This will create source code files annotated with execution counts
in the current directory. In addition, graphical gcov front-ends such
--
2.20.1
^ permalink raw reply related
* Re: [Linux-kernel-mentees] [PATCH] Doc : fs : move xfs.txt to admin-guide
From: Matthew Wilcox @ 2019-07-05 19:04 UTC (permalink / raw)
To: Sheriff Esseson
Cc: skhan, darrick.wong, linux-xfs, corbet, linux-doc, linux-kernel,
linux-kernel-mentees
In-Reply-To: <20190705131446.GA10045@localhost>
On Fri, Jul 05, 2019 at 02:14:46PM +0100, Sheriff Esseson wrote:
> As suggested by Matthew Wilcox, xfs.txt is primarily a guide on available
> options when setting up an XFS. This makes it appropriate to be placed under
> the admin-guide tree.
>
> Thus, move xfs.txt to admin-guide and fix broken references.
What happened to the conversion to xfs.rst?
^ permalink raw reply
* Re: [Linux-kernel-mentees] [PATCH] Doc : fs : move xfs.txt to admin-guide
From: Sheriff Esseson @ 2019-07-05 19:41 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-kernel-mentees, darrick.wong, linux-xfs, corbet, linux-doc
In-Reply-To: <20190705190412.GB32320@bombadil.infradead.org>
On Fri, Jul 05, 2019 at 12:04:12PM -0700, Matthew Wilcox wrote:
> On Fri, Jul 05, 2019 at 02:14:46PM +0100, Sheriff Esseson wrote:
> > As suggested by Matthew Wilcox, xfs.txt is primarily a guide on available
> > options when setting up an XFS. This makes it appropriate to be placed under
> > the admin-guide tree.
> >
> > Thus, move xfs.txt to admin-guide and fix broken references.
>
> What happened to the conversion to xfs.rst?
Okay, I was thinking placing the file properly should come first before the
conversion.
I'll continue work on the conversion right away. I'll send it on Monday, letting
the dust settle on this one.
>
> _______________________________________________
> Linux-kernel-mentees mailing list
> Linux-kernel-mentees@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
thanks.
^ permalink raw reply
* Re: [PATCH v6 01/18] kunit: test: add KUnit test runner core
From: Luis Chamberlain @ 2019-07-05 20:15 UTC (permalink / raw)
To: Brendan Higgins
Cc: frowand.list, gregkh, jpoimboe, keescook, kieran.bingham, peterz,
robh, sboyd, shuah, tytso, yamada.masahiro, devicetree, dri-devel,
kunit-dev, linux-doc, linux-fsdevel, linux-kbuild, linux-kernel,
linux-kselftest, linux-nvdimm, linux-um, Alexander.Levin,
Tim.Bird, amir73il, dan.carpenter, daniel, jdike, joel,
julia.lawall, khilman, knut.omang, logang, mpe, pmladek, rdunlap,
richard, rientjes, rostedt, wfg
In-Reply-To: <20190704003615.204860-2-brendanhiggins@google.com>
On Wed, Jul 03, 2019 at 05:35:58PM -0700, Brendan Higgins wrote:
> Add core facilities for defining unit tests; this provides a common way
> to define test cases, functions that execute code which is under test
> and determine whether the code under test behaves as expected; this also
> provides a way to group together related test cases in test suites (here
> we call them test_modules).
>
> Just define test cases and how to execute them for now; setting
> expectations on code will be defined later.
>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
But a nitpick below, I think that can be fixed later with a follow up
patch.
> +/**
> + * struct kunit - represents a running instance of a test.
> + * @priv: for user to store arbitrary data. Commonly used to pass data created
> + * in the init function (see &struct kunit_suite).
> + *
> + * Used to store information about the current context under which the test is
> + * running. Most of this data is private and should only be accessed indirectly
> + * via public functions; the one exception is @priv which can be used by the
> + * test writer to store arbitrary data.
> + *
> + * A brief note on locking:
> + *
> + * First off, we need to lock because in certain cases a user may want to use an
> + * expectation in a thread other than the thread that the test case is running
> + * in.
This as a prefix to the struct without a lock seems odd. It would be
clearer I think if you'd explain here what locking mechanism we decided
to use and why it suffices today.
> +/**
> + * suite_test() - used to register a &struct kunit_suite with KUnit.
You mean kunit_test_suite()?
> + * @suite: a statically allocated &struct kunit_suite.
> + *
> + * Registers @suite with the test framework. See &struct kunit_suite for more
> + * information.
> + *
> + * NOTE: Currently KUnit tests are all run as late_initcalls; this means that
> + * they cannot test anything where tests must run at a different init phase. One
> + * significant restriction resulting from this is that KUnit cannot reliably
> + * test anything that is initialize in the late_init phase.
initialize prior to the late init phase.
That is, this is useless to test things running early.
> + *
> + * TODO(brendanhiggins@google.com): Don't run all KUnit tests as late_initcalls.
> + * I have some future work planned to dispatch all KUnit tests from the same
> + * place, and at the very least to do so after everything else is definitely
> + * initialized.
TODOs are odd to be adding to documentation, this is just not common
place practice. The NOTE should suffice for you.
Luis
^ permalink raw reply
* Re: [PATCH v6 01/18] kunit: test: add KUnit test runner core
From: Luis Chamberlain @ 2019-07-05 20:20 UTC (permalink / raw)
To: Brendan Higgins
Cc: frowand.list, gregkh, jpoimboe, keescook, kieran.bingham, peterz,
robh, sboyd, shuah, tytso, yamada.masahiro, devicetree, dri-devel,
kunit-dev, linux-doc, linux-fsdevel, linux-kbuild, linux-kernel,
linux-kselftest, linux-nvdimm, linux-um, Alexander.Levin,
Tim.Bird, amir73il, dan.carpenter, daniel, jdike, joel,
julia.lawall, khilman, knut.omang, logang, mpe, pmladek, rdunlap,
richard, rientjes, rostedt, wfg
In-Reply-To: <20190704003615.204860-2-brendanhiggins@google.com>
On Wed, Jul 03, 2019 at 05:35:58PM -0700, Brendan Higgins wrote:
> +struct kunit {
> + void *priv;
> +
> + /* private: internal use only. */
> + const char *name; /* Read only after initialization! */
> + bool success; /* Read only after test_case finishes! */
> +};
No lock attribute above.
> +void kunit_init_test(struct kunit *test, const char *name)
> +{
> + spin_lock_init(&test->lock);
> + test->name = name;
> + test->success = true;
> +}
And yet here you initialize a spin lock... This won't compile. Seems
you forgot to remove this line. So I guess a re-spin is better.
Luis
^ permalink raw reply
* [PATCH] Documentation: coresight: covert txt to rst
From: Phong Tran @ 2019-07-05 20:45 UTC (permalink / raw)
To: corbet, mathieu.poirier, suzuki.poulose
Cc: skhan, mchehab, linux-arm-kernel, linux-doc, linux-kernel,
linux-kernel-mentees, Phong Tran
change the format file and adpate the text style
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
---
.../trace/{coresight.txt => coresight.rst} | 296 ++++++++++++---------
Documentation/trace/index.rst | 1 +
2 files changed, 167 insertions(+), 130 deletions(-)
rename Documentation/trace/{coresight.txt => coresight.rst} (59%)
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.rst
similarity index 59%
rename from Documentation/trace/coresight.txt
rename to Documentation/trace/coresight.rst
index efbc832146e7..bea24e70cfba 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.rst
@@ -1,5 +1,6 @@
- Coresight - HW Assisted Tracing on ARM
- ======================================
+======================================
+Coresight - HW Assisted Tracing on ARM
+======================================
Author: Mathieu Poirier <mathieu.poirier@linaro.org>
Date: September 11th, 2014
@@ -26,7 +27,7 @@ implementation, either storing the compressed stream in a memory buffer or
creating an interface to the outside world where data can be transferred to a
host without fear of filling up the onboard coresight memory buffer.
-At typical coresight system would look like this:
+At typical coresight system would look like this::
*****************************************************************
**************************** AMBA AXI ****************************===||
@@ -95,6 +96,7 @@ Acronyms and Classification
Acronyms:
+======== =============================================================
PTM: Program Trace Macrocell
ETM: Embedded Trace Macrocell
STM: System trace Macrocell
@@ -104,6 +106,7 @@ TPIU: Trace Port Interface Unit
TMC-ETR: Trace Memory Controller, configured as Embedded Trace Router
TMC-ETF: Trace Memory Controller, configured as Embedded Trace FIFO
CTI: Cross Trigger Interface
+======== =============================================================
Classification:
@@ -118,7 +121,7 @@ Misc:
Device Tree Bindings
-----------------------
+--------------------
See Documentation/devicetree/bindings/arm/coresight.txt for details.
@@ -133,57 +136,63 @@ The coresight framework provides a central point to represent, configure and
manage coresight devices on a platform. Any coresight compliant device can
register with the framework for as long as they use the right APIs:
-struct coresight_device *coresight_register(struct coresight_desc *desc);
-void coresight_unregister(struct coresight_device *csdev);
+.. c:function:: struct coresight_device *coresight_register(struct coresight_desc *desc);
+.. c:function:: void coresight_unregister(struct coresight_device *csdev);
-The registering function is taking a "struct coresight_device *csdev" and
+The registering function is taking a :code:`struct coresight_device *csdev` and
register the device with the core framework. The unregister function takes
-a reference to a "struct coresight_device", obtained at registration time.
+a reference to a :code:`struct coresight_device`, obtained at registration time.
If everything goes well during the registration process the new devices will
show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
-root:~# ls /sys/bus/coresight/devices/
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
-root:~#
+.. code:: console
-The functions take a "struct coresight_device", which looks like this:
+ root:~# ls /sys/bus/coresight/devices/
+ replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
+ 20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+ root:~#
-struct coresight_desc {
- enum coresight_dev_type type;
- struct coresight_dev_subtype subtype;
- const struct coresight_ops *ops;
- struct coresight_platform_data *pdata;
- struct device *dev;
- const struct attribute_group **groups;
-};
+The functions take a :code:`struct coresight_device`, which looks like this:
+
+.. code:: c
+
+ struct coresight_desc {
+ enum coresight_dev_type type;
+ struct coresight_dev_subtype subtype;
+ const struct coresight_ops *ops;
+ struct coresight_platform_data *pdata;
+ struct device *dev;
+ const struct attribute_group **groups;
+ };
The "coresight_dev_type" identifies what the device is, i.e, source link or
sink while the "coresight_dev_subtype" will characterise that type further.
-The "struct coresight_ops" is mandatory and will tell the framework how to
+The :code:`struct coresight_ops` is mandatory and will tell the framework how to
perform base operations related to the components, each component having
-a different set of requirement. For that "struct coresight_ops_sink",
-"struct coresight_ops_link" and "struct coresight_ops_source" have been
+a different set of requirement. For that :code:`struct coresight_ops_sink,
+struct coresight_ops_link` and :code:`struct coresight_ops_source` have been
provided.
-The next field, "struct coresight_platform_data *pdata" is acquired by calling
-"of_get_coresight_platform_data()", as part of the driver's _probe routine and
-"struct device *dev" gets the device reference embedded in the "amba_device":
+The next field, :code:`struct coresight_platform_data *pdata` is acquired by calling
+:code:`of_get_coresight_platform_data()`, as part of the driver's _probe routine and
+:code:`struct device *dev` gets the device reference embedded in the :code:`amba_device`:
-static int etm_probe(struct amba_device *adev, const struct amba_id *id)
-{
- ...
- ...
- drvdata->dev = &adev->dev;
- ...
-}
+.. code:: c
+
+ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
+ {
+ ...
+ ...
+ drvdata->dev = &adev->dev;
+ ...
+ }
Specific class of device (source, link, or sink) have generic operations
-that can be performed on them (see "struct coresight_ops"). The
-"**groups" is a list of sysfs entries pertaining to operations
+that can be performed on them (see :code:`struct coresight_ops`). The
+:code:`**groups` is a list of sysfs entries pertaining to operations
specific to that component only. "Implementation defined" customisations are
expected to be accessed and controlled using those entries.
@@ -204,49 +213,56 @@ There is no limit on the amount of sinks (nor sources) that can be enabled at
any given moment. As a generic operation, all device pertaining to the sink
class will have an "active" entry in sysfs:
-root:/sys/bus/coresight/devices# ls
-replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
-20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
-root:/sys/bus/coresight/devices# ls 20010000.etb
-enable_sink status trigger_cntr
-root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
-root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
-1
-root:/sys/bus/coresight/devices#
+.. code:: console
+
+ root:/sys/bus/coresight/devices# ls
+ replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
+ 20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
+ root:/sys/bus/coresight/devices# ls 20010000.etb
+ enable_sink status trigger_cntr
+ root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
+ root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
+ 1
+ root:/sys/bus/coresight/devices#
At boot time the current etm3x driver will configure the first address
comparator with "_stext" and "_etext", essentially tracing any instruction
that falls within that range. As such "enabling" a source will immediately
trigger a trace capture:
-root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
-root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
-1
-root:/sys/bus/coresight/devices# cat 20010000.etb/status
-Depth: 0x2000
-Status: 0x1
-RAM read ptr: 0x0
-RAM wrt ptr: 0x19d3 <----- The write pointer is moving
-Trigger cnt: 0x0
-Control: 0x1
-Flush status: 0x0
-Flush ctrl: 0x2001
-root:/sys/bus/coresight/devices#
+.. code:: console
+
+ root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
+ root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
+ 1
+ root:/sys/bus/coresight/devices# cat 20010000.etb/status
+ Depth: 0x2000
+ Status: 0x1
+ RAM read ptr: 0x0
+ RAM wrt ptr: 0x19d3 <----- The write pointer is moving
+ Trigger cnt: 0x0
+ Control: 0x1
+ Flush status: 0x0
+ Flush ctrl: 0x2001
+ root:/sys/bus/coresight/devices#
Trace collection is stopped the same way:
-root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source
-root:/sys/bus/coresight/devices#
+.. code:: console
+
+ root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source
+ root:/sys/bus/coresight/devices#
The content of the ETB buffer can be harvested directly from /dev:
-root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \
-of=~/cstrace.bin
+.. code:: console
-64+0 records in
-64+0 records out
-32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s
-root:/sys/bus/coresight/devices#
+ root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \
+ of=~/cstrace.bin
+ 64+0 records in
+ 64+0 records out
+ 32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s
+ root:/sys/bus/coresight/devices#
The file cstrace.bin can be decompressed using "ptm2human", DS-5 or Trace32.
@@ -254,55 +270,57 @@ Following is a DS-5 output of an experimental loop that increments a variable up
to a certain value. The example is simple and yet provides a glimpse of the
wealth of possibilities that coresight provides.
-Info Tracing enabled
-Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr}
-Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc
-Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
-Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Timestamp Timestamp: 17106715833
-Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4]
-Instruction 0 0x8026B550 E3530004 false CMP r3,#4
-Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
-Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
-Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
-Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1
-Instruction 0 0x8026B564 E1A0100D false MOV r1,sp
-Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0
-Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f
-Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4]
-Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368
-Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc]
-Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0]
-Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4
-Info Tracing enabled
-Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc
-Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
-Timestamp Timestamp: 17107041535
+.. code:: c
+
+ Info Tracing enabled
+ Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr}
+ Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc
+ Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
+ Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4]
+ Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+ Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+ Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+ Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+ Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+ Timestamp Timestamp: 17106715833
+ Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+ Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+ Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+ Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+ Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+ Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+ Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+ Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+ Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+ Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+ Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+ Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+ Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+ Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+ Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+ Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+ Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+ Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+ Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+ Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+ Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4]
+ Instruction 0 0x8026B550 E3530004 false CMP r3,#4
+ Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
+ Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
+ Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
+ Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1
+ Instruction 0 0x8026B564 E1A0100D false MOV r1,sp
+ Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0
+ Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f
+ Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4]
+ Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368
+ Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc]
+ Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0]
+ Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4
+ Info Tracing enabled
+ Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc
+ Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
+ Timestamp Timestamp: 17107041535
2) Using perf framework:
@@ -312,6 +330,8 @@ controlling when tracing gets enabled based on when the process of interest is
scheduled. When configured in a system, Coresight PMUs will be listed when
queried by the perf command line tool:
+.. code:: console
+
linaro@linaro-nano:~$ ./perf list pmu
List of pre-defined events (to be used in -e):
@@ -329,6 +349,8 @@ Coresight system will typically have more than one sink, the name of the sink to
work with needs to be specified as an event option. Names for sink to choose
from are listed in sysFS under ($SYSFS)/bus/coresight/devices:
+.. code:: console
+
root@linaro-nano:~# ls /sys/bus/coresight/devices/
20010000.etf 20040000.funnel 20100000.stm 22040000.etm
22140000.etm 230c0000.funnel 23240000.etm 20030000.tpiu
@@ -343,7 +365,7 @@ to use for the trace session.
More information on the above and other example on how to use Coresight with
the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub
-repository [3].
+repository [#third]_.
2.1) AutoFDO analysis using the perf tools:
@@ -352,6 +374,8 @@ perf can be used to record and analyze trace of programs.
Execution can be recorded using 'perf record' with the cs_etm event,
specifying the name of the sink to record to, e.g:
+.. code:: console
+
perf record -e cs_etm/@20070000.etr/u --per-thread
The 'perf report' and 'perf script' commands can be used to analyze execution,
@@ -370,12 +394,16 @@ Generating coverage files for Feedback Directed Optimization: AutoFDO
'perf inject' accepts the --itrace option in which case tracing data is
removed and replaced with the synthesized events. e.g.
+.. code:: console
+
perf inject --itrace --strip -i perf.data -o perf.data.new
Below is an example of using ARM ETM for autoFDO. It requires autofdo
(https://github.com/google/autofdo) and gcc version 5. The bubble
sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tutorial).
+.. code:: console
+
$ gcc-5 -O3 sort.c -o sort
$ taskset -c 2 ./sort
Bubble sorting array of 30000 elements
@@ -403,28 +431,36 @@ difference is that clients are driving the trace capture rather
than the program flow through the code.
As with any other CoreSight component, specifics about the STM tracer can be
-found in sysfs with more information on each entry being found in [1]:
+found in sysfs with more information on each entry being found in [#first]_:
-root@genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
-enable_source hwevent_select port_enable subsystem uevent
-hwevent_enable mgmt port_select traceid
-root@genericarmv8:~#
+.. code:: console
+
+ root@genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
+ enable_source hwevent_select port_enable subsystem uevent
+ hwevent_enable mgmt port_select traceid
+ root@genericarmv8:~#
Like any other source a sink needs to be identified and the STM enabled before
being used:
-root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
-root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
+.. code:: console
+
+ root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
+ root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
From there user space applications can request and use channels using the devfs
interface provided for that purpose by the generic STM API:
-root@genericarmv8:~# ls -l /dev/20100000.stm
-crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm
-root@genericarmv8:~#
+.. code:: console
+
+ root@genericarmv8:~# ls -l /dev/20100000.stm
+ crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm
+ root@genericarmv8:~#
+
+Details on how to use the generic STM API can be found here [#second]_.
+
+.. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
-Details on how to use the generic STM API can be found here [2].
+.. [#second] Documentation/trace/stm.rst
-[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
-[2]. Documentation/trace/stm.rst
-[3]. https://github.com/Linaro/perf-opencsd
+.. [#third] https://github.com/Linaro/perf-opencsd
diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst
index 6b4107cf4b98..3330c5456bcb 100644
--- a/Documentation/trace/index.rst
+++ b/Documentation/trace/index.rst
@@ -23,3 +23,4 @@ Linux Tracing Technologies
intel_th
stm
sys-t
+ coresight
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v6 02/18] kunit: test: add test resource management API
From: Luis Chamberlain @ 2019-07-05 20:45 UTC (permalink / raw)
To: Brendan Higgins
Cc: frowand.list, gregkh, jpoimboe, keescook, kieran.bingham, peterz,
robh, sboyd, shuah, tytso, yamada.masahiro, devicetree, dri-devel,
kunit-dev, linux-doc, linux-fsdevel, linux-kbuild, linux-kernel,
linux-kselftest, linux-nvdimm, linux-um, Alexander.Levin,
Tim.Bird, amir73il, dan.carpenter, daniel, jdike, joel,
julia.lawall, khilman, knut.omang, logang, mpe, pmladek, rdunlap,
richard, rientjes, rostedt, wfg
In-Reply-To: <20190704003615.204860-3-brendanhiggins@google.com>
On Wed, Jul 03, 2019 at 05:35:59PM -0700, Brendan Higgins wrote:
> diff --git a/kunit/test.c b/kunit/test.c
> index c030ba5a43e40..a70fbe449e922 100644
> --- a/kunit/test.c
> +++ b/kunit/test.c
> @@ -122,7 +122,8 @@ static void kunit_print_test_case_ok_not_ok(struct kunit_case *test_case,
>
> void kunit_init_test(struct kunit *test, const char *name)
> {
> - spin_lock_init(&test->lock);
Once you re-spin, this above line should be removed.
> + mutex_init(&test->lock);
> + INIT_LIST_HEAD(&test->resources);
> test->name = name;
> test->success = true;
> }
Luis
^ permalink raw reply
* Re: [PATCH v6 17/18] kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec()
From: Luis Chamberlain @ 2019-07-05 20:45 UTC (permalink / raw)
To: Brendan Higgins
Cc: frowand.list, gregkh, jpoimboe, keescook, kieran.bingham, peterz,
robh, sboyd, shuah, tytso, yamada.masahiro, devicetree, dri-devel,
kunit-dev, linux-doc, linux-fsdevel, linux-kbuild, linux-kernel,
linux-kselftest, linux-nvdimm, linux-um, Alexander.Levin,
Tim.Bird, amir73il, dan.carpenter, daniel, jdike, joel,
julia.lawall, khilman, knut.omang, logang, mpe, pmladek, rdunlap,
richard, rientjes, rostedt, wfg, Iurii Zaikin
In-Reply-To: <20190704003615.204860-18-brendanhiggins@google.com>
On Wed, Jul 03, 2019 at 05:36:14PM -0700, Brendan Higgins wrote:
> From: Iurii Zaikin <yzaikin@google.com>
>
> KUnit tests for initialized data behavior of proc_dointvec that is
> explicitly checked in the code. Includes basic parsing tests including
> int min/max overflow.
>
> Signed-off-by: Iurii Zaikin <yzaikin@google.com>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Luis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox