Re: perf: WARNING perfevents: irq loop stuck!
* Vince Weaver wrote:
> So this is just a warning, and I've reported it before, but the
> perf_fuzzer triggers this fairly regularly on my Haswell system.
>
> It looks like fixed counter 0 (retired instructions) being set to
> fffe occasionally causes an irq loop storm and gets
> stuck until the PMU state is cleared.
So fffe corresponds to 2 events left until overflow,
right? And on Haswell we don't set x86_pmu.limit_period AFAICS, so we
allow these super short periods.
Maybe like on Broadwell we need a quirk on Nehalem/Haswell as well,
one similar to bdw_limit_period()? Something like the patch below?
Totally untested and such. I picked 128 because of Broadwell, but
lower values might work as well. You could try to increase it to 3 and
upwards and see which one stops triggering stuck NMI loops?
Thanks,
Ingo
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/cpu/perf_event_intel.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index 960e85de13fb..26b13ea8299c 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2479,6 +2479,15 @@ hsw_get_event_constraints(struct cpu_hw_events *cpuc,
int idx,
return c;
}
+/*
+ * Really short periods might create infinite PMC NMI loops on Haswell,
+ * so limit them to 128. There's no official erratum for this AFAIK.
+ */
+static unsigned int hsw_limit_period(struct perf_event *event, unsigned int
left)
+{
+ return max(left, 128U);
+}
+
/*
* Broadwell:
@@ -2495,7 +2504,7 @@ hsw_get_event_constraints(struct cpu_hw_events *cpuc, int
idx,
* Therefore the effective (average) period matches the requested period,
* despite coarser hardware granularity.
*/
-static unsigned bdw_limit_period(struct perf_event *event, unsigned left)
+static unsigned int bdw_limit_period(struct perf_event *event, unsigned left)
{
if ((event->hw.config & INTEL_ARCH_EVENT_MASK) ==
X86_CONFIG(.event=0xc0, .umask=0x01)) {
@@ -3265,6 +3274,7 @@ __init int intel_pmu_init(void)
x86_pmu.hw_config = hsw_hw_config;
x86_pmu.get_event_constraints = hsw_get_event_constraints;
x86_pmu.cpu_events = hsw_events_attrs;
+ x86_pmu.limit_period = hsw_limit_period;
x86_pmu.lbr_double_abort = true;
pr_cont("Haswell events, ");
break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/6] crypto: drbg - add async seeding operation
Am Freitag, 1. Mai 2015, 11:13:31 schrieb Herbert Xu: Hi Herbert, >On Tue, Apr 28, 2015 at 05:00:03AM +0200, Stephan Mueller wrote: >> @@ -1081,6 +1115,11 @@ static int drbg_seed(struct drbg_state *drbg, struct >> drbg_string *pers,> >> return -EINVAL; >> >> } >> >> +/* cancel any previously invoked seeding */ >> +mutex_unlock(&drbg->drbg_mutex); >> +drbg_async_work_cancel(&drbg->seed_work); >> +mutex_lock(&drbg->drbg_mutex); > >This seems dangerous and unnecessary. Releasing and reacquiring >the locks may invalidate previous checks. Even if it doesn't >matter today if somebody modifies the callers later on this could >explode. Agreed. > >You can easily remove this by making get_blocking_random_bytes_cb >idempotent, i.e., do nothing if the work is already queued, which >is what it would do anyway if you simply move the INIT_WORK out of >it. As the get_blocking_random_bytes_cb fully sets up the random_work data structure, I think INIT_WORK should be left in there to have a nice and easy API. Otherwise either a new call would need to be added to random.c. The caller is not able to invoke INIT_WORK himself as the worker function is static. However, what about simply checking if rw->work is NULL and only then performing the INIT_WORK? In that case then, I guess that all the members of random_walk in get_blocking_random_bytes_cb should only be filled in if INIT_WORK is to be called as otherwise a race may occur: get_blocking_random_bytes_work already performs its operation on the data in the supplied random_work and in the middle of that work, and then we would change it with a new call to get_blocking_random_bytes_cb. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase.
On 1 May 2015 at 01:13, Marek Vasut wrote: > On Thursday, April 30, 2015 at 11:13:12 PM, Michal Suchanek wrote: >> The sector size of the flash memory is unclear from datasheet or may >> possibly vary between chips so add a flag to always use 4k blocks. >> >> Currently 4k blocks are always used when possible but in the future >> somebody might want to do some optimizations with sector erase. >> >> Signed-off-by: Michal Suchanek > > I _think_ you might be able to determine the size, no ? > > One way is to ask the vendor, but you can also try something like: > 1) erase the whole SPI NOR > 2) overwrite it with zeroes (or ones ? I think it should be all ones after > erasing). > 3) Erase sector 0 > 4) Read some 128 KiB back > 5) Observe what is the difference. > I can determine it for this particular chip. However, when the vendor datasheet says the block is 64/32K it might mean that chips with this ID can have either block size. It's a value that we don't use anyway so I just mark it as unknown here for future reference. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 0/4] perf: Enable symbolic event names
Implement ability to specify Power PMU events by their symbolic event names rather than raw codes. This approach pulls tables of the Power7 and Power8 PMU events into the perf source tree and uses these tables to create aliases for the PMU events. With these aliases users can run: perf stat -e PM_1PLUS_PPC_CMPL:ku sleep 1 or perf stat -e cpu/PM_VSU_SINGLE/ sleep 1 This is an early POC patchset based on discussions with Jiri Olsa, Michael Ellerman and Ingo Molnar. Lightly tested on Power7 and Power8. Can other architectures can implement arch_get_events_table() and similarly use symoblic event names? I am also assuming that if the header files like power8-events.h are easily readable, we don't need the JSON files anymore? TODO: - Maybe translate event names to lower-case? - Allow perf to process event descriptions (need Andi Kleen's patch) Sukadev Bhattiprolu (4): perf: Create a table of Power7 PMU events perf: Create a table of Power8 PMU events perf/powerpc: Move mfspr and friends to header file perf: Create aliases for Power PMU events tools/perf/arch/powerpc/util/Build |2 +- tools/perf/arch/powerpc/util/header.c|9 +- tools/perf/arch/powerpc/util/header.h|9 + tools/perf/arch/powerpc/util/pmu-events.c| 52 + tools/perf/arch/powerpc/util/pmu-events.h| 17 + tools/perf/arch/powerpc/util/power7-events.h | 3315 + tools/perf/arch/powerpc/util/power8-events.h | 6408 ++ tools/perf/util/pmu.c| 77 + tools/perf/util/pmu.h| 10 + 9 files changed, 9890 insertions(+), 9 deletions(-) create mode 100644 tools/perf/arch/powerpc/util/header.h create mode 100644 tools/perf/arch/powerpc/util/pmu-events.c create mode 100644 tools/perf/arch/powerpc/util/pmu-events.h create mode 100644 tools/perf/arch/powerpc/util/power7-events.h create mode 100644 tools/perf/arch/powerpc/util/power8-events.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 1/4] perf: Create a table of Power7 PMU events
This table will be used in a follow-on patch to allow specifying
Power7 events by name rather than by their raw codes.
Signed-off-by: Sukadev Bhattiprolu
---
tools/perf/arch/powerpc/util/power7-events.h | 3315 ++
1 file changed, 3315 insertions(+)
create mode 100644 tools/perf/arch/powerpc/util/power7-events.h
diff --git a/tools/perf/arch/powerpc/util/power7-events.h
b/tools/perf/arch/powerpc/util/power7-events.h
new file mode 100644
index 000..a2f928b
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/power7-events.h
@@ -0,0 +1,3315 @@
+#ifndef __POWER7_EVENTS_H__
+#define __POWER7_EVENTS_H__
+
+/*
+* File:power7_events.h
+* CVS:
+* Author: Corey Ashford
+* cjash...@us.ibm.com
+* Mods:Sukadev Bhattiprolu
+* suka...@linux.vnet.ibm.com
+* Mods:
+*
+*
+* (C) Copyright IBM Corporation, 2009. All Rights Reserved.
+* Contributed by Corey Ashford
+*
+* Note: This code was generated based on power7-events.h in libpfm4
+*
+* Documentation on the PMU events can be found at:
+* http://www.power.org/documentation/comprehensive-pmu-event-reference-power7
+*/
+
+static const struct perf_pmu_event power7_pmu_events[] = {
+{
+ .name = "PM_IC_DEMAND_L2_BR_ALL",
+ .code = 0x4898,
+ .short_desc = " L2 I cache demand request due to BHT or redirect",
+ .long_desc = " L2 I cache demand request due to BHT or redirect",
+},
+{
+ .name = "PM_GCT_UTIL_7_TO_10_SLOTS",
+ .code = 0x20a0,
+ .short_desc = "GCT Utilization 7-10 entries",
+ .long_desc = "GCT Utilization 7-10 entries",
+},
+{
+ .name = "PM_PMC2_SAVED",
+ .code = 0x10022,
+ .short_desc = "PMC2 Rewind Value saved",
+ .long_desc = "PMC2 was counting speculatively. The speculative
condition was met and the counter value was committed by copying it to the
backup register.",
+},
+{
+ .name = "PM_CMPLU_STALL_DFU",
+ .code = 0x2003c,
+ .short_desc = "Completion stall caused by Decimal Floating Point Unit",
+ .long_desc = "Completion stall caused by Decimal Floating Point Unit",
+},
+{
+ .name = "PM_VSU0_16FLOP",
+ .code = 0xa0a4,
+ .short_desc = "Sixteen flops operation (SP vector versions of
fdiv,fsqrt) ",
+ .long_desc = "Sixteen flops operation (SP vector versions of
fdiv,fsqrt) ",
+},
+{
+ .name = "PM_MRK_LSU_DERAT_MISS",
+ .code = 0x3d05a,
+ .short_desc = "Marked DERAT Miss",
+ .long_desc = "Marked DERAT Miss",
+},
+{
+ .name = "PM_MRK_ST_CMPL",
+ .code = 0x10034,
+ .short_desc = "marked store finished (was complete)",
+ .long_desc = "A sampled store has completed (data home)",
+},
+{
+ .name = "PM_NEST_PAIR3_ADD",
+ .code = 0x40881,
+ .short_desc = " Nest events (MC0/MC1/PB/GX), Pair3 ADD",
+ .long_desc = " Nest events (MC0/MC1/PB/GX), Pair3 ADD",
+},
+{
+ .name = "PM_L2_ST_DISP",
+ .code = 0x46180,
+ .short_desc = "All successful store dispatches",
+ .long_desc = "All successful store dispatches",
+},
+{
+ .name = "PM_L2_CASTOUT_MOD",
+ .code = 0x16180,
+ .short_desc = "L2 Castouts - Modified (M, Mu, Me)",
+ .long_desc = "An L2 line in the Modified state was castout. Total for
all slices.",
+},
+{
+ .name = "PM_ISEG",
+ .code = 0x20a4,
+ .short_desc = "ISEG Exception",
+ .long_desc = "ISEG Exception",
+},
+{
+ .name = "PM_MRK_INST_TIMEO",
+ .code = 0x40034,
+ .short_desc = "marked Instruction finish timeout ",
+ .long_desc = "The number of instructions finished since the last
progress indicator from a marked instruction exceeded the threshold. The marked
instruction was flushed.",
+},
+{
+ .name = "PM_L2_RCST_DISP_FAIL_ADDR",
+ .code = 0x36282,
+ .short_desc = " L2 RC store dispatch attempt failed due to address
collision with RC/CO/SN/SQ",
+ .long_desc = " L2 RC store dispatch attempt failed due to address
collision with RC/CO/SN/SQ",
+},
+{
+ .name = "PM_LSU1_DC_PREF_STREAM_CONFIRM",
+ .code = 0xd0b6,
+ .short_desc = "LS1 'Dcache prefetch stream confirmed",
+ .long_desc = "LS1 'Dcache prefetch stream confirmed",
+},
+{
+ .name = "PM_IERAT_WR_64K",
+ .code = 0x40be,
+ .short_desc = "large page 64k ",
+ .long_desc = "large page 64k ",
+},
+{
+ .name = "PM_MRK_DTLB_MISS_16M",
+ .code = 0x4d05e,
+ .short_desc = "Marked Data TLB misses for 16M page",
+ .long_desc = "Data TLB references to 16M pages by a marked instruction
that missed the TLB. Page size is determined at TLB reload time.",
+},
+{
+ .name = "PM_IERAT_MISS",
+ .code = 0x100f6,
+ .short_desc = "IERAT Miss (Not implemented as DI on POWER6)",
+ .long_desc = "A translation request missed the Instruction Effective to
Real Address Translation (ERAT) table",
+},
+{
+ .name = "PM_MRK_PTEG_FROM_LMEM",
+ .code = 0x4d052,
[RFC][PATCH 3/4] perf/powerpc: Move mfspr and friends to header file
mfspr() and related macros will be needed in two separate files.
Move these defintions to a common header file.
Signed-off-by: Sukadev Bhattiprolu
---
tools/perf/arch/powerpc/util/header.c |9 +
tools/perf/arch/powerpc/util/header.h |9 +
2 files changed, 10 insertions(+), 8 deletions(-)
create mode 100644 tools/perf/arch/powerpc/util/header.h
diff --git a/tools/perf/arch/powerpc/util/header.c
b/tools/perf/arch/powerpc/util/header.c
index 6c1b8a7..05d3fc8 100644
--- a/tools/perf/arch/powerpc/util/header.c
+++ b/tools/perf/arch/powerpc/util/header.c
@@ -6,14 +6,7 @@
#include "../../util/header.h"
#include "../../util/util.h"
-
-#define mfspr(rn) ({unsigned long rval; \
-asm volatile("mfspr %0," __stringify(rn) \
- : "=r" (rval)); rval; })
-
-#define SPRN_PVR0x11F /* Processor Version Register */
-#define PVR_VER(pvr)(((pvr) >> 16) & 0x) /* Version field */
-#define PVR_REV(pvr)(((pvr) >> 0) & 0x) /* Revison field */
+#include "header.h"
int
get_cpuid(char *buffer, size_t sz)
diff --git a/tools/perf/arch/powerpc/util/header.h
b/tools/perf/arch/powerpc/util/header.h
new file mode 100644
index 000..b9d3a0d
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/header.h
@@ -0,0 +1,9 @@
+#include "../../util/util.h" // __stringify
+
+#define mfspr(rn) ({unsigned long rval; \
+asm volatile("mfspr %0," __stringify(rn) \
+ : "=r" (rval)); rval; })
+
+#define SPRN_PVR0x11F /* Processor Version Register */
+#define PVR_VER(pvr)(((pvr) >> 16) & 0x) /* Version field */
+#define PVR_REV(pvr)(((pvr) >> 0) & 0x) /* Revison field */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 4/4] perf: Create aliases for PMU events
Using the tables of Power7 and Power8 events, create aliases for the
Power PMU events. This would allow us to specify all Power events by
name rather than by raw code:
$ /tmp/perf stat -e PM_1PLUS_PPC_CMPL sleep 1
Performance counter stats for 'sleep 1':
757,661 PM_1PLUS_PPC_CMPL
1.001620145 seconds time elapsed
The perf binary built on Power8 can be copied to Power7 and it will use
the Power7 events (if arch/powerpc/util/pmu-events.h knows the CPU string).
Hopefully other architecutres can also implement arch_get_events_table()
and take advantage of this.
Signed-off-by: Sukadev Bhattiprolu
---
tools/perf/arch/powerpc/util/Build|2 +-
tools/perf/arch/powerpc/util/pmu-events.c | 52 +++
tools/perf/arch/powerpc/util/pmu-events.h | 17 +++
tools/perf/util/pmu.c | 77 +
tools/perf/util/pmu.h | 10
5 files changed, 157 insertions(+), 1 deletion(-)
create mode 100644 tools/perf/arch/powerpc/util/pmu-events.c
create mode 100644 tools/perf/arch/powerpc/util/pmu-events.h
diff --git a/tools/perf/arch/powerpc/util/Build
b/tools/perf/arch/powerpc/util/Build
index 0af6e9b..52fbc7f 100644
--- a/tools/perf/arch/powerpc/util/Build
+++ b/tools/perf/arch/powerpc/util/Build
@@ -1,4 +1,4 @@
-libperf-y += header.o
+libperf-y += header.o pmu-events.o
libperf-$(CONFIG_DWARF) += dwarf-regs.o
libperf-$(CONFIG_DWARF) += skip-callchain-idx.o
diff --git a/tools/perf/arch/powerpc/util/pmu-events.c
b/tools/perf/arch/powerpc/util/pmu-events.c
new file mode 100644
index 000..7036f6d
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/pmu-events.c
@@ -0,0 +1,52 @@
+#include
+#include
+#include
+#include "pmu.h"
+#include "pmu-events.h"
+#include "../../util/debug.h" /* verbose */
+#include "header.h"/* mfspr */
+
+static char *get_cpu_str(void)
+{
+ char *bufp;
+
+ if (asprintf(&bufp, "%.8lx-core", mfspr(SPRN_PVR)) < 0)
+ bufp = NULL;
+
+ return bufp;
+}
+
+struct perf_pmu_event *arch_get_events_table(char *cpustr)
+{
+ int i, nmaps, must_free;
+ struct perf_pmu_event *table;
+
+ must_free = 0;
+ if (!cpustr) {
+ cpustr = get_cpu_str();
+ if (!cpustr)
+ return NULL;
+ must_free = 1;
+ }
+
+ nmaps = sizeof(pvr_events_map) / sizeof(struct pvr_events_map_entry);
+
+ for (i = 0; i < nmaps; i++) {
+ if (!strcmp(pvr_events_map[i].pvr, cpustr))
+ break;
+ }
+
+ table = NULL;
+ if (i < nmaps) {
+ /* pvr_events_map is a const; cast to override */
+ table = (struct perf_pmu_event *)pvr_events_map[i].pmu_events;
+ } else if (verbose) {
+ printf("Unknown CPU %s, ignoring aliases\n", cpustr);
+ }
+
+ if (must_free)
+ free(cpustr);
+
+ return table;
+}
+
diff --git a/tools/perf/arch/powerpc/util/pmu-events.h
b/tools/perf/arch/powerpc/util/pmu-events.h
new file mode 100644
index 000..1daf8e5
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/pmu-events.h
@@ -0,0 +1,17 @@
+/*
+ * Include all Power processor tables that we care about.
+ */
+#include "power7-events.h"
+#include "power8-events.h"
+
+/*
+ * Map a processor version (PVR) to its table of events.
+ */
+struct pvr_events_map_entry {
+ const char *pvr;
+ const struct perf_pmu_event *pmu_events;
+} pvr_events_map[] = {
+ { .pvr = "004d0100-core", .pmu_events = power8_pmu_events },
+ { .pvr = "003f0201-core", .pmu_events = power7_pmu_events }
+};
+
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 4841167..f998d91 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -435,6 +435,80 @@ perf_pmu__get_default_config(struct perf_pmu *pmu
__maybe_unused)
return NULL;
}
+/*
+ * Default arch_get_events_table() is empty.
+ *
+ * Actual implementation is in arch/$(ARCH)/util/pmu-events.c. This
+ * allows architectures could choose what set(s) of events to a) include
+ * in perf binary b) consider for _this_ invocation of perf.
+ *
+ * Eg: For Power, we include both Power7 and Power8 event tables in the
+ * perf binary. But depending on the processor where perf is executed,
+ * either the Power7 or Power8 table is returned.
+ */
+struct perf_pmu_event * __attribute__ ((weak))
+arch_get_events_table(char *cpustr __maybe_unused)
+{
+ return NULL;
+}
+
+static int pmu_add_cpu_aliases(char *cpustr, void *data)
+{
+ struct list_head *head = (struct list_head *)data;
+ struct perf_pmu_alias *alias;
+ int i;
+ struct perf_pmu_event *events_table, *event;
+ struct parse_events_term *term;
+
+ events_table = arch_get_events_table(cpustr);
+ if (!events_table)
+ return 0;
+
Re: [PATCH kernel v9 26/32] powerpc/iommu: Add userspace view of TCE table
On 05/01/2015 02:23 PM, David Gibson wrote:
On Fri, May 01, 2015 at 02:01:17PM +1000, Alexey Kardashevskiy wrote:
On 04/29/2015 04:31 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:50PM +1000, Alexey Kardashevskiy wrote:
In order to support memory pre-registration, we need a way to track
the use of every registered memory region and only allow unregistration
if a region is not in use anymore. So we need a way to tell from what
region the just cleared TCE was from.
This adds a userspace view of the TCE table into iommu_table struct.
It contains userspace address, one per TCE entry. The table is only
allocated when the ownership over an IOMMU group is taken which means
it is only used from outside of the powernv code (such as VFIO).
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v9:
* fixed code flow in error cases added in v8
v8:
* added ENOMEM on failed vzalloc()
---
arch/powerpc/include/asm/iommu.h | 6 ++
arch/powerpc/kernel/iommu.c | 18 ++
arch/powerpc/platforms/powernv/pci-ioda.c | 22 --
3 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 7694546..1472de3 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -111,9 +111,15 @@ struct iommu_table {
unsigned long *it_map; /* A simple allocation bitmap for now */
unsigned long it_page_shift;/* table iommu page size */
struct iommu_table_group *it_table_group;
+ unsigned long *it_userspace; /* userspace view of the table */
A single unsigned long doesn't seem like enough.
Why single? This is an array.
As in single per page.
Sorry, I am not following you here.
It is per IOMMU page. MAP/UNMAP work with IOMMU pages which are fully
backed with either system page or a huge page.
How do you know
which process's address space this address refers to?
It is a current task. Multiple userspaces cannot use the same container/tables.
Where is that enforced?
It is accessed from VFIO DMA map/unmap which are ioctls() to a container's
fd which is per a process. Same for KVM - when it registers IOMMU groups in
KVM, fd's of opened IOMMU groups are passed there. Or I did not understand
the question...
More to the point, that's a VFIO constraint, but it's here affecting
the design of a structure owned by the platform code.
Right. But keeping in mind KVM, I cannot think of any better design here.
[snip]
static void pnv_pci_ioda_setup_opal_tce_kill(struct pnv_phb *phb,
@@ -2062,12 +2071,21 @@ static long pnv_pci_ioda2_create_table(struct
iommu_table_group *table_group,
int nid = pe->phb->hose->node;
__u64 bus_offset = num ? pe->tce_bypass_base : 0;
long ret;
+ unsigned long *uas, uas_cb = sizeof(*uas) * (window_size >> page_shift);
+
+ uas = vzalloc(uas_cb);
+ if (!uas)
+ return -ENOMEM;
I don't see why this is allocated both here as well as in
take_ownership.
Where else? The only alternative is vfio_iommu_spapr_tce but I really do not
want to touch iommu_table fields there.
Well to put it another way, why isn't take_ownership calling create
itself (or at least a common helper).
I am trying to keep DDW stuff away from platform-oriented
arch/powerpc/kernel/iommu.c which main purpose is to implement
iommu_alloc()&co. It already has
I'd rather move it_userspace allocation completely to vfio_iommu_spapr_tce
(should have done earlier, actually), would this be ok?
Clearly the it_userspace table needs to have lifetime which matches
the TCE table itself, so there should be a single function that marks
the beginning of that joint lifetime.
No. it_userspace lives as long as the platform code does not control the
table. For IODA2 it is equal for the lifetime of the table, for
IODA1/P5IOC2 it is not.
Isn't this function used for core-kernel users of the
iommu as well, in which case it shouldn't need the it_userspace.
No. This is an iommu_table_group_ops callback which calls what the platform
code calls (pnv_pci_create_table()) plus allocates this it_userspace thing.
The callback is only called from VFIO.
Ok.
As touched on above it seems more like this should be owned by VFIO
code than the platform code.
Agree now :) I'll move the allocation to VFIO. Thanks!
--
Alexey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/22] perf tools: introduce 'perf bpf' command to load eBPF programs.
* Wang Nan wrote: > This series of patches is an approach to integrate eBPF with perf. Very promising! > After applying these patches, users are allowed to use following > command to load eBPF program compiled by LLVM into kernel: > > $ perf bpf sample_bpf.o Please keep space for a subcommand space as most other perf subcommands do, i.e. make it something like: perf bpf add sample_bpf.o or: perf bpf run sample_bpf.o or: perf bpf load sample_bpf.o So that future subcommands can be added: perf bpf list perf bpf del <...> perf bpf enable <...> perf bpf disable <...> perf bpf help and 'perf bpf' should probably display the help page by default, so if curious perf users stumble into the new subcommand, they get a basic idea about what it's all about. I.e. you should think about the high level subcommand space right now, and pick proper names - because this is going to determine the future usability and the success of the tool to a large degree. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: i2o: Remove unwanted semicolon
On Thu, Apr 30, 2015 at 10:05:00PM +0530, hari prasath wrote: > >>> Greg I am not sure if this needs to go into next release. I send this > >>> patch as checkpatch was complaining about it. May be the owners of this > >>> driver can only decide >>> upon it. Alan cox also mentioned the same > >>> point that its about to be deleted. When you reply to someone's email then the quoted text should have a "> " at the start of the line and the new text should not. Please stop doing it in the reverse way. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Enable deferred error interrupts
* Aravind Gopalakrishnan wrote: > Newer AMD processors can generate deferred errors and can be configured > to generate APIC interrupts on such events. What's the wider context of this? What is it good for? I suspect it's MCE related, but only from the diffstat: > arch/x86/kernel/cpu/mcheck/mce.c | 1 + > arch/x86/kernel/cpu/mcheck/mce_amd.c | 105 > ++- Please provide proper high level description for the changes. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] UV: NMI: insert per_cpu accessor function on uv_hub_nmi.
* George Beshers wrote: > UV: NMI: insert this_cpu_read accessor function on uv_hub_nmi. > > UV NMI was accidently broken by this patch. Broken in what way? > commit e16321709c8270f9803bbfdb51e5e02235078c7f > Author: Christoph Lameter > Date: Sun Aug 17 12:30:41 2014 -0500 That's a rather old patch. Was no upstream kernel tested since ~August last year on UV hardware, or is the bug sporadic? The changelog does not tell us. > This patch insert this_cpu_read() on when accessing the PER_CPU > uv_cpu_nmi variable. Why? What problem does it solve? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/2] crypto: add PKE API
Am Donnerstag, 30. April 2015, 15:36:52 schrieb Tadeusz Struk:
Hi Tadeusz,
>Add Public Key Encryption API.
>
>Signed-off-by: Tadeusz Struk
>---
> crypto/Kconfig |6 +
> crypto/Makefile|1
> crypto/crypto_user.c | 23 +
> crypto/pke.c | 114 ++
> include/crypto/algapi.h|6 +
> include/linux/crypto.h | 191
> include/linux/cryptouser.h |
>7 ++
> 7 files changed, 347 insertions(+), 1 deletion(-)
> create mode 100644 crypto/pke.c
>
>diff --git a/crypto/Kconfig b/crypto/Kconfig
>index 8aaf298..9a14b33 100644
>--- a/crypto/Kconfig
>+++ b/crypto/Kconfig
>@@ -87,6 +87,12 @@ config CRYPTO_PCOMP2
> tristate
> select CRYPTO_ALGAPI2
>
>+config CRYPTO_PKE
>+ tristate "Public Key Algorithms API"
>+ select CRYPTO_ALGAPI
>+ help
>+Crypto API interface for public key algorithms.
>+
> config CRYPTO_MANAGER
> tristate "Cryptographic algorithm manager"
> select CRYPTO_MANAGER2
>diff --git a/crypto/Makefile b/crypto/Makefile
>index 97b7d3a..e7dd283 100644
>--- a/crypto/Makefile
>+++ b/crypto/Makefile
>@@ -27,6 +27,7 @@ crypto_hash-y += shash.o
> obj-$(CONFIG_CRYPTO_HASH2) += crypto_hash.o
>
> obj-$(CONFIG_CRYPTO_PCOMP2) += pcompress.o
>+obj-$(CONFIG_CRYPTO_PKE) += pke.o
>
> cryptomgr-y := algboss.o testmgr.o
>
>diff --git a/crypto/crypto_user.c b/crypto/crypto_user.c
>index 41dfe76..83b4d0f 100644
>--- a/crypto/crypto_user.c
>+++ b/crypto/crypto_user.c
>@@ -110,6 +110,23 @@ nla_put_failure:
> return -EMSGSIZE;
> }
>
>+static int crypto_report_pke(struct sk_buff *skb, struct crypto_alg *alg)
>+{
>+ struct crypto_report_pke rpke;
>+
>+ strncpy(rpke.type, "pke", sizeof(rpke.type));
>+ strncpy(rpke.subtype, alg->cra_name, sizeof(rpke.subtype));
>+ rpke.capabilities = alg->cra_pke.capabilities;
>+
>+ if (nla_put(skb, CRYPTOCFGA_REPORT_PKE,
>+ sizeof(struct crypto_report_pke), &rpke))
>+ goto nla_put_failure;
>+ return 0;
>+
>+nla_put_failure:
>+ return -EMSGSIZE;
>+}
>+
> static int crypto_report_one(struct crypto_alg *alg,
>struct crypto_user_alg *ualg, struct sk_buff
*skb)
> {
>@@ -154,6 +171,12 @@ static int crypto_report_one(struct crypto_alg *alg,
> goto nla_put_failure;
>
> break;
>+
>+ case CRYPTO_ALG_TYPE_PKE:
>+ if (crypto_report_pke(skb, alg))
>+ goto nla_put_failure;
>+
>+ break;
> }
>
> out:
>diff --git a/crypto/pke.c b/crypto/pke.c
>new file mode 100644
>index 000..c1350fa
>--- /dev/null
>+++ b/crypto/pke.c
>@@ -0,0 +1,114 @@
>+/*
>+ * Public Key Encryption operations.
>+ *
>+ * Copyright (c) 2015, Intel Corporation
>+ * Authors: Tadeusz Struk
>+ *
>+ * This program is free software; you can redistribute it and/or modify it
>+ * under the terms of the GNU General Public License as published by the
>Free + * Software Foundation; either version 2 of the License, or (at your
>option) + * any later version.
>+ *
>+ */
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include "internal.h"
>+
>+static unsigned int crypto_pke_ctxsize(struct crypto_alg *alg, u32 type,
>+ u32 mask)
>+{
>+ unsigned int len = alg->cra_ctxsize;
>+
>+ return ALIGN(len, (unsigned long)alg->cra_alignmask + 1);
>+}
>+
>+static int crypto_init_pke_ops(struct crypto_tfm *tfm, u32 type, u32 mask)
>+{
>+ struct pke_tfm *crt = &tfm->crt_pke;
>+ struct pke_alg *alg = &tfm->__crt_alg->cra_pke;
>+
>+ if (alg->pub_mpis > 5 || alg->sec_mpis > 5 || alg->sig_mpis > 2)
>+ return -EINVAL;
>+
>+ if ((alg->capabilities & PKEY_CAN_ENCRYPT) && !alg->encrypt)
>+ return -EINVAL;
>+
>+ if ((alg->capabilities & PKEY_CAN_DECRYPT) && !alg->decrypt)
>+ return -EINVAL;
>+
>+ if ((alg->capabilities & PKEY_CAN_SIGN) && !alg->sign)
>+ return -EINVAL;
>+
>+ if ((alg->capabilities & PKEY_CAN_VERIFY) && !alg->verify)
>+ return -EINVAL;
>+
>+ crt->sign = alg->sign;
>+ crt->verify = alg->verify;
>+ crt->encrypt = alg->encrypt;
>+ crt->decrypt = alg->decrypt;
>+ crt->base = __crypto_pke_cast(tfm);
>+
>+ return 0;
>+}
>+
>+#ifdef CONFIG_NET
>+static int crypto_pke_report(struct sk_buff *skb, struct crypto_alg *alg)
>+{
>+ struct crypto_report_pke rep_pke;
>+
>+ strncpy(rep_pke.type, "pke", sizeof(rep_pke.type));
>+ strncpy(rep_pke.subtype, alg->cra_name, sizeof(rep_pke.subtype));
>+ rep_pke.capabilities = alg->cra_pke.capabilities;
>+
>+ if (nla_put(skb, CRYPTOCFGA_REPORT_PKE,
>+ sizeof(struct crypto_report_pke), &rep_pke))
>+ goto nla_put_failure;
>+ return 0;
>+
>+nla_put_failure:
>+ return -EMSGSIZE;
>+}
>+#e
Re: [PATCH 2/2] UV: NMI: simple dump failover if kdump fails
* George Beshers wrote:
> UV: NMI: simple dump failover if kdump fails
>
> The ability to trigger a kdump using the system NMI command
> was added by
>
> commit 12ba6c990fab50fe568f3ad8715e81e356552428
> Author: Mike Travis
> Date: Mon Sep 23 16:25:03 2013 -0500
>
> When kdump is works it is preferable to the set of backtraces
(spelling error)
> that dump provides; however a number of things can go wrong and
> the backtraces are much more useful than nothing.
>
> The two most common reason for kdump not to be available are
(spelling error)
> a problem during boot or the kdump daemon fails to start.
(spelling error)
> In either case the call to crash_kexec() returns unexpectedly;
> when this happens uv_nmi_kdump() also returns with the
> uv_nmi_kexec_failed flag set. This condition now causes a
> standard dump.
'standard dump' == printing an NMI backtrace on all CPUs?
> One other minor change is that dump now generates both the
> show_regs() stack trace and the uv_nmi_dump_ip{,_hdr} information
> that is generated by the "ips" action; the additional information
> has proved to be useful.
Looks like a useful change.
> -/* Dump this cpu's state */
> +/*
> + * Dump this cpu's state. Note that "kdump" only happens
s/CPU's
> + * when crash_kexec() has failed and we are providing the user
> + * a standard dump instead.
So this sentence does not parse for me: kdump only happens if kdump
fails??
> + */
> static void uv_nmi_dump_state_cpu(int cpu, struct pt_regs *regs)
> {
> const char *dots = " . ";
>
> - if (uv_nmi_action_is("ips")) {
> - if (cpu == 0)
> - uv_nmi_dump_cpu_ip_hdr();
> -
> - if (current->pid != 0)
> - uv_nmi_dump_cpu_ip(cpu, regs);
> -
> - } else if (uv_nmi_action_is("dump")) {
> + if (uv_nmi_action_is("dump") || uv_nmi_action_is("kdump")) {
> printk(KERN_DEFAULT
> "UV:%sNMI process trace for CPU %d\n", dots, cpu);
pr_info().
> show_regs(regs);
> }
> +
> + if (cpu == 0)
> + uv_nmi_dump_cpu_ip_hdr();
> +
> + if (current->pid != 0)
> + uv_nmi_dump_cpu_ip(cpu, regs);
What is an 'ip header'? If it's not an Internet IP address then it's
probably horribly named.
> +
> +#if defined(CONFIG_KEXEC)
#ifdef
> @@ -502,9 +507,9 @@ static void uv_nmi_kdump(int cpu, int master, struct
> pt_regs *regs)
> crash_kexec(regs);
>
> pr_emerg("UV: crash_kexec unexpectedly returned, ");
> + atomic_set(&uv_nmi_kexec_failed, 1);
Why is this flag an atomic variable?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ASoC: Add gtm601 codec driver
Just a nit: a license mismatch.
On Thu, 2015-04-30 at 23:28 +0200, Marek Belisko wrote:
> --- /dev/null
> +++ b/sound/soc/codecs/gtm601.c
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
This states the license is GPL v2 or later.
> +MODULE_LICENSE("GPL v2");
And, according to include/linux/module.h, this states the license is
(just) GPL v2. So I think either the comment at the top of this file or
the ident used in the MODULE_LICESE() macro should change.
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: i2o: Remove unwanted semicolon
On Fri, May 01, 2015 at 10:18:14AM +0300, Dan Carpenter wrote: > On Thu, Apr 30, 2015 at 10:05:00PM +0530, hari prasath wrote: > > >>> Greg I am not sure if this needs to go into next release. I send this > > >>> patch as checkpatch was complaining about it. May be the owners of this > > >>> driver can only decide >>> upon it. Alan cox also mentioned the same > > >>> point that its about to be deleted. > Also please line wrap at 72 characters. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: i2o: Remove unwanted semicolon
On Thu, Apr 30, 2015 at 11:25:48PM +0100, One Thousand Gnomes wrote: > On Thu, 30 Apr 2015 16:14:06 +0200 > "gre...@linuxfoundation.org" wrote: > > > On Thu, Apr 23, 2015 at 04:09:28PM +0100, Alan Cox wrote: > > > On Thu, 2015-04-23 at 13:43 +, Gujulan Elango, Hari Prasath (H.) > > > wrote: > > > > This patch removes unwanted semicolon around close braces of code blocks > > > > > > > > > The i2o driver moved into staging ready to be deleted unless someone > > > steps up with hardware willing to maintain it (which is rather > > > unlikely). > > > > I think it's now time to delete these, want me to do that for 4.2? I > > can queue that up in my tree now, so that we don't see any more cleanup > > patches being made for them? > > Yeah I think it can go I was about to delete it, but what about drivers/scsi/dpt/dpti_i2o.* ? Should that be removed as well? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] Add SMP bringup support for mt65xx socs
This series add SMP brinup support for mediatek SoCs. This is based on v4.1-rc1. There are 2 similar but different SMP bringup up methods on Mediatek mt65xx and mt81xx. On MT8135 & MT8127, system boots with a trustzone firmware. Others, like MT6589, doesn't have trustzone, and run kernel directly in secure world. Patch 1~3 fix issues in mtk_timer(GPT) and enable arch timer support. Patch 4,5 add support for cpu enable-method "mediatek,mt65xx-smp" and "mediatek,mt81xx-tz-smp", which support Mediatek SMP bringup for non-TZ and TZ platform. Patch 6,7 finally enable SMP bringup for mt8135 and mt8127. Matthias Brugger (1): arm: mediatek: enable gpt6 on boot up to make arch timer working Yingjoe Chen (6): clocksource: mediatek: Don't run event_handler if it is NULL clocksource: mediatek: Use GPT as sched clock source devicetree: bindings: add new SMP enable method Mediatek SoC ARM: mediatek: add smp bringup code ARM: dts: mt8135: enable basic SMP bringup for mt8135 ARM: dts: mt8127: enable basic SMP bringup for mt8127 Documentation/devicetree/bindings/arm/cpus.txt | 2 + arch/arm/boot/dts/mt8127.dtsi | 16 +++ arch/arm/boot/dts/mt8135.dtsi | 16 +++ arch/arm/mach-mediatek/Makefile| 3 + arch/arm/mach-mediatek/mediatek.c | 29 + arch/arm/mach-mediatek/platsmp.c | 145 + drivers/clocksource/mtk_timer.c| 13 ++- 7 files changed, 223 insertions(+), 1 deletion(-) create mode 100644 arch/arm/mach-mediatek/platsmp.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] clocksource: mediatek: Don't run event_handler if it is NULL
Spurious timer interrupt is noticed in mtk timer and cause kernel crash. In mtk_timer_interrupt(), only run event_handler if it is not NULL. Signed-off-by: Yingjoe Chen --- drivers/clocksource/mtk_timer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c index 68ab423..85e0ab5 100644 --- a/drivers/clocksource/mtk_timer.c +++ b/drivers/clocksource/mtk_timer.c @@ -143,7 +143,8 @@ static irqreturn_t mtk_timer_interrupt(int irq, void *dev_id) /* Acknowledge timer0 irq */ writel(GPT_IRQ_ACK(GPT_CLK_EVT), evt->gpt_base + GPT_IRQ_ACK_REG); - evt->dev.event_handler(&evt->dev); + if (evt->dev.event_handler) + evt->dev.event_handler(&evt->dev); return IRQ_HANDLED; } -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] clocksource: mediatek: Use GPT as sched clock source
When cpu is in deep idle, arch timer will stop counting. Setup GPT as
sched clock source so it can keep counting in idle.
Signed-off-by: Yingjoe Chen
---
drivers/clocksource/mtk_timer.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
index 85e0ab5..9a90c7b 100644
--- a/drivers/clocksource/mtk_timer.c
+++ b/drivers/clocksource/mtk_timer.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#define GPT_IRQ_EN_REG 0x00
@@ -59,6 +60,13 @@ struct mtk_clock_event_device {
struct clock_event_device dev;
};
+static void __iomem *gpt_base __read_mostly;
+
+static u64 notrace mtk_read_sched_clock(void)
+{
+ return readl_relaxed(gpt_base + TIMER_CNT_REG(GPT_CLK_SRC));
+}
+
static inline struct mtk_clock_event_device *to_mtk_clk(
struct clock_event_device *c)
{
@@ -239,6 +247,8 @@ static void __init mtk_timer_init(struct device_node *node)
mtk_timer_setup(evt, GPT_CLK_SRC, TIMER_CTRL_OP_FREERUN);
clocksource_mmio_init(evt->gpt_base + TIMER_CNT_REG(GPT_CLK_SRC),
node->name, rate, 300, 32, clocksource_mmio_readl_up);
+ gpt_base = evt->gpt_base;
+ sched_clock_register(mtk_read_sched_clock, 32, rate);
/* Configure clock event */
mtk_timer_setup(evt, GPT_CLK_EVT, TIMER_CTRL_OP_REPEAT);
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] ARM: dts: mt8127: enable basic SMP bringup for mt8127
Add arch timer node to enable arch-timer support. MT8127 firmware
doesn't correctly setup arch-timer frequency and CNTVOFF, add
properties to workaround this.
This also set cpu enable-method to enable SMP.
Signed-off-by: Yingjoe Chen
---
arch/arm/boot/dts/mt8127.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/mt8127.dtsi b/arch/arm/boot/dts/mt8127.dtsi
index aaa7862..7c2090d 100644
--- a/arch/arm/boot/dts/mt8127.dtsi
+++ b/arch/arm/boot/dts/mt8127.dtsi
@@ -23,6 +23,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "mediatek,mt81xx-tz-smp";
cpu@0 {
device_type = "cpu";
@@ -72,6 +73,21 @@
};
};
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupt-parent = <&gic>;
+ interrupts = ,
+,
+,
+;
+ clock-frequency = <1300>;
+ arm,cpu-registers-not-fw-configured;
+ };
+
soc {
#address-cells = <2>;
#size-cells = <2>;
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] arm: mediatek: enable gpt6 on boot up to make arch timer working
From: Matthias Brugger
We enable GTP6 which ungates the arch timer clock.
In the future this should be done in the bootloader.
Signed-off-by: Matthias Brugger
Signed-off-by: Yingjoe Chen
---
arch/arm/mach-mediatek/mediatek.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/mach-mediatek/mediatek.c
b/arch/arm/mach-mediatek/mediatek.c
index a954900..6b38d67 100644
--- a/arch/arm/mach-mediatek/mediatek.c
+++ b/arch/arm/mach-mediatek/mediatek.c
@@ -16,6 +16,34 @@
*/
#include
#include
+#include
+#include
+#include
+
+
+#define GPT6_CON_MT65xx 0x10008060
+#define GPT_ENABLE 0x31
+
+static void __init mediatek_timer_init(void)
+{
+ void __iomem *gpt_base = 0;
+
+ if (of_machine_is_compatible("mediatek,mt6589") ||
+ of_machine_is_compatible("mediatek,mt8135") ||
+ of_machine_is_compatible("mediatek,mt8127")) {
+ /* turn on GPT6 which ungates arch timer clocks */
+ gpt_base = ioremap(GPT6_CON_MT65xx, 0x04);
+ }
+
+ /* enabel clock and set to free-run */
+ if (gpt_base) {
+ writel(GPT_ENABLE, gpt_base);
+ iounmap(gpt_base);
+ }
+
+ of_clk_init(NULL);
+ clocksource_of_init();
+};
static const char * const mediatek_board_dt_compat[] = {
"mediatek,mt6589",
@@ -27,4 +55,5 @@ static const char * const mediatek_board_dt_compat[] = {
DT_MACHINE_START(MEDIATEK_DT, "Mediatek Cortex-A7 (Device Tree)")
.dt_compat = mediatek_board_dt_compat,
+ .init_time = mediatek_timer_init,
MACHINE_END
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] ARM: mediatek: add smp bringup code
Add support for booting secondary CPUs on mt6589, mt8127
and mt8135.
Signed-off-by: Yingjoe Chen
---
arch/arm/mach-mediatek/Makefile | 3 +
arch/arm/mach-mediatek/platsmp.c | 145 +++
2 files changed, 148 insertions(+)
create mode 100644 arch/arm/mach-mediatek/platsmp.c
diff --git a/arch/arm/mach-mediatek/Makefile b/arch/arm/mach-mediatek/Makefile
index 43e619f..2116460 100644
--- a/arch/arm/mach-mediatek/Makefile
+++ b/arch/arm/mach-mediatek/Makefile
@@ -1 +1,4 @@
+ifeq ($(CONFIG_SMP),y)
+obj-$(CONFIG_ARCH_MEDIATEK) += platsmp.o
+endif
obj-$(CONFIG_ARCH_MEDIATEK) += mediatek.o
diff --git a/arch/arm/mach-mediatek/platsmp.c b/arch/arm/mach-mediatek/platsmp.c
new file mode 100644
index 000..e266b3d
--- /dev/null
+++ b/arch/arm/mach-mediatek/platsmp.c
@@ -0,0 +1,145 @@
+/*
+ * arch/arm/mach-mediatek/platsmp.c
+ *
+ * Copyright (c) 2014 Mediatek Inc.
+ * Author: Shunli Wang
+ * Yingjoe Chen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MTK_MAX_CPU8
+#define MTK_SMP_REG_SIZE 0x1000
+
+struct mtk_smp_boot_info {
+ unsigned long smp_base;
+ unsigned int jump_reg;
+ unsigned int boot_reg;
+ unsigned int core_keys[MTK_MAX_CPU - 1];
+ unsigned int core_regs[MTK_MAX_CPU - 1];
+};
+
+static const struct mtk_smp_boot_info mtk_mt8135_tz_boot = {
+ 0x80002000, 1020, 1012,
+ { 0x534c4131, 0x4c415332, 0x41534c33 },
+ { 1016, 1016, 1016},
+};
+
+static const struct mtk_smp_boot_info mtk_mt6589_boot = {
+ 0x10002000, 0x34, 0x30,
+ { 0x534c4131, 0x4c415332, 0x41534c33 },
+ { 0x38, 0x3c, 0x40 },
+};
+
+static const struct of_device_id mtk_tz_smp_boot_infos[] __initconst = {
+ { .compatible = "mediatek,mt8135", .data = &mtk_mt8135_tz_boot },
+ { .compatible = "mediatek,mt8127", .data = &mtk_mt8135_tz_boot },
+};
+
+static const struct of_device_id mtk_smp_boot_infos[] __initconst = {
+ { .compatible = "mediatek,mt6589", .data = &mtk_mt6589_boot },
+};
+
+static void __iomem *mtk_smp_base;
+static const struct mtk_smp_boot_info *mtk_smp_info;
+
+static int mtk_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+ if (!mtk_smp_base)
+ return -EINVAL;
+
+ if (!mtk_smp_info->core_keys[cpu-1])
+ return -EINVAL;
+
+ writel_relaxed(mtk_smp_info->core_keys[cpu-1],
+ mtk_smp_base + mtk_smp_info->core_regs[cpu-1]);
+
+ arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+
+ return 0;
+}
+
+static void __init __mtk_smp_prepare_cpus(unsigned int max_cpus, int trustzone)
+{
+ int i, num;
+ const struct of_device_id *infos;
+
+ if (trustzone) {
+ num = ARRAY_SIZE(mtk_tz_smp_boot_infos);
+ infos = mtk_tz_smp_boot_infos;
+ } else {
+ num = ARRAY_SIZE(mtk_smp_boot_infos);
+ infos = mtk_smp_boot_infos;
+ }
+
+ /* Find smp boot info for this SoC */
+ for (i = 0; i < num; i++) {
+ if (of_machine_is_compatible(infos[i].compatible)) {
+ mtk_smp_info = infos[i].data;
+ break;
+ }
+ }
+
+ if (!mtk_smp_info) {
+ pr_err("%s: Device is not supported\n", __func__);
+ return;
+ }
+
+ if (trustzone) {
+ if (memblock_reserve(mtk_smp_info->smp_base, MTK_SMP_REG_SIZE))
{
+ pr_err("%s: Can't reserve smp memory\n", __func__);
+ return;
+ }
+ mtk_smp_base = phys_to_virt(mtk_smp_info->smp_base);
+ } else {
+ mtk_smp_base = ioremap(mtk_smp_info->smp_base,
MTK_SMP_REG_SIZE);
+ if (!mtk_smp_base) {
+ pr_err("%s: Can't remap %lx\n", __func__,
+ mtk_smp_info->smp_base);
+ return;
+ }
+ }
+
+ /*
+* write the address of slave startup address into the system-wide
+* jump register
+*/
+ writel_relaxed(virt_to_phys(secondary_startup),
+ mtk_smp_base + mtk_smp_info->jump_reg);
+}
+
+static void __init mtk_tz_smp_prepare_cpus(unsigned int max_cpus)
+{
+ __mtk_smp_prepare_cpus(max_cpus, 1);
+}
+
+static void __init mtk_smp_prepare_cpus(unsigned int max_cpus)
+{
+ __mtk_smp_prepare_cpus(max_cpus, 0);
+}
+
+static struct smp_operations mt81xx_tz_smp_ops __initdata =
[PATCH 6/7] ARM: dts: mt8135: enable basic SMP bringup for mt8135
Add arch timer node to enable arch-timer support. MT8135 firmware
doesn't correctly setup arch-timer frequency and CNTVOFF, add
properties to workaround this.
This also set cpu enable-method to enable SMP.
Signed-off-by: Yingjoe Chen
---
arch/arm/boot/dts/mt8135.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/mt8135.dtsi b/arch/arm/boot/dts/mt8135.dtsi
index 612bd22..eb5e06f 100644
--- a/arch/arm/boot/dts/mt8135.dtsi
+++ b/arch/arm/boot/dts/mt8135.dtsi
@@ -46,6 +46,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "mediatek,mt81xx-tz-smp";
cpu0: cpu@0 {
device_type = "cpu";
@@ -103,6 +104,21 @@
};
};
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupt-parent = <&gic>;
+ interrupts = ,
+,
+,
+;
+ clock-frequency = <1300>;
+ arm,cpu-registers-not-fw-configured;
+ };
+
soc {
#address-cells = <2>;
#size-cells = <2>;
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] devicetree: bindings: add new SMP enable method Mediatek SoC
This commit add new cpu enable method "mediatek,mt65xx-smp" and "mediatek,mt81xx-tz-smp". Signed-off-by: Yingjoe Chen --- Documentation/devicetree/bindings/arm/cpus.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 6aa331d..ac2903d 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -194,6 +194,8 @@ nodes to be present and contain the properties described below. "marvell,armada-380-smp" "marvell,armada-390-smp" "marvell,armada-xp-smp" + "mediatek,mt65xx-smp" + "mediatek,mt81xx-tz-smp" "qcom,gcc-msm8660" "qcom,kpss-acc-v1" "qcom,kpss-acc-v2" -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH 2/2] regulator: max77843: Convert to use regulator_is_enabled_regmap
2015-05-01 15:17 GMT+09:00 Axel Lin : > Use regulator_is_enabled_regmap() to replace max77843_reg_is_enabled(). > > Signed-off-by: Axel Lin (sending one more time, this time without HTML) I did not update the max77843 driver with such change (as did for max77693) because I think they should be merged: https://lkml.org/lkml/2015/4/29/185 These devices are almost the same. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ARM: dts: Fix pinctrl settings for S2MPS11 RTC alarm IRQ on Arndale Octa
2015-05-01 0:58 GMT+09:00 Kevin Hilman : > Hi Krzystof, > > Krzysztof Kozlowski writes: > >> 2015-04-02 23:36 GMT+09:00 Krzysztof Kozlowski : >>> On Arndale Octa the S2MPS11 RTC alarm interrupt was not handled at all >>> because of wrong configuration of interrupt and gpx3-2. >>> 1. Interrupt is signaled by falling edge. >>> 2. This GPIO line is hard-wired on the board to PVDD_APIO_1V8 through a >>>resistor so pull-up/down must be disabled. >>> >>> Signed-off-by: Krzysztof Kozlowski >>> --- >>> arch/arm/boot/dts/exynos5420-arndale-octa.dts | 13 - >>> 1 file changed, 12 insertions(+), 1 deletion(-) >> >> Dear Kukjin, >> >> Any comments on this and other patches. A lot of emails waits for >> your opinion. Is there anything I could do to help you in smooth >> review or applying? > > IMO, I think you you should just start collecting fixes and features and > queuing them for Kukjin and then start working as a co-maintainer. Seems an interesting and challenging idea. Let's try it and see if it helps. > > The samsung platforms have been in a near constant state of breakage > over the last *several* cycles, and something really needs to change in > how these are being monitored and maintained. We have been struggling with this for some time... It is annoying also to me. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 05/15] dt-bindings: Document the STM32 reset bindings
On 30/04/15 17:20, Maxime Coquelin wrote:
This adds documentation of device tree bindings for the
STM32 reset controller.
Tested-by: Chanwoo Choi
Acked-by: Philipp Zabel
Acked-by: Rob Herring
Signed-off-by: Maxime Coquelin
---
.../devicetree/bindings/reset/st,stm32-rcc.txt | 107 +
1 file changed, 107 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
diff --git a/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
new file mode 100644
index 000..c1b0f8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
@@ -0,0 +1,107 @@
+STMicroelectronics STM32 Peripheral Reset Controller
+
+
+The RCC IP is both a reset and a clock controller. This documentation only
+documents the reset part.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "st,stm32-rcc"
+- reg: should be register base and length as documented in the
+ datasheet
+- #reset-cells: 1, see below
+
+example:
+
+rcc: reset@40023800 {
+ #reset-cells = <1>;
+ compatible = "st,stm32-rcc";
Do you intend the clock driver to use the same compatible string (given
it is the same bit of hardware).
If so, is it better to use st,stm32f4-rcc here? It seems unlikey to me
that the register layout of the PLLs and dividers can be the same on the
f7 parts (and later).
+ reg = <0x40023800 0x400>;
+};
+
+Specifying softreset control of devices
+===
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the reset device node and an index specifying
+which channel to use.
+The index is the bit number within the RCC registers bank, starting from RCC
+base address.
+It is calculated as: index = register_offset / 4 * 32 + bit_offset.
+Where bit_offset is the bit offset within the register.
+For example, for CRC reset:
+ crc = AHB1RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x10 / 4 * 32 + 12 = 140
+
+example:
+
+ timer2 {
+ resets = <&rcc 256>;
+ };
+
+List of valid indices for STM32F429:
+ - gpioa: 128
+ - gpiob: 129
+ - gpioc: 130
+ - gpiod: 131
+ - gpioe: 132
+ - gpiof: 133
+ - gpiog: 134
+ - gpioh: 135
+ - gpioi: 136
+ - gpioj: 137
+ - gpiok: 138
+ - crc: 140
+ - dma1: 149
+ - dma2: 150
+ - dma2d: 151
+ - ethmac: 153
+ - otghs: 157
+ - dcmi: 160
+ - cryp: 164
+ - hash: 165
+ - rng: 166
+ - otgfs: 167
+ - fmc: 192
+ - tim2: 256
+ - tim3: 257
+ - tim4: 258
+ - tim5: 259
+ - tim6: 260
+ - tim7: 261
+ - tim12: 262
+ - tim13: 263
+ - tim14: 264
+ - wwdg: 267
+ - spi2: 270
+ - spi3: 271
+ - uart2: 273
+ - uart3: 274
+ - uart4: 275
+ - uart5: 276
+ - i2c1: 277
+ - i2c2: 278
+ - i2c3: 279
+ - can1: 281
+ - can2: 282
+ - pwr: 284
+ - dac: 285
+ - uart7: 286
+ - uart8: 287
+ - tim1: 288
+ - tim8: 289
+ - usart1: 292
+ - usart6: 293
+ - adc: 296
+ - sdio: 299
+ - spi1: 300
+ - spi4: 301
+ - syscfg: 302
+ - tim9: 304
+ - tim10: 305
+ - tim11: 306
+ - spi5: 308
+ - spi6: 309
+ - sai1: 310
+ - ltdc: 314
These numbers are stable for all STM32F4 family parts. Should this table
go into a dt-bindings header file?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: High-resolution timers not supported when using smp_twd
Hello John, On 30/04/2015 18:42, John Stultz wrote: > On Thu, Apr 30, 2015 at 5:46 AM, Mason wrote: > >> I wanted to enable high-resolution timers on this Cortex A9 system, >> but it seems there is more to it than just enabling >> >> CONFIG_HIGH_RES_TIMERS=y >> >> (The system is limited to jiffy resolution.) > > You might make sure you've got a HRT enabled clocksource installed? > > You might check > /sys/devices/system/clocksource/clocksource0/current_clocksource ? Thanks for the suggestion, I will check on Monday. The clocksource is a constant 27 MHz 32-bit counter. It seems the problem comes from the clockevent source, which is marked CLOCK_EVT_FEAT_C3STOP. If I remove that flag, then hrtimers are enabled; but the flag is there for a good reason, I assume. I will resend my message to the LAKML on Monday. Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] clk: si5351: Some fixes
On 01.05.2015 00:36, Michael Welling wrote: On Fri, May 01, 2015 at 12:21:20AM +0200, Sebastian Hesselbarth wrote: On 30.04.2015 23:20, Michael Welling wrote: On Thu, Apr 30, 2015 at 10:44:07PM +0200, Sebastian Hesselbarth wrote: [...] What I noticed about your clk2 that you always measure as 0 Hz is that none of your clocks is prepared/enabled. Currently, the si5351 driver only ensures the output is enabled when si5351_clkout_prepare() is called. As long as you do not have a clk consumer that properly prepare/enables the clock output, it may remain disabled. We should probably have additional DT properties and corresponding pdata to force clkoutN always on. Does the silabs,disable-state of 3 (SI5351_DISABLE_NEVER) take care of this? That would be the HW version of never disabling the clock output. I never really tried the property, does it work as expected? This did not appear to effect the behavior. I think it is also a good idea to expose register values to debugfs, so we can easily check what is really written into internal registers. Otherwise is there a simple registration that will do this? The SW version of such a property would involve CLK_IGNORE_UNUSED and enabling all requested clock outputs on probe(). If above HW property already works, I think it should be enough. [...] It should be noted that if I program the device's register map in the bootloader the device keeps the correct frequency outputs. "keeps"? You mean "generates", don't you? Yes the clocks are generated and do not get effected by the driver. IIRC, clk API does check if requested rate and current rate match already. If they do, it does not request the same rate again. So I found that the audio codec that I am driving with clk2 could register the clock and allowed the clock to be enabled and disabled by playing audio. This is when I noticed some strange behavior. The first time I attempt to play audio the clock does not turn on blocking the audio from playing. After I interrupt and the clock is disabled for the first time, the successive clock enables work as expected. Does "does not turn on" mean you cannot measure any clock on the output or is it just a guess because audio does not play? It could be that we just need to add some delay when we enable a clock output. Datasheet just says 10us max from OEB pin pulled low to valid clock output - not exactly what we are looking for but it could be a good start. Something tells me that a fault off some kind is occurring on initial configuration. What I noticed when adding the pll reset and checking DEVICE_STATUS is that SYS_INIT is still set. According to the datasheet, the meaning of the bit is that si5351 is still copying NVM content to its internal registers and therefore, we shouldn't try to access them. What really irritates me about it is that it is seconds after power-up and copying the contents shouldn't really take _that_ long. However, the datasheet does not mention anything about how long it may take. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: can: xilinx_can: fix extended frame handling
On 04/29/2015 05:05 PM, Jeppe Ledet-Pedersen wrote: > Using IDR_SRR in RXFIFO_ID to test for the presence of data is only > valid for standard frames. For extended frames the bit is always 1 and > IDR_RTR should be used instead. This patch switches the check to use > CAN_RTR_FLAG which is correctly set when reading the ID. > > The patch also changes the DW1/DW2 to be read unconditionally, since > this is necessary to remove the frame from the RXFIFO. > > Signed-off-by: Jeppe Ledet-Pedersen > Acked-by: Kedareswara rao Appana Applied to can. Added stable on Cc. Thanks, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
[PATCH V3 1/2 linux-next] cpufreq: pxa: replace typedef pxa_freqs_t by structure
typedef is not really useful here. Replace it by structure
to improve readability. typedef should only be used in some cases.
(See Documentation/CodingStyle Chapter 5 for details).
Signed-off-by: Fabian Frederick
---
Compiled but untested.
V3: -constify arrays(patch 2) (suggested by Joe Perches)
-fix typo in changelog (thanks to Viresh Kumar)
V2: -verbose changelog.
drivers/cpufreq/pxa2xx-cpufreq.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/cpufreq/pxa2xx-cpufreq.c b/drivers/cpufreq/pxa2xx-cpufreq.c
index e24269a..fcf6e34 100644
--- a/drivers/cpufreq/pxa2xx-cpufreq.c
+++ b/drivers/cpufreq/pxa2xx-cpufreq.c
@@ -56,7 +56,7 @@ module_param(pxa27x_maxfreq, uint, 0);
MODULE_PARM_DESC(pxa27x_maxfreq, "Set the pxa27x maxfreq in MHz"
"(typically 624=>pxa270, 416=>pxa271, 520=>pxa272)");
-typedef struct {
+struct pxa_freqs {
unsigned int khz;
unsigned int membus;
unsigned int cccr;
@@ -64,7 +64,7 @@ typedef struct {
unsigned int cclkcfg;
int vmin;
int vmax;
-} pxa_freqs_t;
+};
/* Define the refresh period in mSec for the SDRAM and the number of rows */
#define SDRAM_TREF 64 /* standard 64ms SDRAM */
@@ -86,7 +86,7 @@ static unsigned int sdram_rows;
/* Use the run mode frequencies for the CPUFREQ_POLICY_PERFORMANCE policy */
#define CCLKCFGCCLKCFG_TURBO | CCLKCFG_FCS
-static pxa_freqs_t pxa255_run_freqs[] =
+static struct pxa_freqs pxa255_run_freqs[] =
{
/* CPU MEMBUS CCCR DIV2 CCLKCFGrun turbo PXbus
SDRAM */
{ 99500, 99500, 0x121, 1, CCLKCFG, -1, -1}, /* 99, 99, 50,
50 */
@@ -98,7 +98,7 @@ static pxa_freqs_t pxa255_run_freqs[] =
};
/* Use the turbo mode frequencies for the CPUFREQ_POLICY_POWERSAVE policy */
-static pxa_freqs_t pxa255_turbo_freqs[] =
+static struct pxa_freqs pxa255_turbo_freqs[] =
{
/* CPU MEMBUS CCCR DIV2 CCLKCFGrun turbo PXbus SDRAM */
{ 99500, 99500, 0x121, 1, CCLKCFG, -1, -1}, /* 99, 99, 50,
50 */
@@ -153,7 +153,7 @@ MODULE_PARM_DESC(pxa255_turbo_table, "Selects the frequency
table (0 = run table
((HT) ? CCLKCFG_HALFTURBO : 0) | \
((T) ? CCLKCFG_TURBO : 0))
-static pxa_freqs_t pxa27x_freqs[] = {
+static struct pxa_freqs pxa27x_freqs[] = {
{104000, 104000, PXA27x_CCCR(1, 8, 2), 0, CCLKCFG2(1, 0, 1), 90,
1705000 },
{156000, 104000, PXA27x_CCCR(1, 8, 3), 0, CCLKCFG2(1, 0, 1), 100,
1705000 },
{208000, 208000, PXA27x_CCCR(0, 16, 2), 1, CCLKCFG2(0, 0, 1), 118,
1705000 },
@@ -171,7 +171,7 @@ extern unsigned get_clk_frequency_khz(int info);
#ifdef CONFIG_REGULATOR
-static int pxa_cpufreq_change_voltage(pxa_freqs_t *pxa_freq)
+static int pxa_cpufreq_change_voltage(struct pxa_freqs *pxa_freq)
{
int ret = 0;
int vmin, vmax;
@@ -202,7 +202,7 @@ static void __init pxa_cpufreq_init_voltages(void)
}
}
#else
-static int pxa_cpufreq_change_voltage(pxa_freqs_t *pxa_freq)
+static int pxa_cpufreq_change_voltage(struct pxa_freqs *pxa_freq)
{
return 0;
}
@@ -211,7 +211,7 @@ static void __init pxa_cpufreq_init_voltages(void) { }
#endif
static void find_freq_tables(struct cpufreq_frequency_table **freq_table,
-pxa_freqs_t **pxa_freqs)
+struct pxa_freqs **pxa_freqs)
{
if (cpu_is_pxa25x()) {
if (!pxa255_turbo_table) {
@@ -270,7 +270,7 @@ static unsigned int pxa_cpufreq_get(unsigned int cpu)
static int pxa_set_target(struct cpufreq_policy *policy, unsigned int idx)
{
struct cpufreq_frequency_table *pxa_freqs_table;
- pxa_freqs_t *pxa_freq_settings;
+ struct pxa_freqs *pxa_freq_settings;
unsigned long flags;
unsigned int new_freq_cpu, new_freq_mem;
unsigned int unused, preset_mdrefr, postset_mdrefr, cclkcfg;
@@ -361,7 +361,7 @@ static int pxa_cpufreq_init(struct cpufreq_policy *policy)
int i;
unsigned int freq;
struct cpufreq_frequency_table *pxa255_freq_table;
- pxa_freqs_t *pxa255_freqs;
+ struct pxa_freqs *pxa255_freqs;
/* try to guess pxa27x cpu */
if (cpu_is_pxa27x())
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 2/2 linux-next] cpufreq: pxa: make pxa_freqs arrays const
pxa255_run_freqs and pxa255_turbo_freqs are only read.
This patch updates arrays declaration, find_freq_tables()
and its callsites.
Suggested-by: Joe Perches
Signed-off-by: Fabian Frederick
---
Compiled but untested.
drivers/cpufreq/pxa2xx-cpufreq.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/pxa2xx-cpufreq.c b/drivers/cpufreq/pxa2xx-cpufreq.c
index fcf6e34..1d99c97 100644
--- a/drivers/cpufreq/pxa2xx-cpufreq.c
+++ b/drivers/cpufreq/pxa2xx-cpufreq.c
@@ -86,7 +86,7 @@ static unsigned int sdram_rows;
/* Use the run mode frequencies for the CPUFREQ_POLICY_PERFORMANCE policy */
#define CCLKCFGCCLKCFG_TURBO | CCLKCFG_FCS
-static struct pxa_freqs pxa255_run_freqs[] =
+static const struct pxa_freqs pxa255_run_freqs[] =
{
/* CPU MEMBUS CCCR DIV2 CCLKCFGrun turbo PXbus
SDRAM */
{ 99500, 99500, 0x121, 1, CCLKCFG, -1, -1}, /* 99, 99, 50,
50 */
@@ -98,7 +98,7 @@ static struct pxa_freqs pxa255_run_freqs[] =
};
/* Use the turbo mode frequencies for the CPUFREQ_POLICY_POWERSAVE policy */
-static struct pxa_freqs pxa255_turbo_freqs[] =
+static const struct pxa_freqs pxa255_turbo_freqs[] =
{
/* CPU MEMBUS CCCR DIV2 CCLKCFGrun turbo PXbus SDRAM */
{ 99500, 99500, 0x121, 1, CCLKCFG, -1, -1}, /* 99, 99, 50,
50 */
@@ -171,7 +171,7 @@ extern unsigned get_clk_frequency_khz(int info);
#ifdef CONFIG_REGULATOR
-static int pxa_cpufreq_change_voltage(struct pxa_freqs *pxa_freq)
+static int pxa_cpufreq_change_voltage(const struct pxa_freqs *pxa_freq)
{
int ret = 0;
int vmin, vmax;
@@ -211,7 +211,7 @@ static void __init pxa_cpufreq_init_voltages(void) { }
#endif
static void find_freq_tables(struct cpufreq_frequency_table **freq_table,
-struct pxa_freqs **pxa_freqs)
+const struct pxa_freqs **pxa_freqs)
{
if (cpu_is_pxa25x()) {
if (!pxa255_turbo_table) {
@@ -270,7 +270,7 @@ static unsigned int pxa_cpufreq_get(unsigned int cpu)
static int pxa_set_target(struct cpufreq_policy *policy, unsigned int idx)
{
struct cpufreq_frequency_table *pxa_freqs_table;
- struct pxa_freqs *pxa_freq_settings;
+ const struct pxa_freqs *pxa_freq_settings;
unsigned long flags;
unsigned int new_freq_cpu, new_freq_mem;
unsigned int unused, preset_mdrefr, postset_mdrefr, cclkcfg;
@@ -361,7 +361,7 @@ static int pxa_cpufreq_init(struct cpufreq_policy *policy)
int i;
unsigned int freq;
struct cpufreq_frequency_table *pxa255_freq_table;
- struct pxa_freqs *pxa255_freqs;
+ const struct pxa_freqs *pxa255_freqs;
/* try to guess pxa27x cpu */
if (cpu_is_pxa27x())
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] arc: use for_each_sg()
On Friday 01 May 2015 12:17 PM, Akinobu Mita wrote:
> Since arc doesn't select ARCH_HAS_SG_CHAIN, it is not necessary to
> use for_each_sg() in order to loop over each sg element. But this can
> help find problems with drivers that do not properly initialize their
> sg tables when CONFIG_DEBUG_SG is enabled.
>
> Signed-off-by: Akinobu Mita
> Cc: Vineet Gupta
> Cc: linux-a...@vger.kernel.org
Looks fine to me. However it must be noted (perhaps add to change log) that this
will lead to different generated code as sg_next() is a function call etc. So
this
change is strictly not equivalent to what we had before.
Acked-by: Vineet Gupta
Thx,
-Vineet
> ---
> arch/arc/include/asm/dma-mapping.h | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arc/include/asm/dma-mapping.h
> b/arch/arc/include/asm/dma-mapping.h
> index 45b8e0c..f787894 100644
> --- a/arch/arc/include/asm/dma-mapping.h
> +++ b/arch/arc/include/asm/dma-mapping.h
> @@ -178,22 +178,24 @@ dma_sync_single_range_for_device(struct device *dev,
> dma_addr_t dma_handle,
> }
>
> static inline void
> -dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nelems,
> +dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sglist, int
> nelems,
> enum dma_data_direction dir)
> {
> int i;
> + struct scatterlist *sg;
>
> - for (i = 0; i < nelems; i++, sg++)
> + for_each_sg(sglist, sg, nelems, i)
> _dma_cache_sync((unsigned int)sg_virt(sg), sg->length, dir);
> }
>
> static inline void
> -dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int
> nelems,
> -enum dma_data_direction dir)
> +dma_sync_sg_for_device(struct device *dev, struct scatterlist *sglist,
> +int nelems, enum dma_data_direction dir)
> {
> int i;
> + struct scatterlist *sg;
>
> - for (i = 0; i < nelems; i++, sg++)
> + for_each_sg(sglist, sg, nelems, i)
> _dma_cache_sync((unsigned int)sg_virt(sg), sg->length, dir);
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/2] crypto: Introduce Public Key Encryption API
I have nothing to do with this, please drop me from Cc.
Thanks,
Jean
On Thu, 30 Apr 2015 15:36:47 -0700, Tadeusz Struk wrote:
> This patch set introduces a Public Key Encryption API.
> What is proposed is a new crypto type called crypto_pke_type
> plus new struct pke_alg and struct pke_tfm together with number
> of helper functions to register pke type algorithms and allocate
> tfm instances. This is to make it similar to how the existing crypto
> API works for the ablkcipher, ahash, and aead types.
> The operations the new interface will allow to provide are:
>
> int (*sign)(struct pke_request *pkereq);
> int (*verify)(struct pke_request *pkereq);
> int (*encrypt)(struct pke_request *pkereq);
> int (*decrypt)(struct pke_request *pkereq);
>
> The benefits it gives comparing to the struct public_key_algorithm
> interface are:
> - drivers can add many implementations of RSA or DSA
> algorithms and user will allocate instances (tfms) of these, base on
> algorithm priority, in the same way as it is with the symmetric ciphers.
> - the new interface allows for asynchronous implementations that
> can use crypto hardware to offload the calculations to.
> - integrating it with linux crypto api allows using all its benefits
> i.e. managing algorithms using NETLINK_CRYPTO, monitoring implementations
> using /proc/crypto. etc
>
> New helper functions have been added to allocate pke_tfm instances
> and invoke the operations to make it easier to use.
> For instance to verify a public_signature against a public_key using
> the RSA algorithm a user would do:
>
> struct crypto_pke *tfm = crypto_alloc_pke("rsa", 0, 0);
> struct pke_request *req = pke_request_alloc(tfm, GFP_KERNEL);
> pke_request_set_crypt(req, pub_key, signature);
> int ret = crypto_pke_verify(req);
> pke_request_free(req);
> crypto_free_pke(tfm);
> return ret;
>
> Additionally existing public_key and rsa code have been reworked to
> use the new interface for verifying signed modules.
> As part of the rework the enum pkey_algo has been removed as the algorithm
> to allocate will be indicated by a string - for instance "rsa" or "dsa",
> similarly as it is with the symmetric algs e.g. "aes".
> It will also make it easier to extend in the future when new algorithms
> will be added.
> ---
> Tadeusz Struk (2):
> crypto: add PKE API
> crypto: RSA: KEYS: convert rsa and public key to new PKE API
>
>
> Documentation/crypto/asymmetric-keys.txt | 10 +-
> crypto/Kconfig|6 +
> crypto/Makefile |1
> crypto/asymmetric_keys/Kconfig|1
> crypto/asymmetric_keys/pkcs7_parser.c |4 -
> crypto/asymmetric_keys/pkcs7_trust.c |2
> crypto/asymmetric_keys/pkcs7_verify.c |5 -
> crypto/asymmetric_keys/public_key.c | 73 +++
> crypto/asymmetric_keys/public_key.h | 36 -
> crypto/asymmetric_keys/rsa.c | 47 ++-
> crypto/asymmetric_keys/x509_cert_parser.c | 14 ++
> crypto/asymmetric_keys/x509_public_key.c | 14 +-
> crypto/crypto_user.c | 23 +++
> crypto/pke.c | 114 +
> include/crypto/algapi.h |6 +
> include/crypto/public_key.h | 24 +---
> include/linux/crypto.h| 191
> +
> include/linux/cryptouser.h|7 +
> kernel/module_signing.c |9 +
> 19 files changed, 471 insertions(+), 116 deletions(-)
> delete mode 100644 crypto/asymmetric_keys/public_key.h
> create mode 100644 crypto/pke.c
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 1/3] smpboot: allow excluding cpus from the smpboot threads
On Thu, Apr 30, 2015 at 03:39:24PM -0400, Chris Metcalf wrote:
> This change allows some cores to be excluded from running the
> smp_hotplug_thread tasks. The following commit to update
> kernel/watchdog.c to use this functionality is the motivating
> example, and more information on the motivation is provided there.
>
> A new smp_hotplug_thread field is introduced, "cpumask", which
> is cpumask field managed by the smpboot subsystem that indicates whether
> or not the given smp_hotplug_thread should run on that core; the
> cpumask is checked when deciding whether to unpark the thread.
>
> To limit the cpumask to less than cpu_possible, you must call
> smpboot_update_cpumask_percpu_thread() after registering.
>
> Signed-off-by: Chris Metcalf
> ---
> include/linux/smpboot.h | 5 +
> kernel/smpboot.c| 55
> -
> 2 files changed, 59 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/smpboot.h b/include/linux/smpboot.h
> index d600afb21926..7c42153edfac 100644
> --- a/include/linux/smpboot.h
> +++ b/include/linux/smpboot.h
> @@ -27,6 +27,8 @@ struct smpboot_thread_data;
> * @pre_unpark: Optional unpark function, called before the
> thread is
> * unparked (cpu online). This is not guaranteed to be
> * called on the target cpu of the thread. Careful!
> + * @cpumask: Internal state. To update which threads are unparked,
> + * call smpboot_update_cpumask_percpu_thread().
> * @selfparking: Thread is not parked by the park function.
> * @thread_comm: The base name of the thread
> */
> @@ -41,11 +43,14 @@ struct smp_hotplug_thread {
> void(*park)(unsigned int cpu);
> void(*unpark)(unsigned int cpu);
> void(*pre_unpark)(unsigned int cpu);
> + struct cpumask cpumask;
I believe it should be allocated dynamically, otherwise it gets the size of
NR_CPUS
instead of nr_cpus_bits. It's not _that_ much space spared but think there
should be
several struct smp_hotplug_thread registered.
> boolselfparking;
> const char *thread_comm;
> };
>
> int smpboot_register_percpu_thread(struct smp_hotplug_thread *plug_thread);
> void smpboot_unregister_percpu_thread(struct smp_hotplug_thread
> *plug_thread);
> +int smpboot_update_cpumask_percpu_thread(struct smp_hotplug_thread
> *plug_thread,
> + const struct cpumask *);
>
> #endif
> diff --git a/kernel/smpboot.c b/kernel/smpboot.c
> index c697f73d82d6..209750ab7031 100644
> --- a/kernel/smpboot.c
> +++ b/kernel/smpboot.c
> @@ -232,7 +232,8 @@ void smpboot_unpark_threads(unsigned int cpu)
>
> mutex_lock(&smpboot_threads_lock);
> list_for_each_entry(cur, &hotplug_threads, list)
> - smpboot_unpark_thread(cur, cpu);
> + if (cpumask_test_cpu(cpu, &cur->cpumask))
> + smpboot_unpark_thread(cur, cpu);
> mutex_unlock(&smpboot_threads_lock);
> }
>
> @@ -258,6 +259,15 @@ static void smpboot_destroy_threads(struct
> smp_hotplug_thread *ht)
> {
> unsigned int cpu;
>
> + /* Unpark any threads that were voluntarily parked. */
> + for_each_cpu_not(cpu, &ht->cpumask) {
> + if (cpu_online(cpu)) {
> + struct task_struct *tsk = *per_cpu_ptr(ht->store, cpu);
> + if (tsk)
> + kthread_unpark(tsk);
I'm still not clear why we are doing that. kthread_stop() should be able
to handle parked kthreads, otherwise it needs to be fixed.
> + }
> + }
> +
> /* We need to destroy also the parked threads of offline cpus */
> for_each_possible_cpu(cpu) {
> struct task_struct *tsk = *per_cpu_ptr(ht->store, cpu);
> @@ -281,6 +291,7 @@ int smpboot_register_percpu_thread(struct
> smp_hotplug_thread *plug_thread)
> unsigned int cpu;
> int ret = 0;
>
> + cpumask_copy(&plug_thread->cpumask, cpu_possible_mask);
> get_online_cpus();
> mutex_lock(&smpboot_threads_lock);
> for_each_online_cpu(cpu) {
> @@ -316,6 +327,48 @@ void smpboot_unregister_percpu_thread(struct
> smp_hotplug_thread *plug_thread)
> }
> EXPORT_SYMBOL_GPL(smpboot_unregister_percpu_thread);
>
> +/**
> + * smpboot_update_cpumask_percpu_thread - Adjust which per_cpu hotplug
> threads stay parked
> + * @plug_thread: Hotplug thread descriptor
> + * @new: Revised mask to use
> + *
> + * The cpumask field in the smp_hotplug_thread must not be updated directly
> + * by the client, but only by calling this function.
> + */
> +int smpboot_update_cpumask_percpu_thread(struct smp_hotplug_thread
> *plug_thread,
> + const struct cpumask *new)
> +{
> + struct cpumask *old = &plu
Re: [PATCH] ARM: dts: am437x-gp-evm: add DT nodes for ov2659 sensor
On Fri, Apr 10, 2015 at 9:22 PM, Lad, Prabhakar wrote: > Hi Tony, > > On Tue, Mar 17, 2015 at 2:23 AM, Tony Lindgren wrote: >> * Lad, Prabhakar [150316 18:20]: >>> Hi Tony, >>> >>> On Mon, Mar 16, 2015 at 10:17 PM, Tony Lindgren wrote: >>> > * Lad Prabhakar [150312 16:38]: >>> >> From: "Lad, Prabhakar" >>> >> >>> >> this patch does the following: >>> >> 1: adds DT node for fixed oscillator. >>> >> 2: adds DT node entries for ov2659 sensor >>> >> 3: adds remote-endpoint entry for VPFE. >>> >> >>> >> Signed-off-by: Lad, Prabhakar >>> > >>> > Applying into omap-for-v4.1/dt thanks. >>> > >>> I would like to get this one in via media tree to avoid dependency >>> as I am still waiting for Acks from DT maintainers for the sensor >>> driver. >> >> OK dropping it. >> >>> If I can get your Ack on this I'll queue it up along with sensor >>> driver via media tree. >> >> Sorry the chances are too big for pointless merge conflicts with >> these files with constant patching going on. >> >> Please just resend this patch alone again to me later on once the >> driver changes are merged into Linux next and on their way to the >> mainline kernel. >> > the sensor driver is now present in linux-next and the same patch > applies cleanly, can you pick up the same or do you want me to > resend the patch ? > Ping... Cheers, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: AM43xx: hwmod: add VPFE hwmod entries
On Fri, Apr 10, 2015 at 11:51 PM, Paul Walmsley wrote: > Hi Prabhakar > > On Fri, 10 Apr 2015, Lad, Prabhakar wrote: > >> Hi Paul, >> >> On Tue, Feb 10, 2015 at 11:10 PM, Paul Walmsley wrote: >> > On Wed, 28 Jan 2015, Benoit Parrot wrote: >> > >> >> Suspend/resume is functional with this patch. >> >> >> >> Tested-by: Benoit Parrot >> > >> > Thanks folks, queued for v3.21. >> > >> > >> I see that this patch is not into linux-next yet. > > thanks for the ping. This slipped through the cracks here due to the > kernel version number change from 3.21 to 4.1 :-( Sorry about that; I > will requeue for either 4.1-rc or 4.2. > > Unfortunately I don't have an AM43xx board. Is suspend/resume broken > without this patch? If so, then v4.1-rc seems like the appropriate > target. > > Ping.. Cheers, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A desktop environment[1] kernel wishlist
On 30 April 2015 at 20:54, Chirantan Ekbote wrote: > On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson wrote: >> Hi, >> >> On Thu, Apr 30, 2015 at 10:10 AM, John Stultz wrote: >>> On Thu, Apr 30, 2015 at 9:25 AM, Bastien Nocera wrote: On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote: > On Tue, Oct 21, 2014 at 1:49 AM, Bastien Nocera > wrote: > > Hey, > > > > GNOME has had discussions with kernel developers in the past, and, > > fortunately, in some cases we were able to make headway. > > > > There are however a number of items that we still don't have > > solutions > > for, items that kernel developers might not realise we'd like to > > rely > > on, or don't know that we'd make use of if merged. > > > > I've posted this list at: > > https://wiki.gnome.org/BastienNocera/KernelWishlist > > > > Let me know on-list or off-list if you have any comments about > > those, so > > I can update the list. > > As for: 'Export of "wake reason" when the system wakes up (rtc alarm, > lid open, etc.) and wakealarm (/sys/class/rtc/foo/wakealarm) > documentation' > > Can you expand more on the rational for the need here? Is this for UI > for power debugging, or something else? This is pretty much what I had in mind: https://www.chromium.org/chromium-os/chromiumos-design-docs/lucid-sleep I guess I didn't make myself understood. >>> >>> My, admittedly quick skim, of that design document seems to suggest >>> that lucid sleep would be a new kernel state. That would keep the >>> kernel in charge of determining the state transitions (ie: >>> SUSPEND-(alarm)->LUCID-(wakelock >>> release)->SUSPEND-(alarm)->LUCID-(power-button)->AWAKE). Then it seems >>> userspace would be able to query the current state. This avoids some >>> of the races I was concerned with trying to detect which irq woke us >>> from suspend from userspace. >>> > > Tomeu has been working on making things so that we don't need a new > kernel state. Adding him on cc so he can correct me if I say > something wrong. The current idea is to have userspace runtime > suspend any unneeded devices before starting a suspend. This way the > kernel will leave them alone at resume. This behavior already exists > in the mainline kernel. This is right, I have one series on flight about removing any non-runtime device resumes from my test platform (a nyan-big) and another about entering suspend-to-idle with ticks frozen (also on Tegra124/nyan-big). > Getting the wakeup reason can be accomplished > by having the kernel emit a uevent with the wakeup reason. This is > the only change that would be necessary. My current opinion is that for ChromeOS there's no need for the kernel to communicate a wakeup reason to userspace. From what I know it should be enough for powerd/upower/whatever to constantly monitor all relevant input devices and that should tell if the wakeup was caused by user activity or not. Once userspace is thawed, the power management daemon would read any pending events from the input devices and would decide whether to stay on dark resume or whether to unfreeze renderer daemons and power up the display, unpause any audio streams, etc. For the GNOME folks, this is how it's done in ChromeOS: https://chromium.googlesource.com/chromiumos/platform2/+/master/power_manager/powerd/system/input_watcher.cc Of course, this depends on events not getting lost. In the ChromeOS case, the firmware is under the control of the OS developers, so any bugs can be fixed. For GNOME and other desktop environments who aim to run on systems whose firmware cannot be fixed, I think it could make sense for the kernel to synthesize such events if it happens to have enough information to do so. Besides this issue, I think that what "only" remains to be done in the kernel is to speed up resumes so no hacks are needed downstream. The infrastructure for this already exists in the form of power.direct_complete and suspend-to-idle and the work that remains is mostly platform-specific. This is to say that GNOME could start implementing lucid sleep right now, though the user experience might not be ideal yet because resumes might take longer than desired. But it might not matter to GNOME as much as it does to ChromeOS because they aren't in control of the hw anyway? Regards, Tomeu >>> That said, the Power Manager section in that document sounds a little >>> racy as it seems to rely on asking userspace if suspend is ok, rather >>> then using userspace wakelocks, so I'm not sure how well baked this >>> doc is. >>> > > I'm not sure I understand what you are saying here. If you're saying > that the kernel is asking userspace if suspend is ok, then I can say > that that's definitely not the case. Currently from the kernel's > perspective a lucid sleep resume isn't really different from a regular > resume. We have a hack in each driver that we care abo
Re: [PATCH] x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue
On Thu, Apr 30, 2015 at 04:23:26PM -0700, H. Peter Anvin wrote: > I probably should have added that the microbenchmark specifically tests > for an atomic 5-byte NOP (as required by tracepoints etc.) If the > requirement for 5-byte atomic is dropped there might be faster > combinations, e.g. 66 66 66 90 might work better on some platforms, or > using very long 0F 1F sequences. Right, so I was thinking of extending it for all sizes 1 - 15 and then run it on boxes. I'll keep you posted. Thanks for the toy - now I get to have some fun. :-) -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] m68k: use for_each_sg()
Hi Mita-san,
On Fri, May 1, 2015 at 8:47 AM, Akinobu Mita wrote:
> Since m68k doesn't select ARCH_HAS_SG_CHAIN, it is not necessary to
> use for_each_sg() in order to loop over each sg element. But this can
> help find problems with drivers that do not properly initialize their
> sg tables when CONFIG_DEBUG_SG is enabled.
>
> Signed-off-by: Akinobu Mita
> Cc: Geert Uytterhoeven
> Cc: linux-m...@lists.linux-m68k.org
> Cc: linux-a...@vger.kernel.org
Acked-by: Geert Uytterhoeven
Do you want me to queue this up for v4.2, or do you want to handle these
changes yourself, together with "[PATCH] scatterlist: enable sg chaining
for all architectures"?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] clk: si5351: Some fixes
On Thu, 30 Apr 2015 19:45:50 +0200 Sebastian Hesselbarth wrote: > For Si5351 clock driver, Michael Welling and Jean-Francois Moine reported > issues with recent v4.x kernels due to broken/missing/wrong parent clock > claming. This patch set now deals with the issues reported. > > Patch 1 amends the binding documentation mention clock-names property > for the "xtal" and "clkin" parent clock inputs of Si5351 variants. > > Patch 2 adds the clock-names property for the SolidRun CuBox using Si5351 > with a fixed oscillator connected to "xtal" input. > > Patch 3 reworks the way we claim parent clocks by using devm_clk_get() > for both DT and platform_data based registration. Also, properly check > for errors returned by devm_clk_get() and prepare/enable the parent clocks. > > Patch 4 introduces a function to reset PLLs on rate change. This should > improve generated clock output stability. I currently have no scope at hand > to actually test that properly, so there may be more issues remaining. > > @Michael, Jean-Francois: Please test and report if there are still > issues remaining. I applied the patches 2 and 3, and the audio and video in the Cubox work fine again. Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT PATCH] drm/exynos: Enable DP clock to fix display on Exynos5250 and other
2015-05-01 1:50 GMT+09:00 Olof Johansson : > On Thu, Apr 30, 2015 at 9:40 AM, Javier Martinez Canillas > wrote: >> Hello Olof, >> >> On 04/30/2015 05:57 PM, Olof Johansson wrote: >>> On Thu, Apr 30, 2015 at 8:44 AM, Kevin Hilman wrote: Krzysztof Kozlowski writes: >>> >>> This should fix issue reported by Javier [1][2]. >>> >>> Tested on Chromebook Snow (Exynos 5250). More testing would be great, >>> especially on other Exynos 5xxx products. >> >> I hoped to try this on my exynos5 boards, but it doesn't seem to apply >> to linux-next or to Linus' master branch. >> >> Are there some other dependencies here? > > It is already applied: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c363c7cccf64128087002b0779986ad16aff6dc Er, yup. That would explain it. ;) Sorry for the noise, >>> >>> Well, noise or not, Exynos is still broken in mainline and was broken >>> on -next for so long in different ways that bisecting it is a futile >>> exercise in frustration. >>> >>> It doesn't seem to show up with a trivial boot using only ramdisk, but >>> when booting a real distro from disk, it certainly does. >>> >>> For example: >>> >>> http://arm-soc.lixom.net/bootlogs/mainline/v4.1-rc1-56-g3d99e3f/pi-arm-exynos_defconfig.html >>> >>> Disabling CONFIG_DRM makes it boot reliably. >>> >>> Arndale doesn't show it for me, but it also doesn't have working graphics. >>> >> >> Both Exynos5250 and Exynos5420 had similar issues and $subject is the fix >> for 5250 while 5420 is fixed by my "ARM: dts: Make DP a consumer of DISP1 >> power domain on Exynos5420" patch that was posted a long time ago. I have >> pinged Kukjin several times about this patch and he said that he will pick >> it this weekend [0]. >> >> It is indeed very frustrating how many Exynos patches seems to be falling >> through the crack, even important fixes like these ones that allow boards >> to boot again. >> >> Kevin suggested that Krzysztof could collect and queue patches [1] to help >> Kukjin and start acting as a co-maintatiner which I think it's a very good >> idea and Krzysztof already did for some patches during the 4.1 cycle. Yes, I did. It turned quite well, most of the patches I collected were pulled :) . > Yes, that's a much needed improvement. I suggest starting out by > collecting critical fixes like these, and we'd be happy to merge them > directly if going through Kukjin will add latency. > > Krzysztof, if you can, make sure you get a PGP key setup and start > collecting signatures from kernel developers. Sure, I'll start right away! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] Fix a misaligned load inside ptrace_attach()
On Thu, Apr 30, 2015 at 09:19:54PM -0700, Palmer Dabbelt wrote: > I ran across what I believe is a bug in some asm-generic code while > working on the RISC-V Linux port. Essentially the problem is that > wait_on_bit() takes a void *, but then perfroms long-aligned > operation. As far as I can tell, this bug could manifest on any other > architecture that doesn't support misaligned operations and uses this > particular asm-generic implementation. > > The patch set is split into three parts: > > * #1 fixes the bug by making task_struct.jobctl an unsigned long, >which ensures wait_on_bit() always ends up with a long-aligned >argument. > > * #2 changes the prototype of wait_on_bit() and friends to take a >"unsigned long *" instead of a "void *", with the intent of >ensuring these problems don't happen again. > > * #3 is a bit more intrusive: it goes and changes all uses of >task_struct.jobctl from int to long. > > I'm not sure if #3 has gone too far, but I think #1 and #2 are sane. > The cost is making task_struct larger on machines where > sizeof(long)>sizeof(int), but since it's so big already this isn't too > much cost. I thought about making test_bit() perform byte-aligned > accesses to avoid this cost, but since there are very similar looking > atomic functions I thought that would be too odd. Fair enough. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: page_alloc: pass PFN to __free_pages_bootmem -fix
Stephen Rothwell reported the following
Today's linux-next build (sparc defconfig) failed like this:
mm/bootmem.c: In function 'free_all_bootmem_core':
mm/bootmem.c:237:32: error: 'cur' undeclared (first use in this
function)
__free_pages_bootmem(page++, cur++, 0);
^
Caused by commit "mm: page_alloc: pass PFN to __free_pages_bootmem".
He also merged a fix. The only difference in this version is one line is
moved so the final diff context is clearer. This is a fix to the mmotm
patch mm-page_alloc-pass-pfn-to-__free_pages_bootmem.patch
Signed-off-by: Mel Gorman
---
mm/bootmem.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/bootmem.c b/mm/bootmem.c
index daf956bb4782..a23dd1934654 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -172,7 +172,7 @@ void __init free_bootmem_late(unsigned long physaddr,
unsigned long size)
static unsigned long __init free_all_bootmem_core(bootmem_data_t *bdata)
{
struct page *page;
- unsigned long *map, start, end, pages, count = 0;
+ unsigned long *map, start, end, pages, cur, count = 0;
if (!bdata->node_bootmem_map)
return 0;
@@ -214,7 +214,7 @@ static unsigned long __init
free_all_bootmem_core(bootmem_data_t *bdata)
count += BITS_PER_LONG;
start += BITS_PER_LONG;
} else {
- unsigned long cur = start;
+ cur = start;
start = ALIGN(start + 1, BITS_PER_LONG);
while (vec && cur != start) {
@@ -229,6 +229,7 @@ static unsigned long __init
free_all_bootmem_core(bootmem_data_t *bdata)
}
}
+ cur = bdata->node_min_pfn;
page = virt_to_page(bdata->node_bootmem_map);
pages = bdata->node_low_pfn - bdata->node_min_pfn;
pages = bootmem_bootmap_pages(pages);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: meminit: Initialise a subset of struct pages if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set -fix
This is take 2 on describing why these section names exist. If accepted then it should be considered a fix for the mmotm patch mm-meminit-initialise-a-subset-of-struct-pages-if-config_deferred_struct_page_init-is-set.patch Signed-off-by: Mel Gorman --- mm/internal.h | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/mm/internal.h b/mm/internal.h index 24314b671db1..85189fce7f61 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -386,10 +386,14 @@ static inline void mminit_verify_zonelist(void) #endif /* CONFIG_DEBUG_MEMORY_INIT */ /* - * Deferred struct page initialisation requires some early init functions that - * are removed before kswapd is up and running. The feature depends on memory - * hotplug so put the data and code required by deferred initialisation into - * the __meminit section where they are preserved. + * Deferred struct page initialisation requires init functions that are freed + * before kswapd is available. Reuse the memory hotplug section annotation + * to mark the required code. + * + * __defermem_init is code that always exists but is annotated __meminit to + * avoid section warnings. + * __defer_init code gets marked __meminit when deferring struct page + * initialistion but is otherwise in the init section. */ #ifdef CONFIG_DEFERRED_STRUCT_PAGE_INIT #define __defermem_init __meminit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD 0/5] Add latency histogram
Hi Tom, On 05/01/2015 01:52 AM, Tom Zanussi wrote: Hi Daniel, On Thu, 2015-04-30 at 12:06 +0200, Daniel Wagner wrote: Hi, I would like to discuss a possible way of getting the feature of the latecy_hist.patch [1] added to mainline. "Latency histograms are primarily relevant in the context of real-time enabled kernels (CONFIG_PREEMPT/CONFIG_PREEMPT_RT)and are used in the quality management of the Linux real-time capabilities." Steven pointed out that this might be doable based on Tom Zanussi's "[PATCH v4 0/7] tracing: 'hist' triggers" [2]. Here are my findings. It was not too complicated to get it working, though I had to add some hacks. I have added comments to each patch. It looks like you were able to do quite a bit here with not much code - nice! Thanks :) Just FYI, I'll be working on a v5 of the hist triggers patchset that will incorporate the stuff from patch 1 (needs to be split into a separate patch for the triggers code already upstream, and one for hist triggers) and your comments from patch 2 (see comments in my reply to that patch), along with a couple other unrelated changes... Great to hear! cheers, daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: meminit: Reduce number of times pageblocks are set during struct page init -fix
The patch "mm: meminit: Reduce number of times pageblocks are
set during struct page init" is setting a pageblock before
the page is initialised. This is a fix for the mmotm patch
mm-meminit-reduce-number-of-times-pageblocks-are-set-during-struct-page-init.patch
Signed-off-by: Mel Gorman
---
mm/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 19aac687963c..544edb3b8da2 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4497,8 +4497,8 @@ void __meminit memmap_init_zone(unsigned long size, int
nid, unsigned long zone,
if (!(pfn & (pageblock_nr_pages - 1))) {
struct page *page = pfn_to_page(pfn);
- set_pageblock_migratetype(page, MIGRATE_MOVABLE);
__init_single_page(page, pfn, zone, nid);
+ set_pageblock_migratetype(page, MIGRATE_MOVABLE);
} else {
__init_single_pfn(pfn, zone, nid);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD 5/5] tracing: Add trace_irqsoff tracepoints
On 05/01/2015 02:54 AM, Steven Rostedt wrote: On Thu, 30 Apr 2015 21:14:52 -0500 Tom Zanussi wrote: 'hist:key=latency.bucket:val=hitcount:sort=latency if cpu==0' but I haven't got this working. I didn't spend much time figuring out why this doesn't work. Even if the above is working you still I think it doesn't work because the tracepoint doesn't actually have a 'cpu' field to use in the filter... Perhaps we should add special fields that don't use the tracepoint field, but can use generically know fields that are always known when the tracepoint is triggered. COMM could be one, as well as CPU. I'll give it a try if no one objects next week (public holiday today :)) cheers, daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: i2o: Remove unwanted semicolon
On Fri, 2015-05-01 at 09:41 +0200, gre...@linuxfoundation.org wrote: > On Thu, Apr 30, 2015 at 11:25:48PM +0100, One Thousand Gnomes wrote: > > On Thu, 30 Apr 2015 16:14:06 +0200 > > "gre...@linuxfoundation.org" wrote: > > > > > On Thu, Apr 23, 2015 at 04:09:28PM +0100, Alan Cox wrote: > > > > On Thu, 2015-04-23 at 13:43 +, Gujulan Elango, Hari Prasath (H.) > > > > wrote: > > > > > This patch removes unwanted semicolon around close braces of code > > > > > blocks > > > > > > > > > > > > The i2o driver moved into staging ready to be deleted unless someone > > > > steps up with hardware willing to maintain it (which is rather > > > > unlikely). > > > > > > I think it's now time to delete these, want me to do that for 4.2? I > > > can queue that up in my tree now, so that we don't see any more cleanup > > > patches being made for them? > > > > Yeah I think it can go > > I was about to delete it, but what about drivers/scsi/dpt/dpti_i2o.* ? > Should that be removed as well? Possibly but that ought to go via staging and really is one for the SCSI folks to call. The dpt_i2o was a bit more common than i2o proper. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] arm64: post merge-window fixes for 4.1
Hi Linus,
Please pull the following arm64 fixes for 4.1. Not too much here, but
we've addressed a couple of nasty issues in the dma-mapping code as well
as adding the halfword and byte variants of load_acquire/store_release
following on from the CSD locking bug that you fixed in the core.
Thanks,
Will
--->8
The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes
for you to fetch changes up to 8291fd04d86b97869bd34e796bcac3141b9d5432:
arm64: perf: Fix the pmu node name in warning message (2015-04-30 12:11:30
+0100)
arm64 fixes:
- Fix perf devicetree warnings at probe time
- Fix memory leak in __dma_free()
- Ensure DMA buffers are always zeroed
- Show IRQ trigger in /proc/interrupts (for parity with ARM)
- Implement byte and halfword access for smp_{load_acquire,store_release}
Andre Przywara (1):
arm64: add missing data types in smp_load_acquire/smp_store_release
Dean Nelson (1):
arm64: add missing PAGE_ALIGN() to __dma_free()
Marek Szyprowski (1):
arm64: dma-mapping: always clear allocated buffers
Sudeep Holla (1):
ARM64: Enable CONFIG_GENERIC_IRQ_SHOW_LEVEL
Suzuki K. Poulose (1):
arm64: perf: Fix the pmu node name in warning message
Will Deacon (1):
arm64: perf: don't warn about missing interrupt-affinity property for PPIs
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/barrier.h | 16
arch/arm64/kernel/perf_event.c | 9 +++--
arch/arm64/mm/dma-mapping.c | 9 -
4 files changed, 28 insertions(+), 7 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] clk: si5351: Some fixes
On 01.05.2015 11:14, Jean-Francois Moine wrote: On Thu, 30 Apr 2015 19:45:50 +0200 Sebastian Hesselbarth wrote: For Si5351 clock driver, Michael Welling and Jean-Francois Moine reported issues with recent v4.x kernels due to broken/missing/wrong parent clock claming. This patch set now deals with the issues reported. Patch 1 amends the binding documentation mention clock-names property for the "xtal" and "clkin" parent clock inputs of Si5351 variants. Patch 2 adds the clock-names property for the SolidRun CuBox using Si5351 with a fixed oscillator connected to "xtal" input. Patch 3 reworks the way we claim parent clocks by using devm_clk_get() for both DT and platform_data based registration. Also, properly check for errors returned by devm_clk_get() and prepare/enable the parent clocks. [...] I applied the patches 2 and 3, and the audio and video in the Cubox work fine again. Thanks. Ok, good. You mentioned that on v3.19-rc1 it still "works" i.e. despite the broken/missing clk_get/clk_prepare_enable? Can you check the stable (v3.19, v4.0) versions and see how far we should backport the fix? Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] x86/mce/amd: Introduce deferred error interrupt handler
On Thu, Apr 30, 2015 at 11:16:30PM -0500, Aravind Gopalakrishnan wrote: > I used the term as it is an interrupt due to the deferred error. > Would 'deferred_err_interrupt' be more apt? Maybe 'irq_deferred_error_count' > for the counter? Yeah, I think it is important to stick to the "deferred error" naming as those are interrupts announcing deferred errors and not deferred interrupts. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: mfd: check ACPI device companion before checking resources
Current code in mfd-core calls into ACPI to check resources even
on a system that booted with a DT (on kernels with both DT and ACPI
support compiled in). This triggers ACPI exceptions since we may
end up calling the ACPI interpreter when it has not been initialized:
"ACPI Exception: AE_BAD_PARAMETER, Thread 2064154624 could not acquire
Mutex [0x1] (20150410/utmutex-285)"
This patch fixes the issues by adding a check for an ACPI companion
device before carrying out ACPI resources checks to avoid calling
the ACPI interpreter if the fwnode representing the device is an OF one.
Signed-off-by: Lorenzo Pieralisi
Cc: Sudeep Holla
Cc: Lee Jones
Cc: Samuel Ortiz
---
Lee, Samuel,
I could not test it on X86 and I do not know if you prefer setting
ignore_resource_conflicts in the respective mfd cells (ie vexpress),
just let me know how do you want to fix it.
Thanks,
Lorenzo
drivers/mfd/mfd-core.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 1aed3b7..14fd5cb 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -207,9 +207,11 @@ static int mfd_add_device(struct device *parent, int id,
}
if (!cell->ignore_resource_conflicts) {
- ret = acpi_check_resource_conflict(&res[r]);
- if (ret)
- goto fail_alias;
+ if (has_acpi_companion(&pdev->dev)) {
+ ret = acpi_check_resource_conflict(&res[r]);
+ if (ret)
+ goto fail_alias;
+ }
}
}
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH kernel v9 22/32] powerpc/powernv: Implement multilevel TCE tables
On 04/29/2015 03:04 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:46PM +1000, Alexey Kardashevskiy wrote:
TCE tables might get too big in case of 4K IOMMU pages and DDW enabled
on huge guests (hundreds of GB of RAM) so the kernel might be unable to
allocate contiguous chunk of physical memory to store the TCE table.
To address this, POWER8 CPU (actually, IODA2) supports multi-level TCE tables,
up to 5 levels which splits the table into a tree of smaller subtables.
This adds multi-level TCE tables support to pnv_pci_create_table()
and pnv_pci_free_table() helpers.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v9:
* moved from ioda2 to common powernv pci code
* fixed cleanup if allocation fails in a middle
* removed check for the size - all boundary checks happen in the calling code
anyway
---
arch/powerpc/include/asm/iommu.h | 2 +
arch/powerpc/platforms/powernv/pci-ioda.c | 15 +++--
arch/powerpc/platforms/powernv/pci.c | 94 +--
arch/powerpc/platforms/powernv/pci.h | 4 +-
4 files changed, 104 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 7e7ca0a..0f50ee2 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -96,6 +96,8 @@ struct iommu_pool {
struct iommu_table {
unsigned long it_busno; /* Bus number this table belongs to */
unsigned long it_size; /* Size of iommu table in entries */
+ unsigned long it_indirect_levels;
+ unsigned long it_level_size;
unsigned long it_offset;/* Offset into global table */
unsigned long it_base; /* mapped address of tce table */
unsigned long it_index; /* which iommu table this is */
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 59baa15..cc1d09c 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1967,13 +1967,17 @@ static long pnv_pci_ioda2_set_window(struct
iommu_table_group *table_group,
table_group);
struct pnv_phb *phb = pe->phb;
int64_t rc;
+ const unsigned long size = tbl->it_indirect_levels ?
+ tbl->it_level_size : tbl->it_size;
const __u64 start_addr = tbl->it_offset << tbl->it_page_shift;
const __u64 win_size = tbl->it_size << tbl->it_page_shift;
pe_info(pe, "Setting up window at %llx..%llx "
- "pgsize=0x%x tablesize=0x%lx\n",
+ "pgsize=0x%x tablesize=0x%lx "
+ "levels=%d levelsize=%x\n",
start_addr, start_addr + win_size - 1,
- 1UL << tbl->it_page_shift, tbl->it_size << 3);
+ 1UL << tbl->it_page_shift, tbl->it_size << 3,
+ tbl->it_indirect_levels + 1, tbl->it_level_size << 3);
tbl->it_table_group = &pe->table_group;
@@ -1984,9 +1988,9 @@ static long pnv_pci_ioda2_set_window(struct
iommu_table_group *table_group,
rc = opal_pci_map_pe_dma_window(phb->opal_id,
pe->pe_number,
pe->pe_number << 1,
- 1,
+ tbl->it_indirect_levels + 1,
__pa(tbl->it_base),
- tbl->it_size << 3,
+ size << 3,
1ULL << tbl->it_page_shift);
if (rc) {
pe_err(pe, "Failed to configure TCE table, err %ld\n", rc);
@@ -2099,7 +2103,8 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
*phb,
phb->ioda.m32_pci_base);
rc = pnv_pci_create_table(&pe->table_group, pe->phb->hose->node,
- 0, IOMMU_PAGE_SHIFT_4K, phb->ioda.m32_pci_base, tbl);
+ 0, IOMMU_PAGE_SHIFT_4K, phb->ioda.m32_pci_base,
+ POWERNV_IOMMU_DEFAULT_LEVELS, tbl);
if (rc) {
pe_err(pe, "Failed to create 32-bit TCE table, err %ld", rc);
return;
diff --git a/arch/powerpc/platforms/powernv/pci.c
b/arch/powerpc/platforms/powernv/pci.c
index 6bcfad5..fc129c4 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -46,6 +46,8 @@
#define cfg_dbg(fmt...) do { } while(0)
//#define cfg_dbg(fmt...) printk(fmt)
+#define ROUND_UP(x, n) (((x) + (n) - 1ULL) & ~((n) - 1ULL))
Use the existing ALIGN_UP macro instead of creating a new one.
Ok. I knew it existed, it is just _ALIGN_UP (with an underscore) and
PPC-only - this is why I did not find it :)
#ifdef CONFIG_PCI_MSI
static int pnv_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
{
@@ -577,6 +579,19 @@ struct pci_ops pnv_pci_ops = {
static __be64 *pnv_tce(struct iommu_table *tbl, long idx)
{
__be64 *tmp = ((__be64 *)tbl->it_base);
+ int leve
Re: regression in ktime.h circa 3.16.0-rc5+ breaks lirc irsend, bad commit 166afb64511
On 2015-04-30 John Stultz wrote: > >From your description it does seem like some sort of edge case > >problem > w/ the 32bit ktime_divns(), but I don't see it right off, and I agree > with Alan to do both calculations and print out warn when that > happens. > > There's also not a ton of users of that function, but ktime_us_delta() > is used in drivers/media/rc/ir-lirc-codec.c, which makes use of it in > ir_lirc_transmit_ir(). > > We should instrument that to see if its calculating negative deltas. Thanks for looking at this! I didn't have the know-how to add the debug code myself (I was scared this fn might be called a zillion times in other kernel operations and overload the system with debug logging). > I'll send you a debug patch to do the above. Got the patch. Sorry for the delay (takes hours to compile using rpmbuild on this old P4 box). I think I have "success" in terms of useful debug output (relevant lines only): May 1 04:41:08 piles lircd: 'lirc' written to protocols file /sys/class/rc/rc0/protocols May 1 04:41:08 piles lircd-0.9.1a[978]: lircd(default) ready, using /var/run/lirc/lircd May 1 04:41:11 piles lircd-0.9.1a[978]: accepted new client on /var/run/lirc/lircd May 1 04:41:11 piles kernel: [ 55.265023] JDB: ktime_to_us: -20782699 -> divns 18446744073688768 != old method: -20783 May 1 04:44:00 piles lircd-0.9.1a[978]: removed client May 1 04:44:00 piles lircd-0.9.1a[978]: caught signal May 1 04:44:00 piles lircd: 'lirc' written to protocols file /sys/class/rc/rc0/protocols May 1 04:44:00 piles lircd-0.9.1a[1523]: lircd(default) ready, using /var/run/lirc/lircd May 1 04:45:03 piles lircd-0.9.1a[1523]: accepted new client on /var/run/lirc/lircd May 1 04:45:03 piles kernel: [ 287.445027] JDB: ktime_to_us: -20599906 -> divns 18446744073688951 != old method: -20600 May 1 04:45:37 piles lircd-0.9.1a[1523]: removed client May 1 04:45:37 piles lircd-0.9.1a[1523]: caught signal May 1 04:45:37 piles lircd: 'lirc' written to protocols file /sys/class/rc/rc0/protocols May 1 04:45:37 piles lircd-0.9.1a[1579]: lircd(default) ready, using /var/run/lirc/lircd May 1 04:45:40 piles lircd-0.9.1a[1579]: accepted new client on /var/run/lirc/lircd May 1 04:45:40 piles kernel: [ 324.209023] JDB: ktime_to_us: -20443355 -> divns 18446744073689108 != old method: -20444 May 1 04:46:12 piles lircd-0.9.1a[1579]: removed client May 1 04:46:12 piles lircd-0.9.1a[1579]: caught signal May 1 04:46:12 piles lircd: 'lirc' written to protocols file /sys/class/rc/rc0/protocols May 1 04:46:12 piles lircd-0.9.1a[1597]: lircd(default) ready, using /var/run/lirc/lircd May 1 04:46:12 piles lircd-0.9.1a[1597]: accepted new client on /var/run/lirc/lircd May 1 04:46:12 piles kernel: [ 356.838029] JDB: ktime_to_us: -20157485 -> divns 18446744073689394 != old method: -20158 The last 2-3 or 3 groups of output I could produce on demand by stopping mythbackend and running: systemctl restart lircd.service ; irsend SEND_ONCE dct700 info Subsequent irsends don't trigger the bug, since (as I found out a while ago) by that point lircd is "hung", at least for a long while. Hey! Maybe lircd is then hung for 18446744073689394 us or ns :-) If this result is used as a delay timer, the negative would produce 0 delay, and the + number the "hang". I calculate that hang is 584 years? :-) So it looks like maybe my theory wasn't so wacky: we're dealing with a caller passing negative numbers (or 32/64 weirdness). Very strange as it seems the caller *wants* (or is happy with) negative numbers! Let me know if you need any more debugging/patch-tests. But give me 4+ hours between rpmbuilds (probably my responses will be 24-hr later). Thanks a million! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PM / sleep: Let devices force direct_complete
Introduce a new per-device flag power.force_direct_complete that will
instruct the PM core to let that device remain in runtime suspend when
the system goes into a sleep power state, regardless of the PM state of
any of its descendants.
This is needed because otherwise it would be needed to get dozens of
drivers to implement the prepare() callback and be runtime PM active
even if they don't have a 1-to-1 relationship with a piece of HW.
This only applies to devices that aren't wakeup-capable, as those would
need to setup their IRQs as wakeup-capable in their prepare() callbacks.
Signed-off-by: Tomeu Vizoso
---
Hi,
I'm sending this as a standalone patch as suggested by Alan.
Thanks,
Tomeu
---
Documentation/power/runtime_pm.txt | 10 ++
drivers/base/power/main.c | 14 ++
include/linux/pm.h | 1 +
3 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/Documentation/power/runtime_pm.txt
b/Documentation/power/runtime_pm.txt
index 44fe1d2..3b0c68d 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -665,6 +665,16 @@ as appropriate. This only applies to system suspend
transitions that are not
related to hibernation (see Documentation/power/devices.txt for more
information).
+For devices that know that can remain runtime suspended when the system
+transitions to a sleep state regardless of the PM state of their descendants,
+the flag power.force_direct_complete can be set on their device structures.
+This can be useful when a real device has several virtual devices as
+descendants and it would be very cumbersome to make sure that they return a
+positive value in their .prepare() callback and have runtime PM enabled. Usage
+of power.force_direct_complete is only allowed to devices that aren't
+wakeup-capable, as they would need to set their IRQs as wakeups in their
+.prepare() callbacks before the system transitions to a sleep state.
+
The PM core does its best to reduce the probability of race conditions between
the runtime PM and system suspend/resume (and hibernation) callbacks by
carrying
out the following operations:
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 3d874ec..7b962f5 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1438,7 +1438,9 @@ static int __device_suspend(struct device *dev,
pm_message_t state, bool async)
if (parent) {
spin_lock_irq(&parent->power.lock);
- dev->parent->power.direct_complete = false;
+ if (!dev->parent->power.force_direct_complete)
+ dev->parent->power.direct_complete = false;
+
if (dev->power.wakeup_path
&& !dev->parent->power.ignore_children)
dev->parent->power.wakeup_path = true;
@@ -1605,9 +1607,13 @@ static int device_prepare(struct device *dev,
pm_message_t state)
* will do the same thing with all of its descendants". This only
* applies to suspend transitions, however.
*/
- spin_lock_irq(&dev->power.lock);
- dev->power.direct_complete = ret > 0 && state.event == PM_EVENT_SUSPEND;
- spin_unlock_irq(&dev->power.lock);
+ if (state.event == PM_EVENT_SUSPEND) {
+ spin_lock_irq(&dev->power.lock);
+ dev->power.direct_complete = ret > 0 ||
+ (dev->power.force_direct_complete &&
+!device_can_wakeup(dev));
+ spin_unlock_irq(&dev->power.lock);
+ }
return 0;
}
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 2d29c64..2e41cfd 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -553,6 +553,7 @@ struct dev_pm_info {
boolignore_children:1;
boolearly_init:1; /* Owned by the PM core */
booldirect_complete:1; /* Owned by the PM core
*/
+ boolforce_direct_complete:1;
spinlock_t lock;
#ifdef CONFIG_PM_SLEEP
struct list_headentry;
--
2.3.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [sched] WARNING: CPU: 0 PID: 0 at kernel/time/hrtimer.c:802 hrtimer_forward()
On Fri, May 01, 2015 at 12:47:13PM +0800, Fengguang Wu wrote: > commit 77a4d1a1b9a122ca1fa3507bd30aec1520d7a8a4 > sched: Cleanup bandwidth timers > [ 64.000438] WARNING: CPU: 0 PID: 0 at kernel/time/hrtimer.c:802 > hrtimer_forward+0x71/0x189() Argh, yes of course. The problem is that the timer can be re-started before the handler acquires the lock, and therefore the hrtimer_forwards in the handler will trigger that WARN. Lemme try and go convince this heap of snot that's occupying my brain cavity to produce coherent thought and come up with a nice fix for that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/11] drivers/pcmcia: include for modular max77802 code
On Thu, Apr 30, 2015 at 09:47:44PM -0400, Paul Gortmaker wrote: > This file is built off of a tristate Kconfig option and also contains > modular function calls so it should explicitly include module.h to > avoid compile breakage during header shuffles done in the future. Why are you sending me PCMCIA patches? signature.asc Description: Digital signature
[tip:perf/urgent] perf trace: Disable events and drain events when forked workload ends
Commit-ID: 02ac5421ddc634767c732f9b6a10a395a9ecfc4f
Gitweb: http://git.kernel.org/tip/02ac5421ddc634767c732f9b6a10a395a9ecfc4f
Author: Arnaldo Carvalho de Melo
AuthorDate: Wed, 22 Apr 2015 11:11:57 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 23 Apr 2015 17:08:08 -0300
perf trace: Disable events and drain events when forked workload ends
We were not checking in the inner event processing loop if the forked workload
had finished, which, on a busy system, may make it take a long time trying to
drain events, entering a seemingly neverending loop, waiting for the system to
get idle enough to make it drain the buffers.
Fix it by disabling the events when 'done' is true, in the inner loop, to start
draining what is in the buffers.
Now:
[root@ssdandy ~]# time trace --filter-pids 14003 -a sleep 1 | tail
996.748 ( 0.002 ms): sh/30296 rt_sigprocmask(how: SETMASK, nset:
0x7ffc83418160, sigsetsize: 8) = 0
996.751 ( 0.002 ms): sh/30296 rt_sigprocmask(how: BLOCK, nset:
0x7ffc834181f0, oset: 0x7ffc83418270, sigsetsize: 8) = 0
996.755 ( 0.002 ms): sh/30296 rt_sigaction(sig: INT, act: 0x7ffc83417f50,
oact: 0x7ffc83417ff0, sigsetsize: 8) = 0
1004.543 ( 0.362 ms): tail/30198 ... [continued]: read()) = 4096
1004.548 ( 7.791 ms): sh/30296 wait4(upid: -1, stat_addr: 0x7ffc834181a0) ...
1004.975 ( 0.427 ms): tail/30198 read(buf: 0x7633f0, count: 8192) = 4096
1005.390 ( 0.410 ms): tail/30198 read(buf: 0x765410, count: 8192) = 4096
1005.743 ( 0.348 ms): tail/30198 read(buf: 0x7633f0, count: 8192) = 4096
1006.197 ( 0.449 ms): tail/30198 read(buf: 0x765410, count: 8192) = 4096
1006.492 ( 0.290 ms): tail/30198 read(buf: 0x7633f0, count: 8192) = 4096
real0m1.219s
user0m0.704s
sys 0m0.331s
[root@ssdandy ~]#
Reported-by: Michael Petlan
Suggested-by: Jiri Olsa
Acked-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Borislav Petkov
Cc: David Ahern
Cc: Don Zickus
Cc: Frederic Weisbecker
Cc: Namhyung Kim
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-p6kpn1b26qcbe47pufpw0...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-trace.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 8842218..e122970 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2273,6 +2273,11 @@ next_event:
if (interrupted)
goto out_disable;
+
+ if (done && !draining) {
+ perf_evlist__disable(evlist);
+ draining = true;
+ }
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf kmem: Consistently use PRIu64 for printing u64 values
Commit-ID: 6145c259cd454bcb7a1288f7bbb7b4fbc18175dd
Gitweb: http://git.kernel.org/tip/6145c259cd454bcb7a1288f7bbb7b4fbc18175dd
Author: Will Deacon
AuthorDate: Thu, 23 Apr 2015 14:40:37 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 23 Apr 2015 17:08:22 -0300
perf kmem: Consistently use PRIu64 for printing u64 values
Building the perf tool for 32-bit ARM results in the following build
error due to a combination of an incorrect conversion specifier and
compiling with -Werror:
builtin-kmem.c: In function ‘print_page_summary’:
builtin-kmem.c:644:9: error: format ‘%lu’ expects argument of type ‘long
unsigned int’, but argument 3 has type ‘u64’ [-Werror=format=]
nr_alloc_freed, (total_alloc_freed_bytes) / 1024);
^
builtin-kmem.c:647:9: error: format ‘%lu’ expects argument of type ‘long
unsigned int’, but argument 3 has type ‘u64’ [-Werror=format=]
(total_page_alloc_bytes - total_alloc_freed_bytes) / 1024);
^
cc1: all warnings being treated as errors
This patch fixes the problem by consistently using PRIu64 for printing
out u64 values.
Signed-off-by: Will Deacon
Cc: David Ahern
Cc: Jiri Olsa
Cc: Joonsoo Kim
Cc: Minchan Kim
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1429796437-1790-1-git-send-email-will.dea...@arm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-kmem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 63ea013..a1915b4 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -640,9 +640,9 @@ static void print_page_summary(void)
nr_page_frees, total_page_free_bytes / 1024);
printf("\n");
- printf("%-30s: %'16lu [ %'16"PRIu64" KB ]\n", "Total alloc+freed
requests",
+ printf("%-30s: %'16"PRIu64" [ %'16"PRIu64" KB ]\n", "Total
alloc+freed requests",
nr_alloc_freed, (total_alloc_freed_bytes) / 1024);
- printf("%-30s: %'16lu [ %'16"PRIu64" KB ]\n", "Total alloc-only
requests",
+ printf("%-30s: %'16"PRIu64" [ %'16"PRIu64" KB ]\n", "Total alloc-only
requests",
nr_page_allocs - nr_alloc_freed,
(total_page_alloc_bytes - total_alloc_freed_bytes) / 1024);
printf("%-30s: %'16lu [ %'16"PRIu64" KB ]\n", "Total free-only
requests",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH kernel v9 20/32] powerpc/powernv/ioda2: Introduce pnv_pci_create_table/pnv_pci_free_table
On 04/29/2015 02:39 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:44PM +1000, Alexey Kardashevskiy wrote:
This is a part of moving TCE table allocation into an iommu_ops
callback to support multiple IOMMU groups per one VFIO container.
This moves a table creation window to the file with common powernv-pci
helpers as it does not do anything IODA2-specific.
This adds pnv_pci_free_table() helper to release the actual TCE table.
This enforces window size to be a power of two.
This should cause no behavioural change.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: David Gibson
---
Changes:
v9:
* moved helpers to the common powernv pci.c file from pci-ioda.c
* moved bits from pnv_pci_create_table() to pnv_alloc_tce_table_pages()
---
arch/powerpc/platforms/powernv/pci-ioda.c | 36 ++
arch/powerpc/platforms/powernv/pci.c | 61 +++
arch/powerpc/platforms/powernv/pci.h | 4 ++
3 files changed, 76 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index a80be34..b9b3773 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1307,8 +1307,7 @@ static void pnv_pci_ioda2_release_dma_pe(struct pci_dev
*dev, struct pnv_ioda_pe
if (rc)
pe_warn(pe, "OPAL error %ld release DMA window\n", rc);
- iommu_reset_table(tbl, of_node_full_name(dev->dev.of_node));
- free_pages(addr, get_order(TCE32_TABLE_SIZE));
+ pnv_pci_free_table(tbl);
}
static void pnv_ioda_release_vf_PE(struct pci_dev *pdev, u16 num_vfs)
@@ -2039,10 +2038,7 @@ static struct iommu_table_group_ops pnv_pci_ioda2_ops = {
static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
struct pnv_ioda_pe *pe)
{
- struct page *tce_mem = NULL;
- void *addr;
struct iommu_table *tbl = &pe->table_group.tables[0];
- unsigned int tce_table_size, end;
int64_t rc;
/* We shouldn't already have a 32-bit DMA associated */
@@ -2053,29 +2049,20 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
*phb,
/* The PE will reserve all possible 32-bits space */
pe->tce32_seg = 0;
- end = (1 << ilog2(phb->ioda.m32_pci_base));
- tce_table_size = (end / 0x1000) * 8;
pe_info(pe, "Setting up 32-bit TCE table at 0..%08x\n",
- end);
+ phb->ioda.m32_pci_base);
- /* Allocate TCE table */
- tce_mem = alloc_pages_node(phb->hose->node, GFP_KERNEL,
- get_order(tce_table_size));
- if (!tce_mem) {
- pe_err(pe, "Failed to allocate a 32-bit TCE memory\n");
- goto fail;
+ rc = pnv_pci_create_table(&pe->table_group, pe->phb->hose->node,
+ 0, IOMMU_PAGE_SHIFT_4K, phb->ioda.m32_pci_base, tbl);
+ if (rc) {
+ pe_err(pe, "Failed to create 32-bit TCE table, err %ld", rc);
+ return;
}
- addr = page_address(tce_mem);
- memset(addr, 0, tce_table_size);
-
- /* Setup iommu */
- tbl->it_table_group = &pe->table_group;
-
- /* Setup linux iommu table */
- pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, 0,
- IOMMU_PAGE_SHIFT_4K);
tbl->it_ops = &pnv_ioda2_iommu_ops;
+
+ /* Setup iommu */
+ tbl->it_table_group = &pe->table_group;
iommu_init_table(tbl, phb->hose->node);
#ifdef CONFIG_IOMMU_API
pe->table_group.ops = &pnv_pci_ioda2_ops;
@@ -2121,8 +2108,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
*phb,
fail:
if (pe->tce32_seg >= 0)
pe->tce32_seg = -1;
- if (tce_mem)
- __free_pages(tce_mem, get_order(tce_table_size));
+ pnv_pci_free_table(tbl);
}
static void pnv_ioda_setup_dma(struct pnv_phb *phb)
diff --git a/arch/powerpc/platforms/powernv/pci.c
b/arch/powerpc/platforms/powernv/pci.c
index e8802ac..6bcfad5 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -20,7 +20,9 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -645,6 +647,65 @@ void pnv_pci_setup_iommu_table(struct iommu_table *tbl,
tbl->it_type = TCE_PCI;
}
+static __be64 *pnv_alloc_tce_table_pages(int nid, unsigned shift,
+ unsigned long *tce_table_allocated)
I'm a bit confused by the tce_table_allocated parameter. What's the
circumstance where more memory is requested than required, and why
does it matter to the caller?
+{
+ struct page *tce_mem = NULL;
+ __be64 *addr;
+ unsigned order = max_t(unsigned, shift, PAGE_SHIFT) - PAGE_SHIFT;
+ unsigned long local_allocated = 1UL << (order + PAGE_SHIFT);
+
+ tce_mem = alloc_pages_node(nid, GFP_KERNEL, order);
+ if (!tce_mem) {
+
[tip:perf/urgent] perf trace: Enable events when doing system wide tracing and starting a workload
Commit-ID: cb24d01d217497fb32467de22d773655f47d3896 Gitweb: http://git.kernel.org/tip/cb24d01d217497fb32467de22d773655f47d3896 Author: Arnaldo Carvalho de Melo AuthorDate: Wed, 22 Apr 2015 10:04:23 -0300 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 23 Apr 2015 17:07:59 -0300 perf trace: Enable events when doing system wide tracing and starting a workload commit f7aa222ff397 Author: Arnaldo Carvalho de Melo Date: Tue Feb 3 13:25:39 2015 -0300 perf trace: No need to enable evsels for workload started from perf The assumption was that whenever a workload is specified, the attr.enable_on_exec evsel flag would be set, but that is not happening when perf_record_opts.system_wide is set, for instance That resulted in both perf_evlist__enable() and attr.enable_on_exec being not called/set, which made the events to remain disabled while the workload runs, producing no output. Fix it, by calling perf_evlist__enable() in the 'trace' tool when forking and not targetting a workload started from trace v2: Test against !target__none(), as suggested by Namhyung Kim, that is what is used in perf_evsel__config() when deciding if the attr.enable_on_exec flag to be set. More work is needed to cover other cases such as opts->initial_delay. Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Borislav Petkov Cc: David Ahern Cc: Don Zickus Cc: Frederic Weisbecker Cc: Namhyung Kim Cc: Stephane Eranian Link: http://lkml.kernel.org/n/tip-27z7169pvfxgj8upic636...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/builtin-trace.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c index e124741..8842218 100644 --- a/tools/perf/builtin-trace.c +++ b/tools/perf/builtin-trace.c @@ -2241,10 +2241,11 @@ static int trace__run(struct trace *trace, int argc, const char **argv) if (err < 0) goto out_error_mmap; + if (!target__none(&trace->opts.target)) + perf_evlist__enable(evlist); + if (forks) perf_evlist__start_workload(evlist); - else - perf_evlist__enable(evlist); trace->multiple_threads = evlist->threads->map[0] == -1 || evlist->threads->nr > 1 || -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] tools lib traceevent: Fix build failure on 32-bit arch
Commit-ID: 410ceb8f2f1d4edeb02d229ef192e76602005b8b
Gitweb: http://git.kernel.org/tip/410ceb8f2f1d4edeb02d229ef192e76602005b8b
Author: Namhyung Kim
AuthorDate: Fri, 24 Apr 2015 10:45:16 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 24 Apr 2015 12:47:10 -0300
tools lib traceevent: Fix build failure on 32-bit arch
In my i386 build, it failed like this:
CC event-parse.o
event-parse.c: In function 'print_str_arg':
event-parse.c:3868:5: warning: format '%lu' expects argument of type 'long
unsigned int',
but argument 3 has type 'uint64_t' [-Wformat]
Signed-off-by: Namhyung Kim
Acked-by: Javi Merino
Link: http://lkml.kernel.org/r/20150424020218.GF1905@sejong
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/event-parse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 12a7e2a..aa21bd5 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -3865,7 +3865,7 @@ static void print_str_arg(struct trace_seq *s, void
*data, int size,
} else if (el_size == 4) {
trace_seq_printf(s, "%u", *(uint32_t *)num);
} else if (el_size == 8) {
- trace_seq_printf(s, "%lu", *(uint64_t *)num);
+ trace_seq_printf(s, "%"PRIu64, *(uint64_t
*)num);
} else {
trace_seq_printf(s, "BAD SIZE:%d 0x%x",
el_size, *(uint8_t *)num);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf kmem: Fix compiles on RHEL6/OL6
Commit-ID: 4ad1f4300e3bddf63109aa63cfb2d37e8585ecc7
Gitweb: http://git.kernel.org/tip/4ad1f4300e3bddf63109aa63cfb2d37e8585ecc7
Author: David Ahern
AuthorDate: Tue, 14 Apr 2015 13:49:33 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 24 Apr 2015 12:44:47 -0300
perf kmem: Fix compiles on RHEL6/OL6
0d68bc92c48 breaks compiles on RHEL6/OL6:
cc1: warnings being treated as errors
builtin-kmem.c: In function ‘search_page_alloc_stat’:
builtin-kmem.c:322: error: declaration of ‘stat’ shadows a global
declaration
node = &parent->rb_left;
/usr/include/sys/stat.h:455: error: shadowed declaration is here
builtin-kmem.c: In function ‘perf_evsel__process_page_alloc_event’:
builtin-kmem.c:378: error: declaration of ‘stat’ shadows a global
declaration
/usr/include/sys/stat.h:455: error: shadowed declaration is here
builtin-kmem.c: In function ‘perf_evsel__process_page_free_event’:
builtin-kmem.c:431: error: declaration of ‘stat’ shadows a global
declaration
/usr/include/sys/stat.h:455: error: shadowed declaration is here
Rename local variable to pstat to avoid the name conflict.
Signed-off-by: David Ahern
Link:
http://lkml.kernel.org/r/1429033773-31383-1-git-send-email-david.ah...@oracle.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-kmem.c | 54 +++
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index a1915b4..1634186 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -319,7 +319,7 @@ static int page_stat_cmp(struct page_stat *a, struct
page_stat *b)
return 0;
}
-static struct page_stat *search_page_alloc_stat(struct page_stat *stat, bool
create)
+static struct page_stat *search_page_alloc_stat(struct page_stat *pstat, bool
create)
{
struct rb_node **node = &page_alloc_tree.rb_node;
struct rb_node *parent = NULL;
@@ -331,7 +331,7 @@ static struct page_stat *search_page_alloc_stat(struct
page_stat *stat, bool cre
parent = *node;
data = rb_entry(*node, struct page_stat, node);
- cmp = page_stat_cmp(data, stat);
+ cmp = page_stat_cmp(data, pstat);
if (cmp < 0)
node = &parent->rb_left;
else if (cmp > 0)
@@ -345,10 +345,10 @@ static struct page_stat *search_page_alloc_stat(struct
page_stat *stat, bool cre
data = zalloc(sizeof(*data));
if (data != NULL) {
- data->page = stat->page;
- data->order = stat->order;
- data->gfp_flags = stat->gfp_flags;
- data->migrate_type = stat->migrate_type;
+ data->page = pstat->page;
+ data->order = pstat->order;
+ data->gfp_flags = pstat->gfp_flags;
+ data->migrate_type = pstat->migrate_type;
rb_link_node(&data->node, parent, node);
rb_insert_color(&data->node, &page_alloc_tree);
@@ -375,7 +375,7 @@ static int perf_evsel__process_page_alloc_event(struct
perf_evsel *evsel,
unsigned int migrate_type = perf_evsel__intval(evsel, sample,
"migratetype");
u64 bytes = kmem_page_size << order;
- struct page_stat *stat;
+ struct page_stat *pstat;
struct page_stat this = {
.order = order,
.gfp_flags = gfp_flags,
@@ -401,21 +401,21 @@ static int perf_evsel__process_page_alloc_event(struct
perf_evsel *evsel,
* This is to find the current page (with correct gfp flags and
* migrate type) at free event.
*/
- stat = search_page(page, true);
- if (stat == NULL)
+ pstat = search_page(page, true);
+ if (pstat == NULL)
return -ENOMEM;
- stat->order = order;
- stat->gfp_flags = gfp_flags;
- stat->migrate_type = migrate_type;
+ pstat->order = order;
+ pstat->gfp_flags = gfp_flags;
+ pstat->migrate_type = migrate_type;
this.page = page;
- stat = search_page_alloc_stat(&this, true);
- if (stat == NULL)
+ pstat = search_page_alloc_stat(&this, true);
+ if (pstat == NULL)
return -ENOMEM;
- stat->nr_alloc++;
- stat->alloc_bytes += bytes;
+ pstat->nr_alloc++;
+ pstat->alloc_bytes += bytes;
order_stats[order][migrate_type]++;
@@ -428,7 +428,7 @@ static int perf_evsel__process_page_free_event(struct
perf_evsel *evsel,
u64 page;
unsigned int order = perf_evsel__intval(evsel, sample, "order");
u64 bytes = kmem_page_size << order;
- struct page_stat *stat;
+ struct page_stat *pstat;
struct page_stat this = {
.order = order,
};
@@ -441,8 +441,8 @@ static int perf_evsel__process_page_fre
Re: [PATCH v4 1/2] locking/rwsem: reduce spinlock contention in wakeup after up_read/up_write
On Thu, Apr 30, 2015 at 05:12:16PM -0400, Waiman Long wrote: > In up_write()/up_read(), rwsem_wake() will be called whenever it > detects that some writers/readers are waiting. The rwsem_wake() > function will take the wait_lock and call __rwsem_do_wake() to do the > real wakeup. For a heavily contended rwsem, doing a spin_lock() on > wait_lock will cause further contention on the heavily contended rwsem > cacheline resulting in delay in the completion of the up_read/up_write > operations. > > This patch makes the wait_lock taking and the call to __rwsem_do_wake() > optional if at least one spinning writer is present. The spinning > writer will be able to take the rwsem and call rwsem_wake() later > when it calls up_write(). With the presence of a spinning writer, > rwsem_wake() will now try to acquire the lock using trylock. If that > fails, it will just quit. > > Signed-off-by: Waiman Long > Suggested-by: Peter Zijlstra (Intel) > --- Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] tools lib api: Undefine _FORTIFY_SOURCE before setting it
Commit-ID: de28c15daf60e9625bece22f13a091fac8d05f1d Gitweb: http://git.kernel.org/tip/de28c15daf60e9625bece22f13a091fac8d05f1d Author: Bobby Powers AuthorDate: Tue, 21 Apr 2015 19:19:41 -0400 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 23 Apr 2015 17:08:23 -0300 tools lib api: Undefine _FORTIFY_SOURCE before setting it Some toolchains (like Hardened Gentoo) define _FORTIFY_SOURCE in the built-in, default args. This causes perf builds to fail with: :0:0: error: "_FORTIFY_SOURCE" redefined [-Werror] : note: this is the location of the previous definition cc1: all warnings being treated as errors To avoid this, undefine _FORTIFY_SOURCE before (possibly re-)defining it in tools/lib/api. v2 applies cleanly on top of already pulled kbuild changes for 4.1-rc1. Signed-off-by: Bobby Powers Acked-by: Jiri Olsa Cc: Dirk Gouders Cc: Michal Marek Cc: Paul Mackerras Cc: Peter Zijlstra Cc: linux-kbu...@vger.kernel.org Link: http://lkml.kernel.org/r/1429658381-3039-1-git-send-email-bobbypow...@gmail.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/lib/api/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/lib/api/Makefile b/tools/lib/api/Makefile index d8fe29f..8bd9606 100644 --- a/tools/lib/api/Makefile +++ b/tools/lib/api/Makefile @@ -16,7 +16,7 @@ MAKEFLAGS += --no-print-directory LIBFILE = $(OUTPUT)libapi.a CFLAGS := $(EXTRA_WARNINGS) $(EXTRA_CFLAGS) -CFLAGS += -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -D_FORTIFY_SOURCE=2 -fPIC +CFLAGS += -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fPIC CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 RM = rm -f -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf bench futex: Fix hung wakeup tasks after requeueing
Commit-ID: 052b0f6eaf8b1f02669884a177bc3ce463133a42
Gitweb: http://git.kernel.org/tip/052b0f6eaf8b1f02669884a177bc3ce463133a42
Author: Davidlohr Bueso
AuthorDate: Fri, 24 Apr 2015 10:00:48 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 27 Apr 2015 13:57:49 -0300
perf bench futex: Fix hung wakeup tasks after requeueing
The futex-requeue benchmark can hang because of missing wakeups once the
benchmark is done, ie:
[Run 1]: Requeued 1024 of 1024 threads in 0.3290 ms
perf: couldn't wakeup all tasks (135/1024)
This bug, while perhaps suggesting missing wakeups in kernel futex code,
is merely a consequence of the crappy FUTEX_CMP_REQUEUE man page,
incorrectly mentioning that the number of requeued tasks is in fact
returned, not the wakeups.
This patch acknowledges this and updates the corresponding futex_wake
code around it.
Signed-off-by: Davidlohr Bueso
Cc: Mel Gorman
Link: http://lkml.kernel.org/r/1429894848.10273.44.ca...@stgolabs.net
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/bench/futex-requeue.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/tools/perf/bench/futex-requeue.c b/tools/perf/bench/futex-requeue.c
index bedff6b..ad0d9b5 100644
--- a/tools/perf/bench/futex-requeue.c
+++ b/tools/perf/bench/futex-requeue.c
@@ -132,6 +132,9 @@ int bench_futex_requeue(int argc, const char **argv,
if (!fshared)
futex_flag = FUTEX_PRIVATE_FLAG;
+ if (nrequeue > nthreads)
+ nrequeue = nthreads;
+
printf("Run summary [PID %d]: Requeuing %d threads (from [%s] %p to
%p), "
"%d at a time.\n\n", getpid(), nthreads,
fshared ? "shared":"private", &futex1, &futex2, nrequeue);
@@ -161,20 +164,18 @@ int bench_futex_requeue(int argc, const char **argv,
/* Ok, all threads are patiently blocked, start requeueing */
gettimeofday(&start, NULL);
- for (nrequeued = 0; nrequeued < nthreads; nrequeued +=
nrequeue) {
+ while (nrequeued < nthreads) {
/*
* Do not wakeup any tasks blocked on futex1, allowing
* us to really measure futex_wait functionality.
*/
- futex_cmp_requeue(&futex1, 0, &futex2, 0,
- nrequeue, futex_flag);
+ nrequeued += futex_cmp_requeue(&futex1, 0, &futex2, 0,
+ nrequeue, futex_flag);
}
+
gettimeofday(&end, NULL);
timersub(&end, &start, &runtime);
- if (nrequeued > nthreads)
- nrequeued = nthreads;
-
update_stats(&requeued_stats, nrequeued);
update_stats(&requeuetime_stats, runtime.tv_usec);
@@ -184,7 +185,7 @@ int bench_futex_requeue(int argc, const char **argv,
}
/* everybody should be blocked on futex2, wake'em up */
- nrequeued = futex_wake(&futex2, nthreads, futex_flag);
+ nrequeued = futex_wake(&futex2, nrequeued, futex_flag);
if (nthreads != nrequeued)
warnx("couldn't wakeup all tasks (%d/%d)", nrequeued,
nthreads);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf bench numa: Fixes of --quiet argument
Commit-ID: 24f1ced167e5e011040b4c3aae75aee45a79eed5
Gitweb: http://git.kernel.org/tip/24f1ced167e5e011040b4c3aae75aee45a79eed5
Author: Petr Holasek
AuthorDate: Thu, 16 Apr 2015 17:38:17 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 27 Apr 2015 13:57:49 -0300
perf bench numa: Fixes of --quiet argument
Corrected description and fixed function of --quiet argument.
Signed-off-by: Petr Holasek
Reviewed-by: Ingo Molnar
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1429198699-25039-2-git-send-email-phola...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/bench/numa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
index ebfa163..cd872e9c 100644
--- a/tools/perf/bench/numa.c
+++ b/tools/perf/bench/numa.c
@@ -180,7 +180,7 @@ static const struct option options[] = {
OPT_INTEGER('H', "thp" , &p0.thp,
"MADV_NOHUGEPAGE < 0 < MADV_HUGEPAGE"),
OPT_BOOLEAN('c', "show_convergence", &p0.show_convergence, "show
convergence details"),
OPT_BOOLEAN('m', "measure_convergence", &p0.measure_convergence,
"measure convergence latency"),
- OPT_BOOLEAN('q', "quiet", &p0.show_quiet, "bzero the
initial allocations"),
+ OPT_BOOLEAN('q', "quiet", &p0.show_quiet, "quiet mode"),
OPT_BOOLEAN('S', "serialize-startup", &p0.serialize_startup,"serialize
thread startup"),
/* Special option string parsing callbacks: */
@@ -1395,7 +1395,7 @@ static void print_res(const char *name, double val,
if (!name)
name = "main,";
- if (g->p.show_quiet)
+ if (!g->p.show_quiet)
printf(" %-30s %15.3f, %-15s %s\n", name, val, txt_unit,
txt_short);
else
printf(" %14.3f %s\n", val, txt_long);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf top: Fix a segfault when kernel map is restricted.
Commit-ID: c671835021798c1c40ca0b55b49feff76ed5e0e1
Gitweb: http://git.kernel.org/tip/c671835021798c1c40ca0b55b49feff76ed5e0e1
Author: Wang Nan
AuthorDate: Sat, 25 Apr 2015 07:25:03 +
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 27 Apr 2015 13:24:32 -0300
perf top: Fix a segfault when kernel map is restricted.
Perf top raise a warning if a kernel sample is collected but kernel map
is restricted. The warning message needs to dereference al.map->dso...
However, previous perf_event__preprocess_sample() doesn't always
guarantee al.map != NULL, for example, when kernel map is restricted.
This patch validates al.map before dereferencing, avoid the segfault.
Before this patch:
$ cat /proc/sys/kernel/kptr_restrict
1
$ perf top -p 120183
perf: Segmentation fault
backtrace
/path/to/perf[0x509868]
/lib64/libc.so.6(+0x3545f)[0x7f9a1540045f]
/path/to/perf[0x448820]
/path/to/perf(cmd_top+0xe3c)[0x44a5dc]
/path/to/perf[0x4766a2]
/path/to/perf(main+0x5f5)[0x42e545]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x7f9a153ecbd4]
/path/to/perf[0x42e674]
And gdb call trace:
Program received signal SIGSEGV, Segmentation fault.
perf_event__process_sample (machine=0xa44030, sample=0x7fffa4c0,
evsel=0xa43b00, event=0x741c3000, tool=0x7fffa8a0)
at builtin-top.c:736
736
!RB_EMPTY_ROOT(&al.map->dso->symbols[MAP__FUNCTION]) ?
(gdb) bt
#0 perf_event__process_sample (machine=0xa44030, sample=0x7fffa4c0,
evsel=0xa43b00, event=0x741c3000, tool=0x7fffa8a0)
at builtin-top.c:736
#1 perf_top__mmap_read_idx (top=top@entry=0x7fffa8a0, idx=idx@entry=0) at
builtin-top.c:855
#2 0x0044a5dd in perf_top__mmap_read (top=0x7fffa8a0) at
builtin-top.c:872
#3 __cmd_top (top=0x7fffa8a0) at builtin-top.c:997
#4 cmd_top (argc=, argv=, prefix=) at builtin-top.c:1267
#5 0x004766a3 in run_builtin (p=p@entry=0x8a6ce8 ,
argc=argc@entry=3, argv=argv@entry=0x7fffdf70)
at perf.c:371
#6 0x0042e546 in handle_internal_command (argv=0x7fffdf70,
argc=3) at perf.c:430
#7 run_argv (argv=0x7fffdcf0, argcp=0x7fffdcfc) at perf.c:474
#8 main (argc=3, argv=0x7fffdf70) at perf.c:589
(gdb)
Signed-off-by: Wang Nan
Tested-by: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Zefan Li
Link:
http://lkml.kernel.org/r/1429946703-80807-1-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-top.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 1cb3436..6a4d5d4 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -733,7 +733,7 @@ static void perf_event__process_sample(struct perf_tool
*tool,
"Kernel address maps (/proc/{kallsyms,modules}) are restricted.\n\n"
"Check /proc/sys/kernel/kptr_restrict.\n\n"
"Kernel%s samples will not be resolved.\n",
- !RB_EMPTY_ROOT(&al.map->dso->symbols[MAP__FUNCTION]) ?
+ al.map &&
!RB_EMPTY_ROOT(&al.map->dso->symbols[MAP__FUNCTION]) ?
" modules" : "");
if (use_browser <= 0)
sleep(5);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf bench numa: Fix immediate meeting of convergence condition
Commit-ID: 1d90a685eb75a56648d7dd22c704a1a6da516de9
Gitweb: http://git.kernel.org/tip/1d90a685eb75a56648d7dd22c704a1a6da516de9
Author: Petr Holasek
AuthorDate: Thu, 16 Apr 2015 17:38:19 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 27 Apr 2015 13:57:50 -0300
perf bench numa: Fix immediate meeting of convergence condition
This patch fixes the race in the beginning of benchmark run when some
threads hasn't got assigned curr_cpu yet so they don't occur in
nodes-of-process stats and benchmark concludes that all remaining
threads are converged already.
The race can be reproduced with small amount of threads and some bigger
amount of shared process memory, e.g. one process, two threads and 5GB
of process memory.
Signed-off-by: Petr Holasek
Reviewed-by: Ingo Molnar
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1429198699-25039-4-git-send-email-phola...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/bench/numa.c | 8
1 file changed, 8 insertions(+)
diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
index cd872e9c..ba5efa4 100644
--- a/tools/perf/bench/numa.c
+++ b/tools/perf/bench/numa.c
@@ -828,6 +828,9 @@ static int count_process_nodes(int process_nr)
td = g->threads + task_nr;
node = numa_node_of_cpu(td->curr_cpu);
+ if (node < 0) /* curr_cpu was likely still -1 */
+ return 0;
+
node_present[node] = 1;
}
@@ -882,6 +885,11 @@ static void calc_convergence_compression(int *strong)
for (p = 0; p < g->p.nr_proc; p++) {
unsigned int nodes = count_process_nodes(p);
+ if (!nodes) {
+ *strong = 0;
+ return;
+ }
+
nodes_min = min(nodes, nodes_min);
nodes_max = max(nodes, nodes_max);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf probe: Fix bug with global variables handling
Commit-ID: d13855ef18e1852b2c4dc86ddf5759c5b34628cb
Gitweb: http://git.kernel.org/tip/d13855ef18e1852b2c4dc86ddf5759c5b34628cb
Author: He Kuang
AuthorDate: Sat, 25 Apr 2015 16:08:58 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 27 Apr 2015 13:57:29 -0300
perf probe: Fix bug with global variables handling
There are missing curly braces which causes find_variable() return wrong
value when probing with global variables.
This problem can be reproduced as following:
$ perf probe -v --add='generic_perform_write global_variable_for_test'
...
Try to find probe point from debuginfo.
Probe point found: generic_perform_write+0
Searching 'global_variable_for_test' variable in context.
An error occurred in debuginfo analysis (-2).
Error: Failed to add events. Reason: No such file or directory (Code: -2)
After this patch:
$ perf probe -v --add='generic_perform_write global_variable_for_test'
...
Converting variable global_variable_for_test into trace event.
global_variable_for_test type is int.
Found 1 probe_trace_events.
Opening /sys/kernel/debug/tracing/kprobe_events write=1
Added new event:
Writing event: p:probe/generic_perform_write _stext+1237464
global_variable_for_test=@global_variable_for_test+0:s32
probe:generic_perform_write (on generic_perform_write with
global_variable_for_test)
You can now use it in all perf tools, such as:
perf record -e probe:generic_perform_write -aR sleep 1
Signed-off-by: He Kuang
Acked-by: Masami Hiramatsu
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1429949338-18678-1-git-send-email-heku...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/probe-finder.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 44554c3..1c3cc07 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -578,10 +578,12 @@ static int find_variable(Dwarf_Die *sc_die, struct
probe_finder *pf)
/* Search child die for local variables and parameters. */
if (!die_find_variable_at(sc_die, pf->pvar->var, pf->addr, &vr_die)) {
/* Search again in global variables */
- if (!die_find_variable_at(&pf->cu_die, pf->pvar->var, 0,
&vr_die))
+ if (!die_find_variable_at(&pf->cu_die, pf->pvar->var,
+ 0, &vr_die)) {
pr_warning("Failed to find '%s' in this function.\n",
pf->pvar->var);
ret = -ENOENT;
+ }
}
if (ret >= 0)
ret = convert_variable(&vr_die, pf);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6] block: loop: avoiding too many pending per work I/O
On Fri, May 01, 2015 at 11:28:01AM +0800, Ming Lei wrote: > If there are too many pending per work I/O, too many > high priority work thread can be generated so that > system performance can be effected. > > This patch limits the max pending per work I/O as 16, > and will fackback to single queue mode when the max > number is reached. Why would you do this fall back? Shouldn't we just communicate a concurrency limit to the workqueue code? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] x86/mce: Define 'SUCCOR' cpuid bit
On Thu, Apr 30, 2015 at 09:49:22AM -0500, Aravind Gopalakrishnan wrote:
> SUCCOR stands for S/W UnCorrectable error COntainment and Recovery.
> It indicates support for data poisoning in HW and deferred error
> interrupts.
>
> Add new bitfield in mce_vendor_flags for this.
> We use this to verify prescence of deferred error interrupts
> before we enable them in mce_amd.c
>
> Signed-off-by: Aravind Gopalakrishnan
> ---
> arch/x86/include/asm/mce.h | 3 ++-
> arch/x86/kernel/cpu/mcheck/mce.c | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
> index 1f5a86d..dfcb664 100644
> --- a/arch/x86/include/asm/mce.h
> +++ b/arch/x86/include/asm/mce.h
> @@ -118,7 +118,8 @@ struct mca_config {
>
> struct mce_vendor_flags {
> __u64 overflow_recov : 1, /* cpuid_ebx(8007) */
> - __reserved_0: 63;
> + succor : 1,
Please add that CPUID bit definition from the commit message here too so
that we know what it means.
> + __reserved_0: 62;
> };
> extern struct mce_vendor_flags mce_flags;
>
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> b/arch/x86/kernel/cpu/mcheck/mce.c
> index e535533..de61f62e 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -1640,6 +1640,7 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86
> *c)
> case X86_VENDOR_AMD:
> mce_amd_feature_init(c);
> mce_flags.overflow_recov = cpuid_ebx(0x8007) & 0x1;
> + mce_flags.succor = (cpuid_ebx(0x8007) & 0x2) ? 1 : 0;
mce_flags.succor = !!(cpuid_ebx(0x8007) & BIT(1));
is a common way of assigning truth values from bits in the kernel.
You can change the above one to use BIT(0) too, while at it, and
vertically align the assignments.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] regulator: Add regulator driver for the MC34708 PMIC
Hi Martin, > Martin Fuzzey hat am 28. April 2015 um 16:17 > geschrieben: > > > Add regulator driver and associated DT bindings for the regulators in the > Freescale MC34708 PMIC. from my understanding this PMIC is used typically for i.MX50/53 SoCs. So in this case it would make sense to mention it here and CC this patch series also to the IMX maintainers. Btw git format-patch --cover-letter is your friend. Stefan > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: acpi: make ACPI_PROCFS_POWER X86 only
The ACPI procfs power interface is initialized by compilation units that are only selectable on X86 platforms. Since its usage is deprecated and it cannot even be used on platforms other than X86 it should be compiled in only on X86 platforms. This patch makes CONFIG_ACPI_PROCFS_POWER dependent on X86, so that other architectures are prevented from compiling it in for no purpose. Signed-off-by: Lorenzo Pieralisi Cc: Hanjun Guo Cc: Lan Tianyu Cc: Rafael J. Wysocki --- Lan, Rafael, I do not see any reason why this option is allowed to be selected on platforms other than X86, so let's make it X86 only. Please let me know what you think, thanks. Lorenzo drivers/acpi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index ab2cbb5..16da185 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -62,7 +62,7 @@ config ACPI_SLEEP config ACPI_PROCFS_POWER bool "Deprecated power /proc/acpi directories" - depends on PROC_FS + depends on X86 && PROC_FS help For backwards compatibility, this option allows deprecated power /proc/acpi/ directories to exist, even when -- 2.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] m68k: use for_each_sg()
2015-05-01 18:07 GMT+09:00 Geert Uytterhoeven : > Hi Mita-san, > > On Fri, May 1, 2015 at 8:47 AM, Akinobu Mita wrote: >> Since m68k doesn't select ARCH_HAS_SG_CHAIN, it is not necessary to >> use for_each_sg() in order to loop over each sg element. But this can >> help find problems with drivers that do not properly initialize their >> sg tables when CONFIG_DEBUG_SG is enabled. >> >> Signed-off-by: Akinobu Mita >> Cc: Geert Uytterhoeven >> Cc: linux-m...@lists.linux-m68k.org >> Cc: linux-a...@vger.kernel.org > > Acked-by: Geert Uytterhoeven > > Do you want me to queue this up for v4.2, or do you want to handle these > changes yourself, together with "[PATCH] scatterlist: enable sg chaining > for all architectures"? Hi Geert, Please queue it up to your tree. As it turned out that enabling sg chaining for all architectures requires more survey, I've just started trivial works like this. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Regulator: mc34708: Add DT binding documentation
Hi Martin, > Martin Fuzzey hat am 28. April 2015 um 16:17 > geschrieben: > > > Signed-off-by: Martin Fuzzey a commit message would be nice and the subject should specify dt-bindings instead of regulator subsystem. Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests
On 30/04/15 20:08, Boris Ostrovsky wrote:
> Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor
> attribute issue") makes AMD processors set SS to __KERNEL_DS in
> __switch_to() to deal with cases when SS is NULL.
>
> This breaks Xen PV guests who do not want to load SS with__KERNEL_DS.
>
> Since the problem that the commit is trying to address would have to be
> fixed in the hypervisor (if it in fact exists under Xen) there is no
> reason to set X86_BUG_SYSRET_SS_ATTRS flag for PV VPCUs here.
>
> This can be easily achieved by adding x86_hyper_xen_hvm.set_cpu_features
> op which will clear this flag. (And since this structure is no longer
> HVM-specific we should do some renaming).
Applied to for-linus-4.1b, thanks.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Regulator: add driver for Freescale MC34708
Hi Martin, > Martin Fuzzey hat am 28. April 2015 um 16:17 > geschrieben: > > > [...] > diff --git a/drivers/regulator/mc34708-regulator.c > b/drivers/regulator/mc34708-regulator.c > new file mode 100644 > index 000..b5ff727 > --- /dev/null > +++ b/drivers/regulator/mc34708-regulator.c > @@ -0,0 +1,1266 @@ > +/* > + * Driver for regulators in the Fresscale MC34708/9 PMICs > + * just a typo: Freescale Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH v2 2/4] xen/xenbus: Update xenbus event channel on resume
On 29/04/15 22:10, Boris Ostrovsky wrote: > After a resume the hypervisor/tools may change xenbus event > channel number. We should re-query it. Reviewed-by: David Vrabel David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH v2 1/4] xen/events: Clear cpu_evtchn_mask before resuming
On 29/04/15 22:10, Boris Ostrovsky wrote:
> When a guest is resumed, the hypervisor may change event channel
> assignments. If this happens and the guest uses 2-level events it
> is possible for the interrupt to be claimed by wrong VCPU since
> cpu_evtchn_mask bits may be stale. This can happen even though
> evtchn_2l_bind_to_cpu() attempts to clear old bits: irq_info that
> is passed in is not necessarily the original one (from pre-migration
> times) but instead is freshly allocated during resume and so any
> information about which CPU the channel was bound to is lost.
>
> Thus we should clear the mask during resume.
>
> We also need to make sure that bits for xenstore and console channels
> are set when these two subsystems are resumed. While rebind_evtchn_irq()
> (which is invoked for both of them on a resume) calls irq_set_affinity(),
> the latter will in fact postpone setting affinity until handling the
> interrupt. But because cpu_evtchn_mask will have bits for these two
> cleared we won't be able to take the interrupt.
>
> With that in mind, we need to bind those two channels explicitly in
> rebind_evtchn_irq(). We will keep irq_set_affinity() so that we have a
> pass through generic irq affinity code later, in case something needs
> to be updated there as well.
>
> (Also replace cpumask_of(0) with cpumask_of(info->cpu) in
> rebind_evtchn_irq(): it should be set to zero in preceding
> xen_irq_info_evtchn_setup().)
[...]
> @@ -1279,8 +1280,16 @@ void rebind_evtchn_irq(int evtchn, int irq)
>
> mutex_unlock(&irq_mapping_update_lock);
>
> - /* new event channels are always bound to cpu 0 */
> - irq_set_affinity(irq, cpumask_of(0));
> + bind_vcpu.port = evtchn;
> + bind_vcpu.vcpu = info->cpu;
> + if (HYPERVISOR_event_channel_op(EVTCHNOP_bind_vcpu, &bind_vcpu) == 0)
> + bind_evtchn_to_cpu(evtchn, info->cpu);
Isn't the hypercall is unnecessary since this is a new event channel
it's already bound to VCPU 0 and info->cpu == 0?
I think only the bind_evtchn_to_cpu() call is needed here.
If you agree I can remove the hypercall and apply this series.
> + else
> + pr_warn("Failed binding port %d to cpu %d\n",
> + evtchn, info->cpu);
> +
> + /* This will be deferred until interrupt is processed */
> + irq_set_affinity(irq, cpumask_of(info->cpu));
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] remove
We don't have any arch specific scatterlist now that parisc switched over
to the generic one.
Signed-off-by: Christoph Hellwig
---
arch/alpha/include/asm/pci.h | 2 +-
arch/arm/include/asm/dma.h| 2 +-
arch/arm/mach-footbridge/dma.c| 2 +-
arch/blackfin/include/asm/pci.h | 2 +-
arch/cris/include/asm/dma-mapping.h | 2 +-
arch/cris/include/asm/pci.h | 2 +-
arch/frv/include/asm/dma-mapping.h| 2 +-
arch/frv/include/asm/pci.h| 2 +-
arch/ia64/include/asm/pci.h | 2 +-
arch/microblaze/include/asm/pci.h | 2 +-
arch/mips/include/asm/dma-mapping.h | 2 +-
arch/mips/include/asm/pci.h | 2 +-
arch/mn10300/include/asm/pci.h| 2 +-
arch/parisc/include/asm/dma-mapping.h | 2 +-
arch/parisc/include/asm/pci.h | 2 +-
arch/powerpc/include/asm/pci.h| 2 +-
arch/powerpc/include/asm/vio.h| 2 +-
arch/sparc/kernel/iommu_common.h | 2 +-
arch/x86/include/asm/pci.h| 2 +-
arch/xtensa/include/asm/pci.h | 2 +-
drivers/mmc/host/android-goldfish.c | 2 +-
include/asm-generic/scatterlist.h | 34 --
include/linux/blkdev.h| 3 +--
include/linux/dmapool.h | 2 +-
include/linux/scatterlist.h | 39 ---
lib/swiotlb.c | 2 +-
26 files changed, 56 insertions(+), 66 deletions(-)
delete mode 100644 include/asm-generic/scatterlist.h
diff --git a/arch/alpha/include/asm/pci.h b/arch/alpha/include/asm/pci.h
index f7f680f..bf7d97d 100644
--- a/arch/alpha/include/asm/pci.h
+++ b/arch/alpha/include/asm/pci.h
@@ -5,7 +5,7 @@
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/arm/include/asm/dma.h b/arch/arm/include/asm/dma.h
index 9908443..bb4fa67 100644
--- a/arch/arm/include/asm/dma.h
+++ b/arch/arm/include/asm/dma.h
@@ -19,7 +19,7 @@
* It should not be re-used except for that purpose.
*/
#include
-#include
+#include
#include
diff --git a/arch/arm/mach-footbridge/dma.c b/arch/arm/mach-footbridge/dma.c
index e2e0df8..22536b8 100644
--- a/arch/arm/mach-footbridge/dma.c
+++ b/arch/arm/mach-footbridge/dma.c
@@ -13,9 +13,9 @@
#include
#include
#include
+#include
#include
-#include
#include
#include
diff --git a/arch/blackfin/include/asm/pci.h b/arch/blackfin/include/asm/pci.h
index c737909..14efc0d 100644
--- a/arch/blackfin/include/asm/pci.h
+++ b/arch/blackfin/include/asm/pci.h
@@ -3,7 +3,7 @@
#ifndef _ASM_BFIN_PCI_H
#define _ASM_BFIN_PCI_H
-#include
+#include
#include
#include
diff --git a/arch/cris/include/asm/dma-mapping.h
b/arch/cris/include/asm/dma-mapping.h
index 2f0f654..57f794e 100644
--- a/arch/cris/include/asm/dma-mapping.h
+++ b/arch/cris/include/asm/dma-mapping.h
@@ -5,10 +5,10 @@
#include
#include
+#include
#include
#include
-#include
#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
#define dma_free_noncoherent(d, s, v, h) dma_free_coherent(d, s, v, h)
diff --git a/arch/cris/include/asm/pci.h b/arch/cris/include/asm/pci.h
index cc2399c..c15b4b4 100644
--- a/arch/cris/include/asm/pci.h
+++ b/arch/cris/include/asm/pci.h
@@ -29,7 +29,7 @@ int pcibios_set_irq_routing(struct pci_dev *dev, int pin, int
irq);
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/frv/include/asm/dma-mapping.h
b/arch/frv/include/asm/dma-mapping.h
index 1746a2b..2840adc 100644
--- a/arch/frv/include/asm/dma-mapping.h
+++ b/arch/frv/include/asm/dma-mapping.h
@@ -2,9 +2,9 @@
#define _ASM_DMA_MAPPING_H
#include
+#include
#include
#include
-#include
#include
/*
diff --git a/arch/frv/include/asm/pci.h b/arch/frv/include/asm/pci.h
index 2035a4d..43d2246 100644
--- a/arch/frv/include/asm/pci.h
+++ b/arch/frv/include/asm/pci.h
@@ -14,7 +14,7 @@
#define _ASM_FRV_PCI_H
#include
-#include
+#include
#include
#include
diff --git a/arch/ia64/include/asm/pci.h b/arch/ia64/include/asm/pci.h
index 52af5ed..0c0e25d 100644
--- a/arch/ia64/include/asm/pci.h
+++ b/arch/ia64/include/asm/pci.h
@@ -6,9 +6,9 @@
#include
#include
#include
+#include
#include
-#include
#include
struct pci_vector_struct {
diff --git a/arch/microblaze/include/asm/pci.h
b/arch/microblaze/include/asm/pci.h
index 468aca8..81f27ae 100644
--- a/arch/microblaze/include/asm/pci.h
+++ b/arch/microblaze/include/asm/pci.h
@@ -16,8 +16,8 @@
#include
#include
#include
+#include
-#include
#include
#include
#include
diff --git a/arch/mips/include/asm/dma-mapping.h
b/arch/mips/include/asm/dma-mapping.h
index fd1b4a1..360b338 100644
--- a/arch/mips/include/asm/dma-mapping.h
+++ b/arch/mips/include/asm/dma-mapping.h
@@ -1,7 +1,7 @@
#ifndef _ASM_DMA_MAPPING_H
#define _ASM_DMA_MAPPING_H
-#include
+#include
#include
#include
#include
diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/a
Re: [PATCH 3/3] MTD: spi-nor: add flag to not use sector erase.
Hi, On Fri, May 1, 2015 at 9:05 AM, Michal Suchanek wrote: > On 1 May 2015 at 01:13, Marek Vasut wrote: >> On Thursday, April 30, 2015 at 11:13:12 PM, Michal Suchanek wrote: >>> The sector size of the flash memory is unclear from datasheet or may >>> possibly vary between chips so add a flag to always use 4k blocks. >>> >>> Currently 4k blocks are always used when possible but in the future >>> somebody might want to do some optimizations with sector erase. >>> >>> Signed-off-by: Michal Suchanek >> >> I _think_ you might be able to determine the size, no ? >> >> One way is to ask the vendor, but you can also try something like: >> 1) erase the whole SPI NOR >> 2) overwrite it with zeroes (or ones ? I think it should be all ones after >> erasing). >> 3) Erase sector 0 >> 4) Read some 128 KiB back >> 5) Observe what is the difference. >> > > I can determine it for this particular chip. However, when the vendor > datasheet says the block is 64/32K it might mean that chips with this > ID can have either block size. > > It's a value that we don't use anyway so I just mark it as unknown > here for future reference. It will be used if MTD_SPI_NOR_USE_4K_SECTORS is unset, so you should add some code to properly handle that case. Also I'd suggest switching the order of 2 and 3, so you add the flag handling first and then add support for a flash chip with this issue. Regards Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Regulator: mc34708: Add DT binding documentation
On Fri, May 01, 2015 at 12:34:21PM +0200, Stefan Wahren wrote: > a commit message would be nice and the subject should specify dt-bindings > instead of regulator subsystem. No, it shouldn't. DT bindings for a subsystem go through the subsystem and the subsystem maintainer needs to see them to read them. signature.asc Description: Digital signature
Re: [PATCH 1/1] Added RAPL support for Intel Haswell server
The below patch should be in 4.1
---
commit 645523960102fa0ac0578d070630e49ab05f06d1
Author: Jacob Pan
Date: Thu Mar 26 14:28:45 2015 -0700
perf/x86/intel/rapl: Fix energy counter measurements but supporing per
domain energy units
RAPL energy hardware unit can vary within a single CPU package, e.g.
HSW server DRAM has a fixed energy unit of 15.3 uJ (2^-16) whereas
the unit on other domains can be enumerated from power unit MSR.
There might be other variations in the future, this patch adds
per cpu model quirk to allow special handling of certain cpus.
hw_unit is also removed from per cpu data since it is not per cpu
and the sampling rate for energy counter is typically not high.
Without this patch, DRAM domain on HSW servers will be counted
4x higher than the real energy counter.
Signed-off-by: Jacob Pan
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Stephane Eranian
Cc: Andi Kleen
Cc: Arnaldo Carvalho de Melo
Cc: H. Peter Anvin
Cc: Paul Mackerras
Cc: Thomas Gleixner
Cc: Vince Weaver
Link:
http://lkml.kernel.org/r/1427405325-780-1-git-send-email-jacob.jun@linux.intel.com
Signed-off-by: Ingo Molnar
diff --git a/arch/x86/kernel/cpu/perf_event_intel_rapl.c
b/arch/x86/kernel/cpu/perf_event_intel_rapl.c
index c4bb8b8e5017..999289b94025 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_rapl.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_rapl.c
@@ -62,6 +62,14 @@
#define RAPL_IDX_PP1_NRG_STAT 3 /* gpu */
#define INTEL_RAPL_PP1 0x4 /* pseudo-encoding */
+#define NR_RAPL_DOMAINS 0x4
+static const char *rapl_domain_names[NR_RAPL_DOMAINS] __initconst = {
+ "pp0-core",
+ "package",
+ "dram",
+ "pp1-gpu",
+};
+
/* Clients have PP0, PKG */
#define RAPL_IDX_CLN (1< NR_RAPL_DOMAINS) {
+ pr_warn("invalid domain %d, failed to scale data\n", cfg);
+ return v;
+ }
/*
* scale delta to smallest unit (1/2^32)
* users must then scale back: count * 1/(1e9*2^32) to get Joules
* or use ldexp(count, -32).
* Watts = Joules/Time delta
*/
- return v << (32 - __this_cpu_read(rapl_pmu)->hw_unit);
+ return v << (32 - rapl_hw_unit[cfg - 1]);
}
static u64 rapl_event_update(struct perf_event *event)
@@ -173,7 +195,7 @@ static u64 rapl_event_update(struct perf_event *event)
delta = (new_raw_count << shift) - (prev_raw_count << shift);
delta >>= shift;
- sdelta = rapl_scale(delta);
+ sdelta = rapl_scale(delta, event->hw.config);
local64_add(sdelta, &event->count);
@@ -546,12 +568,22 @@ static void rapl_cpu_init(int cpu)
cpumask_set_cpu(cpu, &rapl_cpu_mask);
}
+static __init void rapl_hsw_server_quirk(void)
+{
+ /*
+* DRAM domain on HSW server has fixed energy unit which can be
+* different than the unit from power unit MSR.
+* "Intel Xeon Processor E5-1600 and E5-2600 v3 Product Families, V2
+* of 2. Datasheet, September 2014, Reference Number: 330784-001 "
+*/
+ rapl_hw_unit[RAPL_IDX_RAM_NRG_STAT] = 16;
+}
+
static int rapl_cpu_prepare(int cpu)
{
struct rapl_pmu *pmu = per_cpu(rapl_pmu, cpu);
int phys_id = topology_physical_package_id(cpu);
u64 ms;
- u64 msr_rapl_power_unit_bits;
if (pmu)
return 0;
@@ -559,24 +591,13 @@ static int rapl_cpu_prepare(int cpu)
if (phys_id < 0)
return -1;
- /* protect rdmsrl() to handle virtualization */
- if (rdmsrl_safe(MSR_RAPL_POWER_UNIT, &msr_rapl_power_unit_bits))
- return -1;
-
pmu = kzalloc_node(sizeof(*pmu), GFP_KERNEL, cpu_to_node(cpu));
if (!pmu)
return -1;
-
spin_lock_init(&pmu->lock);
INIT_LIST_HEAD(&pmu->active_list);
- /*
-* grab power unit as: 1/2^unit Joules
-*
-* we cache in local PMU instance
-*/
- pmu->hw_unit = (msr_rapl_power_unit_bits >> 8) & 0x1FULL;
pmu->pmu = &rapl_pmu_class;
/*
@@ -586,8 +607,8 @@ static int rapl_cpu_prepare(int cpu)
* divide interval by 2 to avoid lockstep (2 * 100)
* if hw unit is 32, then we use 2 ms 1/200/2
*/
- if (pmu->hw_unit < 32)
- ms = (1000 / (2 * 100)) * (1ULL << (32 - pmu->hw_unit - 1));
+ if (rapl_hw_unit[0] < 32)
+ ms = (1000 / (2 * 100)) * (1ULL << (32 - rapl_hw_unit[0] - 1));
else
ms = 2;
@@ -655,6 +676,20 @@ static int rapl_cpu_notifier(struct notifier_block *self,
return NOTIFY_OK;
}
+static int rapl_check_hw_unit(void)
+{
+ u64 msr_rapl_power_unit_bits;
+ int i;
+
+ /* protect rdmsrl() to handle virtualization */
+ if (rdmsrl_safe(MSR_RAPL_POWER_UNIT, &msr_rapl_power_unit_bits))
+ return -1;
+
Re: [PATCH 1/3] ASoC: Add gtm601 codec driver
On Thu, Apr 30, 2015 at 11:28:01PM +0200, Marek Belisko wrote: > select SND_SOC_WM9705 if SND_SOC_AC97_BUS > select SND_SOC_WM9712 if SND_SOC_AC97_BUS > select SND_SOC_WM9713 if SND_SOC_AC97_BUS > + select SND_SOC_GTM601 > help > +config SND_SOC_GTM601 > + tristate 'GTM601 UMTS modem audio codec' > + Keep Makefile and Kconfig sorted. > +/* > + * Note this is a simple chip with no configuration interface, sample rate is > + * determined automatically by examining the Master clock and Bit clock > ratios > + */ > +#define GTM601_RATES (SNDRV_PCM_RATE_8000) Does it or doesn't it support multiple sample rates? signature.asc Description: Digital signature
Re: [Linaro-acpi] [PATCH 2/2] ACPI / scan: Parse _CCA and setup device coherency
On Wed, Apr 29, 2015 at 05:54:02PM +0200, Arnd Bergmann wrote:
> On Wednesday 29 April 2015 14:57:10 Suthikulpanit, Suravee wrote:
> > Otherwise, it would seem inconsistent with what states in the ACPI spec:
> >
> > CCA objects are only relevant for devices that can access
> > CPU-visible memory, such as devices that are DMA capable. On ARM
> > based systems, the _CCA object must be supplied all such devices.
> > On Intel platforms, if the _CCA object is not supplied, the OSPM
> > will assume the devices are hardware cache coherent.
> >
> > From the statement above, I interpreted as if it is not present, it would
> > be non-coherent.
>
> My guess is that this section was included for Windows Phone, which runs
> on embedded SoCs that usually have noncoherent DMA in a particular way.
>
> Linux however only uses ACPI for servers, so that case does not happen.
>
> I guess it would be reasonable to add a run-time warning here if you
> try to do DMA on a device that does not have CCA set, and you should
> probably set the DMA mask to 0 in that case as well.
I agree, if _CCA isn't present, we should not allow DMA. With DT, the
default dma_ops point to non-coherent but with ACPI, we could change
the default to a dummy set of dma_ops which don't do anything (or just
return NULL). Something like below, untested:
diff --git a/arch/arm64/include/asm/dma-mapping.h
b/arch/arm64/include/asm/dma-mapping.h
index 9437e3dc5833..3fd6ef019c8f 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -31,10 +31,14 @@ extern struct dma_map_ops *dma_ops;
static inline struct dma_map_ops *__generic_dma_ops(struct device *dev)
{
- if (unlikely(!dev) || !dev->archdata.dma_ops)
+ if (!dev)
return dma_ops;
- else
+ else if (dev->archdata.dma_ops)
return dev->archdata.dma_ops;
+ else if (!acpi_disabled)
+ return dummy_dma_ops;
+ else
+ return dma_ops;
}
static inline struct dma_map_ops *get_dma_ops(struct device *dev)
@@ -48,6 +52,8 @@ static inline struct dma_map_ops *get_dma_ops(struct device
*dev)
static inline void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64
size,
struct iommu_ops *iommu, bool coherent)
{
+ if (!acpi_disabled && !dev->archdata.dma_ops)
+ dev->archdata.dma_ops = dma_ops;
dev->archdata.dma_coherent = coherent;
}
#define arch_setup_dma_ops arch_setup_dma_ops
The core code should not call arch_setup_dma_ops() if no _CCA option is
found.
> Note that there are lots of ways in which you could have noncoherent DMA:
> the default on ARM32 is that it requires uncached access or explicit
> cache flushes, but it's also possible to have an SMP system where a device
> is only coherent with some of the CPUs and requires explicit synchronization
> (not flushes) otherwise. In a multi-level cache hierarchy, there could be
> all sorts of combinations of flushes and syncs you would need to do.
>
> With DT, we handle this using SoC-specific overrides for platforms that
> are noncoherent in funny ways, see
> http://lxr.free-electrons.com/source/arch/arm/mach-mvebu/coherency.c?v=3.18#L263
> for instance.
It looks like mach-mvebu no longer needs this, according to commit
1bd4d8a6de5c (ARM: mvebu: use arm_coherent_dma_ops and re-enable hardware
I/O coherency).
Even if some hardware needs this, it's usually because it has some
broken assumptions about barriers which most likely are architecture
non-compliant. We can work around it on a case by case basis (SoC
quirks). One option would be to disable coherency altogether for that
device, even if the performance is affected (e.g. no partial coherency).
Another possibility may be to add a bus driver for that broken
interconnect which installs its own dma ops for each device attached.
> If we just disallow DMA to devices that are marked with _CCA=0
> in ACPI, we can avoid this case, or discuss it by the time someone has
> hardware
> that wants it, and then make a more informed decision about it.
I don't think we should disallow DMA to devices with _CCA == 0 (only to
those that don't have a _CCA property at all) as long as _CCA == 0 has
clear semantics like only architected cache maintenance required (and
that's what the ARMv8 ARM requires from compliant system caches).
--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/22] perf tools: introduce 'perf bpf' command to load eBPF programs.
On Thu, Apr 30, 2015 at 09:37:04PM -0700, Alexei Starovoitov wrote: > We're also working in parallel on creating a new tracing language > that together with llvm backend can be used as a single shared library > that can be called from perf or anything else. Gurgh, please also keep normal C an option. I never can remember how all these fancy arse special case languages work and its just too annoying / frustrating to have to figure out how to do simple things every time you need it to just work. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging : wlan-ng: fix memcpy with ether_addr_copy in p80211conv.c
This is a patch which fixes memcpy warning found by a checpatch.pl in
p80211conv.c
and replaces memcpy with ether_addr_copy.
Signed-off-by: Abhishek-Bist
---
drivers/staging/wlan-ng/p80211conv.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/wlan-ng/p80211conv.c
b/drivers/staging/wlan-ng/p80211conv.c
index bd69e8c..87661ba 100644
--- a/drivers/staging/wlan-ng/p80211conv.c
+++ b/drivers/staging/wlan-ng/p80211conv.c
@@ -178,21 +178,23 @@ int skb_ether_to_p80211(wlandevice_t *wlandev, u32
ethconv,
switch (wlandev->macmode) {
case WLAN_MACMODE_IBSS_STA:
- memcpy(p80211_hdr->a3.a1, &e_hdr.daddr, ETH_ALEN);
- memcpy(p80211_hdr->a3.a2, wlandev->netdev->dev_addr, ETH_ALEN);
- memcpy(p80211_hdr->a3.a3, wlandev->bssid, ETH_ALEN);
+ ether_addr_copy(p80211_hdr->a3.a1, &e_hdr.daddr, ETH_ALEN);
+ ether_addr_copy(p80211_hdr->a3.a2, wlandev->netdev->dev_addr,
+ ETH_ALEN);
+ ether_addr_copy(p80211_hdr->a3.a3, wlandev->bssid, ETH_ALEN);
break;
case WLAN_MACMODE_ESS_STA:
fc |= cpu_to_le16(WLAN_SET_FC_TODS(1));
- memcpy(p80211_hdr->a3.a1, wlandev->bssid, ETH_ALEN);
- memcpy(p80211_hdr->a3.a2, wlandev->netdev->dev_addr, ETH_ALEN);
- memcpy(p80211_hdr->a3.a3, &e_hdr.daddr, ETH_ALEN);
+ ether_addr_copy(p80211_hdr->a3.a1, wlandev->bssid, ETH_ALEN);
+ ether_addr_copy(p80211_hdr->a3.a2, wlandev->netdev->dev_addr,
+ ETH_ALEN);
+ ether_addr_copy(p80211_hdr->a3.a3, &e_hdr.daddr, ETH_ALEN);
break;
case WLAN_MACMODE_ESS_AP:
fc |= cpu_to_le16(WLAN_SET_FC_FROMDS(1));
- memcpy(p80211_hdr->a3.a1, &e_hdr.daddr, ETH_ALEN);
- memcpy(p80211_hdr->a3.a2, wlandev->bssid, ETH_ALEN);
- memcpy(p80211_hdr->a3.a3, &e_hdr.saddr, ETH_ALEN);
+ ether_addr_copy(p80211_hdr->a3.a1, &e_hdr.daddr, ETH_ALEN);
+ ether_addr_copy(p80211_hdr->a3.a2, wlandev->bssid, ETH_ALEN);
+ ether_addr_copy(p80211_hdr->a3.a3, &e_hdr.saddr, ETH_ALEN);
break;
default:
netdev_err(wlandev->netdev,
@@ -241,7 +243,7 @@ static void orinoco_spy_gather(wlandevice_t *wlandev, char
*mac,
for (i = 0; i < wlandev->spy_number; i++) {
if (!memcmp(wlandev->spy_address[i], mac, ETH_ALEN)) {
- memcpy(wlandev->spy_address[i], mac, ETH_ALEN);
+ ether_addr_copy(wlandev->spy_address[i], mac, ETH_ALEN);
wlandev->spy_stat[i].level = rxmeta->signal;
wlandev->spy_stat[i].noise = rxmeta->noise;
wlandev->spy_stat[i].qual =
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Added RAPL support for Intel Haswell server
Tested on Xeon E5 2690v3. Signed-off-by: Paul Barber --- arch/x86/kernel/cpu/perf_event_intel_rapl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/cpu/perf_event_intel_rapl.c b/arch/x86/kernel/cpu/perf_event_intel_rapl.c index c4bb8b8..5bfe767 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_rapl.c +++ b/arch/x86/kernel/cpu/perf_event_intel_rapl.c @@ -679,6 +679,7 @@ static int __init rapl_pmu_init(void) rapl_pmu_events_group.attrs = rapl_events_cln_attr; break; case 60: /* Haswell */ + case 63: /* Haswell servers */ case 69: /* Haswell-Celeron */ rapl_cntr_mask = RAPL_IDX_HSW; rapl_pmu_events_group.attrs = rapl_events_hsw_attr; -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH kernel v9 28/32] powerpc/mmu: Add userspace-to-physical addresses translation cache
On 04/29/2015 05:01 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:52PM +1000, Alexey Kardashevskiy wrote:
We are adding support for DMA memory pre-registration to be used in
conjunction with VFIO. The idea is that the userspace which is going to
run a guest may want to pre-register a user space memory region so
it all gets pinned once and never goes away. Having this done,
a hypervisor will not have to pin/unpin pages on every DMA map/unmap
request. This is going to help with multiple pinning of the same memory
and in-kernel acceleration of DMA requests.
This adds a list of memory regions to mm_context_t. Each region consists
of a header and a list of physical addresses. This adds API to:
1. register/unregister memory regions;
2. do final cleanup (which puts all pre-registered pages);
3. do userspace to physical address translation;
4. manage a mapped pages counter; when it is zero, it is safe to
unregister the region.
Multiple registration of the same region is allowed, kref is used to
track the number of registrations.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v8:
* s/mm_iommu_table_group_mem_t/struct mm_iommu_table_group_mem_t/
* fixed error fallback look (s/[i]/[j]/)
---
arch/powerpc/include/asm/mmu-hash64.h | 3 +
arch/powerpc/include/asm/mmu_context.h | 17 +++
arch/powerpc/mm/Makefile | 1 +
arch/powerpc/mm/mmu_context_hash64.c | 6 +
arch/powerpc/mm/mmu_context_hash64_iommu.c | 215 +
5 files changed, 242 insertions(+)
create mode 100644 arch/powerpc/mm/mmu_context_hash64_iommu.c
diff --git a/arch/powerpc/include/asm/mmu-hash64.h
b/arch/powerpc/include/asm/mmu-hash64.h
index 1da6a81..a82f534 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -536,6 +536,9 @@ typedef struct {
/* for 4K PTE fragment support */
void *pte_frag;
#endif
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ struct list_head iommu_group_mem_list;
+#endif
Urgh. I know I'm not one to talk, having done the hugepage crap in
there, but man mm_context_t has grown to a bloated mess from orginally
being just intended as a context ID integer :/.
Where else to put it then?... The other way to go would be some global map
of pid<->iommu_group_mem_list which needs to be available from both VFIO
and KVM.
} mm_context_t;
diff --git a/arch/powerpc/include/asm/mmu_context.h
b/arch/powerpc/include/asm/mmu_context.h
index 73382eb..d6116ca 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -16,6 +16,23 @@
*/
extern int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
extern void destroy_context(struct mm_struct *mm);
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+struct mm_iommu_table_group_mem_t;
+
+extern bool mm_iommu_preregistered(void);
+extern long mm_iommu_alloc(unsigned long ua, unsigned long entries,
+ struct mm_iommu_table_group_mem_t **pmem);
+extern struct mm_iommu_table_group_mem_t *mm_iommu_get(unsigned long ua,
+ unsigned long entries);
+extern long mm_iommu_put(struct mm_iommu_table_group_mem_t *mem);
+extern void mm_iommu_cleanup(mm_context_t *ctx);
+extern struct mm_iommu_table_group_mem_t *mm_iommu_lookup(unsigned long ua,
+ unsigned long size);
+extern long mm_iommu_ua_to_hpa(struct mm_iommu_table_group_mem_t *mem,
+ unsigned long ua, unsigned long *hpa);
+extern long mm_iommu_mapped_update(struct mm_iommu_table_group_mem_t *mem,
+ bool inc);
+#endif
extern void switch_mmu_context(struct mm_struct *prev, struct mm_struct
*next);
extern void switch_slb(struct task_struct *tsk, struct mm_struct *mm);
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index 9c8770b..e216704 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -36,3 +36,4 @@ obj-$(CONFIG_PPC_SUBPAGE_PROT)+= subpage-prot.o
obj-$(CONFIG_NOT_COHERENT_CACHE) += dma-noncoherent.o
obj-$(CONFIG_HIGHMEM) += highmem.o
obj-$(CONFIG_PPC_COPRO_BASE) += copro_fault.o
+obj-$(CONFIG_SPAPR_TCE_IOMMU) += mmu_context_hash64_iommu.o
diff --git a/arch/powerpc/mm/mmu_context_hash64.c
b/arch/powerpc/mm/mmu_context_hash64.c
index 178876ae..eb3080c 100644
--- a/arch/powerpc/mm/mmu_context_hash64.c
+++ b/arch/powerpc/mm/mmu_context_hash64.c
@@ -89,6 +89,9 @@ int init_new_context(struct task_struct *tsk, struct
mm_struct *mm)
#ifdef CONFIG_PPC_64K_PAGES
mm->context.pte_frag = NULL;
#endif
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ INIT_LIST_HEAD_RCU(&mm->context.iommu_group_mem_list);
+#endif
return 0;
}
@@ -132,6 +135,9 @@ static inline void destroy_pagetable_page(struct mm_struct
*mm)
void destroy_context(struct mm_struct *mm)
{
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ mm_iommu_cleanup(&mm->context);
+#endif
#ifdef CONFIG_PPC_ICSWX
drop_cop(mm->context.acop, mm);
diff --git a/arch/powerpc/mm/mmu_c
Re: [PATCH 1/3] ASoC: Add gtm601 codec driver
Hi Mark, On Fri, May 1, 2015 at 1:03 PM, Mark Brown wrote: > On Thu, Apr 30, 2015 at 11:28:01PM +0200, Marek Belisko wrote: > >> select SND_SOC_WM9705 if SND_SOC_AC97_BUS >> select SND_SOC_WM9712 if SND_SOC_AC97_BUS >> select SND_SOC_WM9713 if SND_SOC_AC97_BUS >> + select SND_SOC_GTM601 >> help >> +config SND_SOC_GTM601 >> + tristate 'GTM601 UMTS modem audio codec' >> + > > Keep Makefile and Kconfig sorted. Ok. > >> +/* >> + * Note this is a simple chip with no configuration interface, sample rate >> is >> + * determined automatically by examining the Master clock and Bit clock >> ratios >> + */ > >> +#define GTM601_RATES (SNDRV_PCM_RATE_8000) > > Does it or doesn't it support multiple sample rates? It support only 8kHz rate. I'll remove define and use SNDRV_PCM_RATE_8000 only in gtm601_dai struct. Thanks and BR. marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ASoC: Add gtm601 codec driver
Hi Paul,
On Fri, May 1, 2015 at 9:30 AM, Paul Bolle wrote:
> Just a nit: a license mismatch.
Right, I copy and paste license header from wm827 driver but add
MODULE_LICENSE wrong version. I'll update in next version. Thanks.
>
> On Thu, 2015-04-30 at 23:28 +0200, Marek Belisko wrote:
>> --- /dev/null
>> +++ b/sound/soc/codecs/gtm601.c
>
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>
> This states the license is GPL v2 or later.
>
>> +MODULE_LICENSE("GPL v2");
>
> And, according to include/linux/module.h, this states the license is
> (just) GPL v2. So I think either the comment at the top of this file or
> the ident used in the MODULE_LICESE() macro should change.
>
>
> Paul Bolle
>
BR,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.17.0+ files disappearing after playing old dos game on nfsroot laptop
On 05/01/2015 06:35 AM, Eric W. Biederman wrote: Hans de Bruin writes: I expect what needs to happen is to confirm that nfs directory entry revalidation is buggy, and at least for the short term re-add the nfs logic that will avoid dropping a dentry if it is a mount point, or path to a mount point, to avoid the nfs bugs. ok, I will go in waiting mode. I dropped the ball on this but it looks like someone else hit the problem and the following two commits fixed this issue: Can you confirm that things are working again? I noticed the issue was gone in one of the previous releases. I was wondering whether you changed something or not. Sorry for not notifying you. -- Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/22] perf tools: introduce 'perf bpf' command to load eBPF programs.
* Peter Zijlstra wrote: > On Thu, Apr 30, 2015 at 09:37:04PM -0700, Alexei Starovoitov wrote: > > We're also working in parallel on creating a new tracing language > > that together with llvm backend can be used as a single shared library > > that can be called from perf or anything else. > > Gurgh, please also keep normal C an option. [...] Absolutely, I thought there was agreement on that when we started merging all these eBPF patches ... It might be 'simplified C', in that it's just a subset of C, but please don't re-do something that works, especially if it's used to instrument a kernel that is written in C ... Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: char: misc.c: remove trailing whitespace
Remove trailing whitespace from several lines in drivers/char/misc.c
This was done using scripts/cleanfile
Signed-off-by: Tal Shorer
---
drivers/char/misc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/char/misc.c b/drivers/char/misc.c
index 9fd5a91..a4d3674 100644
--- a/drivers/char/misc.c
+++ b/drivers/char/misc.c
@@ -117,14 +117,14 @@ static int misc_open(struct inode * inode, struct file *
file)
const struct file_operations *new_fops = NULL;
mutex_lock(&misc_mtx);
-
+
list_for_each_entry(c, &misc_list, list) {
if (c->minor == minor) {
- new_fops = fops_get(c->fops);
+ new_fops = fops_get(c->fops);
break;
}
}
-
+
if (!new_fops) {
mutex_unlock(&misc_mtx);
request_module("char-major-%d-%d", MISC_MAJOR, minor);
@@ -167,7 +167,7 @@ static const struct file_operations misc_fops = {
/**
* misc_register - register a miscellaneous device
* @misc: device structure
- *
+ *
* Register a miscellaneous device with the kernel. If the minor
* number is set to %MISC_DYNAMIC_MINOR a minor number is assigned
* and placed in the minor field of the structure. For other cases
@@ -181,7 +181,7 @@ static const struct file_operations misc_fops = {
* A zero is returned on success and a negative errno code for
* failure.
*/
-
+
int misc_register(struct miscdevice * misc)
{
dev_t dev;
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtd: Introduce CONFIG_MTD_RESERVE_END
On Thu, Apr 30, 2015 at 7:36 PM, Ben Shelton wrote: > The reason for doing this as a Kconfig option rather than with an additional > partition is that we use the same .itb boot image (and kernel arguments) for > a series of embedded controllers that have different NAND flash sizes, and we > use the '-' command line parameter to give the root partition all the > available > space after the other partitions. Wouldn't it make more sense to make cmdlineparts to recognize if it is run on a nand flash that has on-flash BBT enabled, and then reduce the SIZE_REMAINING partition's size by the amount of nand_bbt_descr's maxblocks * erase block size? Currently your proposed solution would break if boards have differing erase block sizes, or if some have NOR flash, which makes it an option for a rather narrow use case IMHO. Regards Jonas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9] sysfs: disallow world-writable files.
On 30 April 2015 at 07:32, Rusty Russell wrote: > You're absolutely right, well spotted! The checks can be tightened. We > don't really care about execute, but logically write is "more > privileged" than read. > > Best to separate the tests; OTHER_WRITABLE <= GROUP_WRITABLE <= OWNER_WRITABLE > and OTHER_READABLE <= GROUP_READABLE <= OWNER_READABLE. > > A patch would be welcome! Thanks for the suggestion. OTHER_WRITABLE is already not permitted. So, added the checks for GROUP_WRITABLE <= OWNER_WRITABLE for write and OTHER_READABLE <= GROUP_READABLE <= OWNER_READABLE for read. I am just sending a separate patch for this. The subject line will be "[PATCH] sysfs: tightened sysfs permission checks" -- Thanks, Gobinda -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sparc: kernel: GRPCI2: Remove a useless memset
grpci2priv is allocated using kzalloc, so there is no need to memset it. Signed-off-by: Christophe Jaillet --- arch/sparc/kernel/leon_pci_grpci2.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/sparc/kernel/leon_pci_grpci2.c b/arch/sparc/kernel/leon_pci_grpci2.c index 94e392b..814fb17 100644 --- a/arch/sparc/kernel/leon_pci_grpci2.c +++ b/arch/sparc/kernel/leon_pci_grpci2.c @@ -723,7 +723,6 @@ static int grpci2_of_probe(struct platform_device *ofdev) err = -ENOMEM; goto err1; } - memset(grpci2priv, 0, sizeof(*grpci2priv)); priv->regs = regs; priv->irq = ofdev->archdata.irqs[0]; /* BASE IRQ */ priv->irq_mode = (capability & STS_IRQMODE) >> STS_IRQMODE_BIT; -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
