Re: boot tracing
* Borislav Petkov wrote: > On Fri, Jul 12, 2013 at 10:27:56AM +0200, Ingo Molnar wrote: > > Robert Richter and Boris Petkov are working on 'persistent events' > > support for perf, which will eventually allow boot time profiling - > > I'm not sure if the patches and the tooling support is ready enough > > yet for your purposes. > > Nope, not yet but we're getting there. > > > Robert, Boris, the following workflow would be pretty intuitive: > > > > - kernel developer sets boot flag: perf=boot,freq=1khz,size=16MB > > What does perf=boot mean? I assume boot tracing. In this case it would mean boot profiling - i.e. a cycles hardware-PMU event collecting into a perf trace buffer as usual. Essentially a 'perf record -a' work-alike, just one that gets activated as early as practical, and which would allow the profiling of memory initialization. Now, one extra complication here is that to be able to profile buddy allocator this persistent event would have to work before the buddy allocator is active :-/ So this sort of profiling would have to use memblock_alloc(). Just wanted to highlight this usecase, we might eventually want to support it. [ Note that this is different from boot tracing of one or more trace events - but it's a conceptually pretty close cousin. ] 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/
[tip:perf/urgent] perf tools: Revert regression in configuration of Python support
Commit-ID: a363a9da65d253fa7354ce5fd630f4f94df934cc Gitweb: http://git.kernel.org/tip/a363a9da65d253fa7354ce5fd630f4f94df934cc Author: Michael Witten AuthorDate: Wed, 17 Apr 2013 02:23:16 + Committer: Arnaldo Carvalho de Melo CommitDate: Tue, 9 Jul 2013 17:29:01 -0300 perf tools: Revert regression in configuration of Python support Among other things, the following: commit 31160d7feab786c991780d7f0ce2755a469e0e5e Date: Tue Jan 8 16:22:36 2013 -0500 perf tools: Fix GNU make v3.80 compatibility issue attempts to aid the user by tapping into an existing error message, as described in the commit message: ... Also fix an issue where _get_attempt was called with only one argument. This prevented the error message from printing the name of the variable that can be used to fix the problem. or more precisely: -$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2))) +$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2),$(1))) However, The "missing" argument was in fact missing on purpose; it's absence is a signal that the error message should be skipped, because the failure would be due to the default value, not any user-supplied value. This can be seen in how `_ge_attempt' uses `gea_err' (in the config/utilities.mak file): _ge_attempt = $(if $(get-executable),$(get-executable),$(_gea_warn)$(call _gea_err,$(2))) _gea_warn = $(warning The path '$(1)' is not executable.) _gea_err = $(if $(1),$(error Please set '$(1)' appropriately)) That is, because the argument is no longer missing, the value `$(1)' (associated with `_gea_err') always evaluates to true, thus always triggering the error condition that is meant to be reserved for only the case when a user explicitly supplies an invalid value. Concretely, the result is a regression in the Makefile's configuration of python support; rather than gracefully disable support when the relevant executables cannot be found according to default values, the build process halts in error as though the user explicitly supplied the values. This new commit simply reverts the offending one-line change. Reported-by: Pekka Enberg Link: http://lkml.kernel.org/r/caojsxlhv17ys3m7p5q25imkuxqw6le_vabxh1n3tt7mv6ho...@mail.gmail.com Signed-off-by: Michael Witten --- tools/perf/config/utilities.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/config/utilities.mak b/tools/perf/config/utilities.mak index faffb52..94d2d4f 100644 --- a/tools/perf/config/utilities.mak +++ b/tools/perf/config/utilities.mak @@ -173,7 +173,7 @@ _ge-abspath = $(if $(is-executable),$(1)) # Usage: absolute-executable-path-or-empty = $(call get-executable-or-default,variable,default) # define get-executable-or-default -$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2),$(1))) +$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2))) endef _ge_attempt = $(if $(get-executable),$(get-executable),$(_gea_warn)$(call _gea_err,$(2))) _gea_warn = $(warning The path '$(1)' is not executable.) -- 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 script: Fix broken include in Context.xs
Commit-ID: 750ade7e82709c2835cb221a7b6a9ef0a6a9c0ac Gitweb: http://git.kernel.org/tip/750ade7e82709c2835cb221a7b6a9ef0a6a9c0ac Author: Ramkumar Ramachandra AuthorDate: Tue, 9 Jul 2013 15:30:30 +0530 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 10 Jul 2013 13:47:00 -0300 perf script: Fix broken include in Context.xs 765532c8 (perf script: Finish the rename from trace to script, 2010-12-23) made a mistake during find-and-replace replacing "../../../util/trace-event.h" with "../../../util/script-event.h", a non-existent file. Fix this include. Signed-off-by: Ramkumar Ramachandra Cc: Namhyung Kim Link: http://lkml.kernel.org/r/1373364033-7918-3-git-send-email-artag...@gmail.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/scripts/perl/Perf-Trace-Util/Context.xs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/scripts/perl/Perf-Trace-Util/Context.xs b/tools/perf/scripts/perl/Perf-Trace-Util/Context.xs index c1e2ed1..8c7ea42 100644 --- a/tools/perf/scripts/perl/Perf-Trace-Util/Context.xs +++ b/tools/perf/scripts/perl/Perf-Trace-Util/Context.xs @@ -23,7 +23,7 @@ #include "perl.h" #include "XSUB.h" #include "../../../perf.h" -#include "../../../util/script-event.h" +#include "../../../util/trace-event.h" MODULE = Perf::Trace::Context PACKAGE = Perf::Trace::Context PROTOTYPES: ENABLE -- 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: [PATCHv2 0/5] perf tools: Remove event types data
Hi Jiri, On Thu, 11 Jul 2013 17:28:28 +0200, Jiri Olsa wrote: > hi, > following up on the 'perf timechart' FIXME note and changing > its tracepoint match not to use event types data. > > Original RFC sent here: > http://marc.info/?l=linux-kernel=137344263513417=2 > > v2 changes: > - using tracepoints haler callbacks to get power data > in timechart command (patch 2) > - separating enum removal of 'enum trace_flag_type' > (patch 1) > > Again, timechart (and perf.data) tests look ok, but would > appreciate another tester ;-). > > It's reachable here: > git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git > perf/et2 For the whole patchset: Acked-by: Namhyung Kim Thanks, Namhyung -- 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 symbols: Fix vdso list searching
Commit-ID: f9ceffb605be7b3b3b2a6e6d14dd0d7a97eae580
Gitweb: http://git.kernel.org/tip/f9ceffb605be7b3b3b2a6e6d14dd0d7a97eae580
Author: Waiman Long
AuthorDate: Thu, 9 May 2013 10:42:48 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 8 Jul 2013 17:59:07 -0300
perf symbols: Fix vdso list searching
When "perf record" was used on a large machine with a lot of CPUs, the
perf post-processing time (the time after the workload was done until
the perf command itself exited) could take a lot of minutes and even
hours depending on how large the resulting perf.data file was.
While running AIM7 1500-user high_systime workload on a 80-core x86-64
system with a 3.9 kernel (with only the -s -a options used), the
workload itself took about 2 minutes to run and the perf.data file had a
size of 1108.746 MB. However, the post-processing step took more than 10
minutes.
With a gprof-profiled perf binary, the time spent by perf was as
follows:
% cumulative self self total
time seconds secondscalls s/call s/call name
96.90822.10 822.10 192156 0.00 0.00 dsos__find
0.81828.96 6.86 172089958 0.00 0.00 rb_next
0.41832.44 3.48 48539289 0.00 0.00 rb_erase
So 97% (822 seconds) of the time was spent in a single dsos_find()
function. After analyzing the call-graph data below:
---
0.00 822.12 192156/192156 map__new [6]
[7] 96.90.00 822.12 192156 vdso__dso_findnew [7]
822.100.00 192156/192156 dsos__find [8]
0.010.00 192156/192156 dsos__add [62]
0.010.00 192156/192366 dso__new [61]
0.000.00 1/45282525 memdup [31]
0.000.00 192156/192230 dso__set_long_name [91]
---
822.100.00 192156/192156 vdso__dso_findnew [7]
[8] 96.9 822.100.00 192156 dsos__find [8]
---
It was found that the vdso__dso_findnew() function failed to locate
VDSO__MAP_NAME ("[vdso]") in the dso list and have to insert a new
entry at the end for 192156 times. This problem is due to the fact that
there are 2 types of name in the dso entry - short name and long name.
The initial dso__new() adds "[vdso]" to both the short and long names.
After that, vdso__dso_findnew() modifies the long name to something
like /tmp/perf-vdso.so-NoXkDj. The dsos__find() function only compares
the long name. As a result, the same vdso entry is duplicated many
time in the dso list. This bug increases memory consumption as well
as slows the symbol processing time to a crawl.
To resolve this problem, the dsos__find() function interface was
modified to enable searching either the long name or the short
name. The vdso__dso_findnew() will now search only the short name
while the other call sites search for the long name as before.
With this change, the cpu time of perf was reduced from 848.38s to
15.77s and dsos__find() only accounted for 0.06% of the total time.
0.06 15.73 0.01 192151 0.00 0.00 dsos__find
Signed-off-by: Waiman Long
Acked-by: Ingo Molnar
Cc: "Chandramouleeswaran, Aswin"
Cc: "Norton, Scott J"
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1368110568-64714-1-git-send-email-waiman.l...@hp.com
[ replaced TRUE/FALSE with stdbool.h equivalents, fixing builds where
those macros are not present (NO_LIBPYTHON=1 NO_LIBPERL=1), fix from Jiri
Olsa ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/dso.c | 10 --
tools/perf/util/dso.h | 3 ++-
tools/perf/util/vdso.c | 2 +-
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 6f7d5a9..c4374f0 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -513,10 +513,16 @@ void dsos__add(struct list_head *head, struct dso *dso)
list_add_tail(>node, head);
}
-struct dso *dsos__find(struct list_head *head, const char *name)
+struct dso *dsos__find(struct list_head *head, const char *name, bool
cmp_short)
{
struct dso *pos;
+ if (cmp_short) {
+ list_for_each_entry(pos, head, node)
+ if (strcmp(pos->short_name, name) == 0)
+ return pos;
+ return NULL;
+ }
list_for_each_entry(pos, head, node)
if (strcmp(pos->long_name, name) == 0)
return pos;
@@ -525,7 +531,7 @@ struct dso *dsos__find(struct list_head *head, const char
*name)
struct dso *__dsos__findnew(struct list_head *head, const char *name)
{
- struct dso *dso = dsos__find(head, name);
+ struct dso *dso = dsos__find(head, name, false);
[tip:perf/urgent] perf tools: fix a typo of a Power7 event name
Commit-ID: 7e40c92019cef784fffbdfc51c6e731e7ee6ba10
Gitweb: http://git.kernel.org/tip/7e40c92019cef784fffbdfc51c6e731e7ee6ba10
Author: Runzhen Wang
AuthorDate: Fri, 28 Jun 2013 16:14:56 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 8 Jul 2013 17:40:05 -0300
perf tools: fix a typo of a Power7 event name
In the Power7 PMU guide:
https://www.power.org/documentation/commonly-used-metrics-for-performance-analysis/
PM_BRU_MPRED is referred to as PM_BR_MPRED.
It fixed the typo by changing the name of the event in kernel and
documentation accordingly.
This patch changes the ABI, there are some reasons I think it's ok:
- It is relatively new interface, specific to the Power7 platform.
- No tools that we know of actually use this interface at this point
(none are listed near the interface).
- Users of this interface (eg oprofile users migrating to perf)
would be more used to the "PM_BR_MPRED" rather than "PM_BRU_MPRED".
- These are in the ABI/testing at this point rather than ABI/stable,
so hoping we have some wiggle room.
Signed-off-by: Runzhen Wang
Acked-by: Michael Ellerman
Cc: icyco...@gmail.com
Cc: linuxppc-...@lists.ozlabs.org
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: Runzhen Wang
Cc: Sukadev Bhattiprolu
Cc: Xiao Guangrong
Link:
http://lkml.kernel.org/r/1372407297-6996-2-git-send-email-runz...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
.../ABI/testing/sysfs-bus-event_source-devices-events| 2 +-
arch/powerpc/perf/power7-pmu.c | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
index 8b25ffb..3c1cc24 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
@@ -29,7 +29,7 @@ Description: Generic performance monitoring events
What: /sys/devices/cpu/events/PM_1PLUS_PPC_CMPL
/sys/devices/cpu/events/PM_BRU_FIN
- /sys/devices/cpu/events/PM_BRU_MPRED
+ /sys/devices/cpu/events/PM_BR_MPRED
/sys/devices/cpu/events/PM_CMPLU_STALL
/sys/devices/cpu/events/PM_CMPLU_STALL_BRU
/sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 13c3f0e..d1821b8 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -60,7 +60,7 @@
#definePME_PM_LD_REF_L10xc880
#definePME_PM_LD_MISS_L1 0x400f0
#definePME_PM_BRU_FIN 0x10068
-#definePME_PM_BRU_MPRED0x400f6
+#definePME_PM_BR_MPRED 0x400f6
#define PME_PM_CMPLU_STALL_FXU 0x20014
#define PME_PM_CMPLU_STALL_DIV 0x40014
@@ -349,7 +349,7 @@ static int power7_generic_events[] = {
[PERF_COUNT_HW_CACHE_REFERENCES] = PME_PM_LD_REF_L1,
[PERF_COUNT_HW_CACHE_MISSES] = PME_PM_LD_MISS_L1,
[PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = PME_PM_BRU_FIN,
- [PERF_COUNT_HW_BRANCH_MISSES] = PME_PM_BRU_MPRED,
+ [PERF_COUNT_HW_BRANCH_MISSES] = PME_PM_BR_MPRED,
};
#define C(x) PERF_COUNT_HW_CACHE_##x
@@ -405,7 +405,7 @@ GENERIC_EVENT_ATTR(instructions,INST_CMPL);
GENERIC_EVENT_ATTR(cache-references, LD_REF_L1);
GENERIC_EVENT_ATTR(cache-misses, LD_MISS_L1);
GENERIC_EVENT_ATTR(branch-instructions,BRU_FIN);
-GENERIC_EVENT_ATTR(branch-misses, BRU_MPRED);
+GENERIC_EVENT_ATTR(branch-misses, BR_MPRED);
POWER_EVENT_ATTR(CYC, CYC);
POWER_EVENT_ATTR(GCT_NOSLOT_CYC, GCT_NOSLOT_CYC);
@@ -414,7 +414,7 @@ POWER_EVENT_ATTR(INST_CMPL, INST_CMPL);
POWER_EVENT_ATTR(LD_REF_L1,LD_REF_L1);
POWER_EVENT_ATTR(LD_MISS_L1, LD_MISS_L1);
POWER_EVENT_ATTR(BRU_FIN, BRU_FIN)
-POWER_EVENT_ATTR(BRU_MPRED,BRU_MPRED);
+POWER_EVENT_ATTR(BR_MPRED, BR_MPRED);
POWER_EVENT_ATTR(CMPLU_STALL_FXU, CMPLU_STALL_FXU);
POWER_EVENT_ATTR(CMPLU_STALL_DIV, CMPLU_STALL_DIV);
@@ -449,7 +449,7 @@ static struct attribute *power7_events_attr[] = {
GENERIC_EVENT_PTR(LD_REF_L1),
GENERIC_EVENT_PTR(LD_MISS_L1),
GENERIC_EVENT_PTR(BRU_FIN),
- GENERIC_EVENT_PTR(BRU_MPRED),
+ GENERIC_EVENT_PTR(BR_MPRED),
POWER_EVENT_PTR(CYC),
POWER_EVENT_PTR(GCT_NOSLOT_CYC),
@@ -458,7 +458,7 @@ static struct attribute *power7_events_attr[] = {
POWER_EVENT_PTR(LD_REF_L1),
POWER_EVENT_PTR(LD_MISS_L1),
POWER_EVENT_PTR(BRU_FIN),
-
[tip:perf/urgent] perf tools: Fix parse_events_terms() segfault on error path
Commit-ID: b2c34fde048f3c85ef0716a8cdabbe46ac67d1e6 Gitweb: http://git.kernel.org/tip/b2c34fde048f3c85ef0716a8cdabbe46ac67d1e6 Author: Adrian Hunter AuthorDate: Thu, 4 Jul 2013 16:20:23 +0300 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 8 Jul 2013 17:45:41 -0300 perf tools: Fix parse_events_terms() segfault on error path On the error path, 'data.terms' may not have been initialised. Signed-off-by: Adrian Hunter Acked-by: Jiri Olsa Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1372944040-32690-5-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/parse-events.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c index 6c8bb0f..d8dcb8d 100644 --- a/tools/perf/util/parse-events.c +++ b/tools/perf/util/parse-events.c @@ -860,7 +860,8 @@ int parse_events_terms(struct list_head *terms, const char *str) return 0; } - parse_events__free_terms(data.terms); + if (data.terms) + parse_events__free_terms(data.terms); return ret; } -- 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 tools: Fix perf version generation
Commit-ID: a4147f0f91386540316e468f3a3674a498dada5f Gitweb: http://git.kernel.org/tip/a4147f0f91386540316e468f3a3674a498dada5f Author: Robert Richter AuthorDate: Wed, 8 May 2013 11:43:34 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 8 Jul 2013 18:09:52 -0300 perf tools: Fix perf version generation The tag of the perf version is wrongly determined, always the latest tag is taken regardless of the HEAD commit: $ perf --version perf version 3.9.rc8.gd7f5d3 $ git describe d7f5d3 v3.9-rc7-154-gd7f5d33 $ head -n 4 Makefile VERSION = 3 PATCHLEVEL = 9 SUBLEVEL = 0 EXTRAVERSION = -rc7 In other cases no tag might be found. This patch fixes this. This new implementation handles also the case if there are no tags at all found in the git repo but there is a commit id. Signed-off-by: Robert Richter Link: http://lkml.kernel.org/r/1368006214-12912-1-git-send-email-r...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/PERF-VERSION-GEN | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/tools/perf/util/PERF-VERSION-GEN b/tools/perf/util/PERF-VERSION-GEN index 055fef3..15a77b7 100755 --- a/tools/perf/util/PERF-VERSION-GEN +++ b/tools/perf/util/PERF-VERSION-GEN @@ -13,13 +13,22 @@ LF=' # First check if there is a .git to get the version from git describe # otherwise try to get the version from the kernel Makefile # -if test -d ../../.git -o -f ../../.git && - VN=$(git tag 2>/dev/null | tail -1 | grep -E "v[0-9].[0-9]*") +CID= +TAG= +if test -d ../../.git -o -f ../../.git then - VN=$(echo $VN"-g"$(git log -1 --abbrev=4 --pretty=format:"%h" HEAD)) - VN=$(echo "$VN" | sed -e 's/-/./g'); -else - VN=$(MAKEFLAGS= make -sC ../.. kernelversion) + TAG=$(git describe --abbrev=0 --match "v[0-9].[0-9]*" 2>/dev/null ) + CID=$(git log -1 --abbrev=4 --pretty=format:"%h" 2>/dev/null) && CID="-g$CID" +fi +if test -z "$TAG" +then + TAG=$(MAKEFLAGS= make -sC ../.. kernelversion) +fi +VN="$TAG$CID" +if test -n "$CID" +then + # format version string, strip trailing zero of sublevel: + VN=$(echo "$VN" | sed -e 's/-/./g;s/\([0-9]*[.][0-9]*\)[.]0/\1/') fi VN=$(expr "$VN" : v*'\(.*\)') -- 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 tools: Fix new_term() missing free on error path
Commit-ID: 4be8be6b430611def94bcd583b7b302d197a9520 Gitweb: http://git.kernel.org/tip/4be8be6b430611def94bcd583b7b302d197a9520 Author: Adrian Hunter AuthorDate: Thu, 4 Jul 2013 16:20:24 +0300 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 8 Jul 2013 17:45:56 -0300 perf tools: Fix new_term() missing free on error path On the error path, newly allocated 'term' must be freed. Signed-off-by: Adrian Hunter Acked-by: Jiri Olsa Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1372944040-32690-6-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/parse-events.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c index d8dcb8d..995fc25 100644 --- a/tools/perf/util/parse-events.c +++ b/tools/perf/util/parse-events.c @@ -1184,6 +1184,7 @@ static int new_term(struct parse_events_term **_term, int type_val, term->val.str = str; break; default: + free(term); return -EINVAL; } -- 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 evsel: Fix count parameter to read call in event_format__new
Commit-ID: 7cab84e8975cfb8a59ce3e79ce75e5eedd384484 Gitweb: http://git.kernel.org/tip/7cab84e8975cfb8a59ce3e79ce75e5eedd384484 Author: David Ahern AuthorDate: Tue, 2 Jul 2013 13:27:20 -0600 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 8 Jul 2013 17:40:39 -0300 perf evsel: Fix count parameter to read call in event_format__new per realloc above the length of the buffer is alloc_size, not BUFSIZ. Adjust length per size as done for buf start. Addresses some valgrind complaints: ==1870== Syscall param read(buf) points to unaddressable byte(s) ==1870==at 0x4E3F610: __read_nocancel (in /lib64/libpthread-2.14.90.so) ==1870==by 0x44AEE1: event_format__new (unistd.h:45) ==1870==by 0x44B025: perf_evsel__newtp (evsel.c:158) ==1870==by 0x451919: add_tracepoint_event (parse-events.c:395) ==1870==by 0x479815: parse_events_parse (parse-events.y:292) ==1870==by 0x45463A: parse_events_option (parse-events.c:861) ==1870==by 0x44FEE4: get_value (parse-options.c:113) ==1870==by 0x450767: parse_options_step (parse-options.c:192) ==1870==by 0x450C40: parse_options (parse-options.c:422) ==1870==by 0x42735F: cmd_record (builtin-record.c:918) ==1870==by 0x419D72: run_builtin (perf.c:319) ==1870==by 0x4195F2: main (perf.c:376) ==1870== Address 0xcffebf0 is 0 bytes after a block of size 8,192 alloc'd ==1870==at 0x4C2A62F: malloc (vg_replace_malloc.c:270) ==1870==by 0x4C2A7A3: realloc (vg_replace_malloc.c:662) ==1870==by 0x44AF07: event_format__new (evsel.c:121) ==1870==by 0x44B025: perf_evsel__newtp (evsel.c:158) ==1870==by 0x451919: add_tracepoint_event (parse-events.c:395) ==1870==by 0x479815: parse_events_parse (parse-events.y:292) ==1870==by 0x45463A: parse_events_option (parse-events.c:861) ==1870==by 0x44FEE4: get_value (parse-options.c:113) ==1870==by 0x450767: parse_options_step (parse-options.c:192) ==1870==by 0x450C40: parse_options (parse-options.c:422) ==1870==by 0x42735F: cmd_record (builtin-record.c:918) ==1870==by 0x419D72: run_builtin (perf.c:319) Signed-off-by: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1372793245-4136-2-git-send-email-dsah...@gmail.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/evsel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 63b6f8c..df99ebe 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -124,7 +124,7 @@ struct event_format *event_format__new(const char *sys, const char *name) bf = nbf; } - n = read(fd, bf + size, BUFSIZ); + n = read(fd, bf + size, alloc_size - size); if (n < 0) goto out_free_bf; size += n; -- 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 tools: Fix -x/ --exclude-other option for report command
Commit-ID: 0276c22a3f22b7f6696fa07b0a77635726b2c0fd
Gitweb: http://git.kernel.org/tip/0276c22a3f22b7f6696fa07b0a77635726b2c0fd
Author: Jiri Olsa
AuthorDate: Mon, 10 Jun 2013 08:21:21 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 8 Jul 2013 17:38:53 -0300
perf tools: Fix -x/--exclude-other option for report command
Currently we have symbol_conf.exclude_other being set as true every time
so the -x/--exclude-other has nothing to do.
Also we have no way to see the data with symbol_conf.exclude_other being
false which is useful sometimes.
Fixing it by making symbol_conf.exclude_other false by default.
1) Example without -x option:
$ perf report -i perf.data.delete -p perf_session__delete -s parent
+ 99.91% [other]
+ 0.08% perf_session__delete
+ 0.00% perf_session__delete_dead_threads
+ 0.00% perf_session__delete_threads
2) Example with -x option:
$ ./perf report -i perf.data.delete -p perf_session__delete -s parent -x
+ 96.22% perf_session__delete
+ 1.89% perf_session__delete_dead_threads
+ 1.89% perf_session__delete_threads
In Example 1) we get the sorted out data together with the rest
"[other]". This could help us estimate how much time we spent in the
sorted data.
In Example 2) the total is just the sorted data.
Signed-off-by: Jiri Olsa
Cc: Andi Kleen
Cc: Corey Ashford
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/n/tip-sg8fvu0fyqohf9ur9l38l...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-diff.c | 1 -
tools/perf/builtin-report.c | 3 +--
tools/perf/builtin-top.c| 2 --
tools/perf/util/symbol.c| 1 -
4 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index da8f8eb..0aac5f3 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -607,7 +607,6 @@ int cmd_diff(int argc, const char **argv, const char
*prefix __maybe_unused)
input_new = "perf.data.guest";
}
- symbol_conf.exclude_other = false;
if (symbol__init() < 0)
return -1;
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index ca98d34..3662047 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -939,8 +939,7 @@ repeat:
*/
if (!strstr(sort_order, "parent"))
sort_parent.elide = 1;
- } else
- symbol_conf.exclude_other = false;
+ }
if (argc) {
/*
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index f036af9..e06c4f8 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1130,8 +1130,6 @@ int cmd_top(int argc, const char **argv, const char
*prefix __maybe_unused)
if (top.evlist == NULL)
return -ENOMEM;
- symbol_conf.exclude_other = false;
-
argc = parse_options(argc, argv, options, top_usage, 0);
if (argc)
usage_with_options(top_usage, options);
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 8cf3b54..d5528e1 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -32,7 +32,6 @@ int vmlinux_path__nr_entries;
char **vmlinux_path;
struct symbol_conf symbol_conf = {
- .exclude_other= true,
.use_modules = true,
.try_vmlinux_path = true,
.annotate_src = 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 stat: Avoid sending SIGTERM to random processes
Commit-ID: d07f0b120642f442d81a61f68a9325fb7717004f
Gitweb: http://git.kernel.org/tip/d07f0b120642f442d81a61f68a9325fb7717004f
Author: Stephane Eranian
AuthorDate: Tue, 4 Jun 2013 17:44:26 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 8 Jul 2013 17:36:33 -0300
perf stat: Avoid sending SIGTERM to random processes
This patch fixes a problem with perf stat whereby on termination it may
send a SIGTERM signal to random processes on systems with high PID
recycling. I got some actual bug reports on this.
There is race between the SIGCHLD and sig_atexit() handlers. This patch
addresses this problem by clearing child_pid in the SIGCHLD handler.
Signed-off-by: Stephane Eranian
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20130604154426.GA2928@quad
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 7e910ba..95768af 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -87,7 +87,7 @@ static intrun_count
= 1;
static boolno_inherit = false;
static boolscale = true;
static enum aggr_mode aggr_mode = AGGR_GLOBAL;
-static pid_t child_pid = -1;
+static volatile pid_t child_pid = -1;
static boolnull_run= false;
static int detailed_run= 0;
static boolbig_num = true;
@@ -1148,13 +1148,34 @@ static void skip_signal(int signo)
done = 1;
signr = signo;
+ /*
+* render child_pid harmless
+* won't send SIGTERM to a random
+* process in case of race condition
+* and fast PID recycling
+*/
+ child_pid = -1;
}
static void sig_atexit(void)
{
+ sigset_t set, oset;
+
+ /*
+* avoid race condition with SIGCHLD handler
+* in skip_signal() which is modifying child_pid
+* goal is to avoid send SIGTERM to a random
+* process
+*/
+ sigemptyset();
+ sigaddset(, SIGCHLD);
+ sigprocmask(SIG_BLOCK, , );
+
if (child_pid != -1)
kill(child_pid, SIGTERM);
+ sigprocmask(SIG_SETMASK, , NULL);
+
if (signr == -1)
return;
--
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 record: Remove -f/--force option
Commit-ID: 4a4d371a4dfbd3b84a7eab8d535d4c7c3647b09e
Gitweb: http://git.kernel.org/tip/4a4d371a4dfbd3b84a7eab8d535d4c7c3647b09e
Author: Jiri Olsa
AuthorDate: Wed, 5 Jun 2013 13:37:21 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 8 Jul 2013 17:37:25 -0300
perf record: Remove -f/--force option
It no longer have any affect on the processing and is marked as obsolete
anyway.
Signed-off-by: Jiri Olsa
Cc: Andi Kleen
Cc: Corey Ashford
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/n/tip-tvwyspiqr4getzfib2lw0...@git.kernel.org
Link:
http://lkml.kernel.org/r/1372307120-737-1-git-send-email-namhy...@kernel.org
[ combined patch removing the -f usage in various sub-commands, such as 'perf
sched', etc, by Namhyung Kim ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/examples.txt| 4 ++--
tools/perf/Documentation/perf-record.txt | 4
tools/perf/builtin-kmem.c| 2 +-
tools/perf/builtin-lock.c| 2 +-
tools/perf/builtin-record.c | 3 ---
tools/perf/builtin-sched.c | 1 -
tools/perf/builtin-timechart.c | 4 ++--
7 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/tools/perf/Documentation/examples.txt
b/tools/perf/Documentation/examples.txt
index 77f9527..a4e3921 100644
--- a/tools/perf/Documentation/examples.txt
+++ b/tools/perf/Documentation/examples.txt
@@ -66,7 +66,7 @@ Furthermore, these tracepoints can be used to sample the
workload as
well. For example the page allocations done by a 'git gc' can be
captured the following way:
- titan:~/git> perf record -f -e kmem:mm_page_alloc -c 1 ./git gc
+ titan:~/git> perf record -e kmem:mm_page_alloc -c 1 ./git gc
Counting objects: 1148, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (450/450), done.
@@ -120,7 +120,7 @@ Furthermore, call-graph sampling can be done too, of page
allocations - to see precisely what kind of page allocations there
are:
- titan:~/git> perf record -f -g -e kmem:mm_page_alloc -c 1 ./git gc
+ titan:~/git> perf record -g -e kmem:mm_page_alloc -c 1 ./git gc
Counting objects: 1148, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (450/450), done.
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 7e32580..e297b74 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -70,10 +70,6 @@ OPTIONS
--no-delay::
Collect data without buffering.
--f::
---force::
- Overwrite existing data file. (deprecated)
-
-c::
--count=::
Event period to sample.
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 46878da..0259502 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -708,7 +708,7 @@ static int parse_line_opt(const struct option *opt
__maybe_unused,
static int __cmd_record(int argc, const char **argv)
{
const char * const record_args[] = {
- "record", "-a", "-R", "-f", "-c", "1",
+ "record", "-a", "-R", "-c", "1",
"-e", "kmem:kmalloc",
"-e", "kmem:kmalloc_node",
"-e", "kmem:kfree",
diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
index 4258300..76543a4 100644
--- a/tools/perf/builtin-lock.c
+++ b/tools/perf/builtin-lock.c
@@ -878,7 +878,7 @@ static int __cmd_report(void)
static int __cmd_record(int argc, const char **argv)
{
const char *record_args[] = {
- "record", "-R", "-f", "-m", "1024", "-c", "1",
+ "record", "-R", "-m", "1024", "-c", "1",
};
unsigned int rec_argc, i, j;
const char **rec_argv;
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 2990570..ecca62e 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -74,7 +74,6 @@ struct perf_record {
int realtime_prio;
boolno_buildid;
boolno_buildid_cache;
- boolforce;
longsamples;
off_t post_processing_offset;
};
@@ -856,8 +855,6 @@ const struct option record_options[] = {
"system-wide collection from all CPUs"),
OPT_STRING('C', "cpu", _list, "cpu",
"list of cpus to monitor"),
- OPT_BOOLEAN('f', "force", ,
- "overwrite existing data file (deprecated)"),
OPT_U64('c', "count", _interval, "event period to
sample"),
OPT_STRING('o', "output", _name, "file",
"output file name"),
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 2da2a6c..fed9ae4 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -1632,7 +1632,6 @@ static int
[tip:perf/urgent] perf tools: Include termios.h explicitly
Commit-ID: 756bbc84e30b57ca1010b550ea30594fd0b0494f Gitweb: http://git.kernel.org/tip/756bbc84e30b57ca1010b550ea30594fd0b0494f Author: Joonsoo Kim AuthorDate: Wed, 19 Jun 2013 10:02:30 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 8 Jul 2013 17:36:05 -0300 perf tools: Include termios.h explicitly Building perf for android fails because it can't find the definition of struct winsize. This definition is in termios.h, so I add this header to util.h to solve the problem. It is missed by commit '2c803e52' which moves get_term_dimensions() from builtin-top.c to util.c, but missed to move termios.h header. Signed-off-by: Joonsoo Kim Acked-by: David Ahern Cc: David Ahern Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1371603750-15053-3-git-send-email-iamjoonsoo@lge.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/util.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h index 7a484c9..2732fad 100644 --- a/tools/perf/util/util.h +++ b/tools/perf/util/util.h @@ -72,6 +72,7 @@ #include "types.h" #include #include +#include extern const char *graph_line; extern const char *graph_dotted_line; @@ -274,6 +275,5 @@ void dump_stack(void); extern unsigned int page_size; -struct winsize; void get_term_dimensions(struct winsize *ws); #endif /* GIT_COMPAT_UTIL_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/
[tip:perf/urgent] perf bench: Fix memory allocation fail check in mem{set,cpy} workloads
Commit-ID: 13966721a11f4a2ba8038191e48083b5f31822bb
Gitweb: http://git.kernel.org/tip/13966721a11f4a2ba8038191e48083b5f31822bb
Author: Kirill A. Shutemov
AuthorDate: Thu, 6 Jun 2013 14:35:03 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 8 Jul 2013 17:35:40 -0300
perf bench: Fix memory allocation fail check in mem{set,cpy} workloads
Addresses of allocated memory areas saved to '*src' and '*dst', so we
need to check them for NULL, not 'src' and 'dst'.
Signed-off-by: Kirill A. Shutemov
Acked-by: Hitoshi Mitake
Cc: Hitoshi Mitake
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1370518503-4230-1-git-send-email-kirill.shute...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/bench/mem-memcpy.c | 4 ++--
tools/perf/bench/mem-memset.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/bench/mem-memcpy.c b/tools/perf/bench/mem-memcpy.c
index 93c83e3..25fd3f1 100644
--- a/tools/perf/bench/mem-memcpy.c
+++ b/tools/perf/bench/mem-memcpy.c
@@ -111,11 +111,11 @@ static double timeval2double(struct timeval *ts)
static void alloc_mem(void **dst, void **src, size_t length)
{
*dst = zalloc(length);
- if (!dst)
+ if (!*dst)
die("memory allocation failed - maybe length is too large?\n");
*src = zalloc(length);
- if (!src)
+ if (!*src)
die("memory allocation failed - maybe length is too large?\n");
}
diff --git a/tools/perf/bench/mem-memset.c b/tools/perf/bench/mem-memset.c
index c6e4bc5..4a2f120 100644
--- a/tools/perf/bench/mem-memset.c
+++ b/tools/perf/bench/mem-memset.c
@@ -111,7 +111,7 @@ static double timeval2double(struct timeval *ts)
static void alloc_mem(void **dst, size_t length)
{
*dst = zalloc(length);
- if (!dst)
+ if (!*dst)
die("memory allocation failed - maybe length is too large?\n");
}
--
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 tools: Fix build errors with O and DESTDIR make vars set
Commit-ID: 107de3724eff5a6fa6474a4d2aa5460b63749ebf Gitweb: http://git.kernel.org/tip/107de3724eff5a6fa6474a4d2aa5460b63749ebf Author: Robert Richter AuthorDate: Tue, 11 Jun 2013 17:22:38 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 8 Jul 2013 17:34:00 -0300 perf tools: Fix build errors with O and DESTDIR make vars set Fixing build errors with O and DESTDIR make vars set: $ make prefix=/usr/local O=$builddir DESTDIR=$destdir -C tools/ perf ... make[1]: Entering directory `.../.source/perf/tools/perf' CC .../.build/perf/perf/util/parse-events.o util/parse-events.c:14:32: fatal error: parse-events-bison.h: No such file or directory compilation terminated. make[1]: *** [.../.build/perf/perf/util/parse-events.o] Error 1 ... and: LINK /.../.build/perf/perf/perf gcc: error: /.../.build/perf/perf//.../.source/perf/tools/lib/lk/liblk.a: No such file or directory Signed-off-by: Robert Richter Signed-off-by: Robert Richter Cc: Ingo Molnar Cc: Jiri Olsa Cc: Robert Richter Link: http://lkml.kernel.org/r/1370964158-4135-1-git-send-email-r...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Makefile| 5 ++--- tools/perf/config/Makefile | 2 +- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/tools/perf/Makefile b/tools/perf/Makefile index 203cb0e..641fccd 100644 --- a/tools/perf/Makefile +++ b/tools/perf/Makefile @@ -121,17 +121,16 @@ SCRIPT_SH += perf-archive.sh grep-libs = $(filter -l%,$(1)) strip-libs = $(filter-out -l%,$(1)) -LK_PATH=$(LK_DIR) - ifneq ($(OUTPUT),) TE_PATH=$(OUTPUT) ifneq ($(subdir),) - LK_PATH=$(OUTPUT)$(LK_DIR) + LK_PATH=$(objtree)/lib/lk/ else LK_PATH=$(OUTPUT) endif else TE_PATH=$(TRACE_EVENT_DIR) + LK_PATH=$(LK_DIR) endif LIBTRACEEVENT = $(TE_PATH)libtraceevent.a diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index f139dcd..f446895 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -39,7 +39,7 @@ src-perf := $(srctree)/tools/perf endif ifeq ($(obj-perf),) -obj-perf := $(objtree) +obj-perf := $(OUTPUT) endif ifneq ($(obj-perf),) -- 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 tools: Fix output directory of Documentation/
Commit-ID: 761a0f395d5d8b7aafe563ecefbc8cf71a214a91
Gitweb: http://git.kernel.org/tip/761a0f395d5d8b7aafe563ecefbc8cf71a214a91
Author: Robert Richter
AuthorDate: Mon, 6 May 2013 20:40:14 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 8 Jul 2013 17:31:49 -0300
perf tools: Fix output directory of Documentation/
The OUTPUT directory is wrongly determind leading to:
make[3]: *** No rule to make target `.../.build/perf/PERF-VERSION-FILE'. Stop.
Fixing this by using the generic approach in script/Makefile.include.
Signed-off-by: Robert Richter
Link: http://lkml.kernel.org/r/1367865614-30876-1-git-send-email-r...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/Makefile | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/tools/perf/Documentation/Makefile
b/tools/perf/Documentation/Makefile
index f751757..5a37a7c 100644
--- a/tools/perf/Documentation/Makefile
+++ b/tools/perf/Documentation/Makefile
@@ -1,12 +1,6 @@
+include ../../scripts/Makefile.include
include ../config/utilities.mak
-OUTPUT := ./
-ifeq ("$(origin O)", "command line")
- ifneq ($(O),)
- OUTPUT := $(O)/
- endif
-endif
-
MAN1_TXT= \
$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
$(wildcard perf-*.txt)) \
@@ -277,7 +271,7 @@ $(MAN_HTML): $(OUTPUT)%.html : %.txt
$(OUTPUT)%.1 $(OUTPUT)%.5 $(OUTPUT)%.7 : $(OUTPUT)%.xml
$(QUIET_XMLTO)$(RM) $@ && \
- $(XMLTO) -o $(OUTPUT) -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<
+ $(XMLTO) -o $(OUTPUT). -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<
$(OUTPUT)%.xml : %.txt
$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
--
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/
boot tracing
On Fri, Jul 12, 2013 at 10:27:56AM +0200, Ingo Molnar wrote: > Robert Richter and Boris Petkov are working on 'persistent events' > support for perf, which will eventually allow boot time profiling - > I'm not sure if the patches and the tooling support is ready enough > yet for your purposes. Nope, not yet but we're getting there. > Robert, Boris, the following workflow would be pretty intuitive: > > - kernel developer sets boot flag: perf=boot,freq=1khz,size=16MB What does perf=boot mean? I assume boot tracing. If so, does it mean we want to enable *all* tracepoints and collect whatever hits us? What makes more sense to me is to hijack what the function tracer does - i.e. simply collect all function calls. > - we'd get a single (cycles?) event running once the perf subsystem is up >and running, with a sampling frequency of 1 KHz, sending profiling >trace events to a sufficiently sized profiling buffer of 16 MB per >CPU. Right, what would those trace events be? > - once the system reaches SYSTEM_RUNNING, profiling is stopped either >automatically - or the user stops it via a new tooling command. Ok. > - the profiling buffer is extracted into a regular perf.data via a >special 'perf record' call or some other, new perf tooling >solution/variant. > >[ Alternatively the kernel could attempt to construct a 'virtual' > perf.data from the persistent buffer, available via /sys/debug or > elsewhere in /sys - just like the kernel constructs a 'virtual' > /proc/kcore, etc. That file could be copied or used directly. ] Yeah, that. > - from that point on this workflow joins the regular profiling workflow: >perf report, perf script et al can be used to analyze the resulting >boot profile. Agreed. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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] i2c-designware: make *CNT values configurable
On Fri, Jul 12, 2013 at 04:56:49PM +0900, Shinya Kuribayashi wrote: > On 7/11/13 7:13 PM, Mika Westerberg wrote: > >On Thu, Jul 11, 2013 at 10:36:00AM +0300, Mika Westerberg wrote: > >>On Wed, Jul 10, 2013 at 06:56:35PM +0200, Christian Ruppert wrote: > >>>On Wed, Jul 10, 2013 at 01:52:15PM +0300, Mika Westerberg wrote: > On Tue, Jul 09, 2013 at 06:19:28PM +0200, Christian Ruppert wrote: > >What I meant is the following: The clock cycle time Tc is composed of > >the four components > > > > Tc = Th + Tf + Tl + Tr > > > >where > > Th: Time during which the signal is high > > Tf: Falling edge transition time > > Tl: Time during which the signal is low > > Tr: Rising edge transition time > > > >The I2C specification specifies a minimum for Tl and Th and a range (or > >maximum) for Tr and Tf. A maximum frequency is specified as the > >frequency obtained by adding the minima for Th and Tl to the maxima of > >Tr ant Tf. > >Since as you said, transition times are very much PCB dependent, one way > >to guarantee the max. frequency constraint (and to achieve a constant > >frequency at its max) is to define the constants > >Th' = Th + Tf := Th_min + Tf_max > >Tl' = Tl + Tr := Tl_min + Tr_max > > > >and to calculate the variables > >Th = Th' - Tf > >Tl = Tl' - Tr > >in function of Tf and Tr of the given PCB. > > If I understand the above, it leaves Tf and Tr to be PCB specific and then > these values are passed to the core driver from platform data, right? > >>> > >>>That would be the idea: Calculate Th' and Tl' in function of the desired > >>>clock frequency and duty cycle and then adapt these values using > >>>measured transition times. What prevented me from implementing this > >>>rather academic approach are the following comments in > >>>i2c-designware-core.c: > > When we talk about I2C timing specs, we should not bring up "clock speed" > things. All we have to do is to strictly meet timing constraints of > tHIGH, tLOW, tHD;SATA, tr, tf, etc. The resulting "clock speed" is not > a goal. OK, thanks for the explanation. I'm relatively new with I2C bus even though I've adapted the DW I2C driver to work on our HW. > >>>/* > >>> * DesignWare I2C core doesn't seem to have solid strategy to meet > >>> * the tHD;STA timing spec. Configuring _HCNT based on tHIGH spec > >>> * will result in violation of the tHD;STA spec. > >>> */ > >>> > >>>/* ... > >>> * This is just experimental rule; the tHD;STA period > >>> * turned out to be proportinal to (_HCNT + 3). With this setting, > >>> * we could meet both tHIGH and tHD;STA timing specs. > >>> * ... > >>> */ > >>> > >>>If I interpret this right, the slow down of the clock is intentional to > >>>meet tHD;STA timing constraints. > > Correct. > > >>Yeah, looks like so. tHD;STA is the SDA hold time. I wonder if the above > >>comments apply to some earlier version of the IP that didn't have the SDA > >>hold register? > > If I remember DesignWare APB I2C spec correctly, SDA hold time register > doesn't help to meet tHD;STA spec. Could someone confirm it really so > with a real hardware, please? Indeed, SDA hold in the DesignWare I2C is not the same as tHD;STA according the databook. Unfortunately I don't have means to actually measure that here. Anyway, the HCNT, LCNT and SDA hold time values we get from ACPI SSCN/FMCN methods are measured by our HW guys on a certain board and they have verified that using those we meet all the I2C timing specs. In order to take advantage of those we need some way to pass those values to the i2c designware core. I have two suggestions: - Use the method outlined in this patch and let the interface driver override *CNT values. - Allow interface drivers to override the function that does calculations for these values like: if (dev->std_scl_cnt) dev->std_scl_cnt(dev, , ); else /* Fallback to the calculation based solely on iclk */ Any comments on these? -- 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: is it desirable to improve the build system?
On Thu, Jul 11, 2013 at 02:22:14PM -0700, Mark Galeck wrote: > >The answer to "is it desirable to improve X?" is always "yes." But > > the only way to make progress in Linux is to actually post patches > that "improve X." This is unlike many corporate environments, where > you might need to get somebody's approval > > > Precisely. Please excuse me coming from a corporate background. > In corporate, even if you "get somebody's approval", there may be "other > stakeholders" who may "feel ownership" etc etc Yes, your approved project may get canned later. But the point was, that you aren't allowed to even get started without someone's approval. Thanks, Richard -- 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 0/4] Transparent on-demand struct page initialization embedded in the buddy allocator
* Robin Holt wrote: > [...] > > With this patch, we did boot a 16TiB machine. Without the patches, the > v3.10 kernel with the same configuration took 407 seconds for > free_all_bootmem. With the patches and operating on 2MiB pages instead > of 1GiB, it took 26 seconds so performance was improved. I have no feel > for how the 1GiB chunk size will perform. That's pretty impressive. It's still a 15x speedup instead of a 512x speedup, so I'd say there's something else being the current bottleneck, besides page init granularity. Can you boot with just a few gigs of RAM and stuff the rest into hotplug memory, and then hot-add that memory? That would allow easy profiling of remaining overhead. Side note: Robert Richter and Boris Petkov are working on 'persistent events' support for perf, which will eventually allow boot time profiling - I'm not sure if the patches and the tooling support is ready enough yet for your purposes. Robert, Boris, the following workflow would be pretty intuitive: - kernel developer sets boot flag: perf=boot,freq=1khz,size=16MB - we'd get a single (cycles?) event running once the perf subsystem is up and running, with a sampling frequency of 1 KHz, sending profiling trace events to a sufficiently sized profiling buffer of 16 MB per CPU. - once the system reaches SYSTEM_RUNNING, profiling is stopped either automatically - or the user stops it via a new tooling command. - the profiling buffer is extracted into a regular perf.data via a special 'perf record' call or some other, new perf tooling solution/variant. [ Alternatively the kernel could attempt to construct a 'virtual' perf.data from the persistent buffer, available via /sys/debug or elsewhere in /sys - just like the kernel constructs a 'virtual' /proc/kcore, etc. That file could be copied or used directly. ] - from that point on this workflow joins the regular profiling workflow: perf report, perf script et al can be used to analyze the resulting boot profile. 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 net 2/2] usb/net/r815x: fix cast to restricted __le32
>> drivers/net/usb/r815x.c:38:16: sparse: cast to restricted __le32
>> drivers/net/usb/r815x.c:67:15: sparse: cast to restricted __le32
>> drivers/net/usb/r815x.c:69:13: sparse: incorrect type in assignment
>> (different base types)
drivers/net/usb/r815x.c:69:13:expected unsigned int [unsigned]
[addressable] [assigned] [usertype] tmp
drivers/net/usb/r815x.c:69:13:got restricted __le32 [usertype]
Signed-off-by: Hayes Wang
Spotted-by: kbuild test robot
---
drivers/net/usb/r815x.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/net/usb/r815x.c b/drivers/net/usb/r815x.c
index 6516737..8523922 100644
--- a/drivers/net/usb/r815x.c
+++ b/drivers/net/usb/r815x.c
@@ -26,16 +26,18 @@ static int pla_read_word(struct usb_device *udev, u16 index)
{
int data, ret;
u8 shift = index & 2;
+ __le32 ocp_data;
index &= ~3;
ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
RTL815x_REQ_GET_REGS, RTL815x_REQT_READ,
- index, MCU_TYPE_PLA, , sizeof(data), 500);
+ index, MCU_TYPE_PLA, _data, sizeof(ocp_data),
+ 500);
if (ret < 0)
return ret;
- data = __le32_to_cpu(data);
+ data = __le32_to_cpu(ocp_data);
data >>= (shift * 8);
data &= 0x;
@@ -44,7 +46,8 @@ static int pla_read_word(struct usb_device *udev, u16 index)
static int pla_write_word(struct usb_device *udev, u16 index, u32 data)
{
- u32 tmp, mask = 0x;
+ __le32 ocp_data;
+ u32 mask = 0x;
u16 byen = BYTE_EN_WORD;
u8 shift = index & 2;
int ret;
@@ -60,18 +63,18 @@ static int pla_write_word(struct usb_device *udev, u16
index, u32 data)
ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
RTL815x_REQ_GET_REGS, RTL815x_REQT_READ,
- index, MCU_TYPE_PLA, , sizeof(tmp), 500);
+ index, MCU_TYPE_PLA, _data, sizeof(ocp_data),
+ 500);
if (ret < 0)
return ret;
- tmp = __le32_to_cpu(tmp) & ~mask;
- tmp |= data;
- tmp = __cpu_to_le32(tmp);
+ data |= __le32_to_cpu(ocp_data) & ~mask;
+ ocp_data = __cpu_to_le32(data);
ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
RTL815x_REQ_SET_REGS, RTL815x_REQT_WRITE,
- index, MCU_TYPE_PLA | byen, ,
- sizeof(tmp), 500);
+ index, MCU_TYPE_PLA | byen, _data,
+ sizeof(ocp_data), 500);
return ret;
}
--
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 net 1/2] usb/net/r8152: fix integer overflow in expression
config: make ARCH=avr32 allyesconfig drivers/net/usb/r8152.c: In function 'rtl8152_start_xmit': drivers/net/usb/r8152.c:956: warning: integer overflow in expression 955 memset(tx_desc, 0, sizeof(*tx_desc)); > 956 tx_desc->opts1 = cpu_to_le32((len & TX_LEN_MASK) | TX_FS | TX_LS); 957 tp->tx_skb = skb; Signed-off-by: Hayes Wang Spotted-by: kbuild test robot --- drivers/net/usb/r8152.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index d02bac8..ee13f9e 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -934,7 +934,8 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff *skb, struct r8152 *tp = netdev_priv(netdev); struct net_device_stats *stats = rtl8152_get_stats(netdev); struct tx_desc *tx_desc; - int len, res; + unsigned int len; + int res; netif_stop_queue(netdev); len = skb->len; -- 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/
hi
Ciao il mio nome è vera devo dire che scintilla il mio interesse per un buon partner, mi piacerebbe sapere di più per lo scambio di amore e di amicizia, non esitate a inviarmi una e-mail attraverso il mio id mail (vera.matine @ yahoo. com) Please in modo che io vi manderò la mia foto e ti dirà di più su myself. awaiting tua mail in modo che si può qui passare da qui, Prenditi cura. Hello my name is vera i must say it spark my interest for a good partner,i will like to know you more to exchange love and friendship, Please feel free to send me a mail through my mail id ( vera.mat...@yahoo.com ) so that i will send you my picture and tell you more about myself.awaiting your mail so that can here move on from here,Take care. -- 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: BUG: key ffff880c1148c478 not in .data! (V3.10.0)
On 2013.07.12 at 10:19 +0800, Ming Lei wrote: > On Mon, Jul 8, 2013 at 6:25 AM, Linda Walsh wrote: > > Also am seeing this for the first time: > > > > (don't know, but seems unlikely to be related to > > https://patchwork.kernel.org/patch/87359/ > > Yet it is the only hit I found for the same message. > > > > > > Looks like it's back to a more stable 3.9.8... > > (*sigh*) > > > > > > BUG: key 880c1148c478 not in .data! > > [4.429474] [ cut here ] > > [4.434236] WARNING: at kernel/lockdep.c:2987 > > lockdep_init_map+0x45e/0x490() > > [4.441414] DEBUG_LOCKS_WARN_ON(1) > > [4.444684] Modules linked in: > > [4.448168] usb 1-3.2: new low-speed USB device number 3 using ehci-pci > > [4.454975] CPU: 10 PID: 1 Comm: swapper/0 Tainted: G I > > 3.10.0-Isht-Van #1 > > [4.462862] Hardware name: Dell Inc. PowerEdge T610/0CX0R0, BIOS 6.3.0 > > 07/24/2012 > > [4.470475] 0009 880c13175a70 815bb279 > > 880c13175aa8 > > [4.478221] 8104641c 880c11c12130 880c1148c478 > > > > [4.485988] 880c11c12058 880c12386180 880c13175b08 > > 81046487 > > [4.493800] Call Trace: > > [4.496472] [] dump_stack+0x19/0x1b > > [4.501776] [] warn_slowpath_common+0x5c/0x80 > > [4.507917] [] warn_slowpath_fmt+0x47/0x50 > > [4.513790] [] lockdep_init_map+0x45e/0x490 > > [4.519775] [] debug_mutex_init+0x2d/0x40 > > [4.525567] [] __mutex_init+0x51/0x60 > > [4.531017] [] bus_register+0x158/0x2c0 > > [4.536646] [] edac_create_sysfs_mci_device+0x53/0x540 > > Looks because that bus_type of 'struct mem_ctl_info' is allocated dynamically > instead of being kept it in .data statically. Mauro said he will fix this in the coming weeks: http://article.gmane.org/gmane.linux.kernel/1522719 -- Markus -- 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 -next 2/2] kbuild: fix for updated LZ4 tool with the new streaming format
On Fri, Jul 12, 2013 at 09:56:02AM +0200, Ingo Molnar wrote: > If a utility is not widely available yet and if the utility is not in > the kernel proper, could you please at least make sure that randconfig > does not stumble over non-buildable kernels? Two months ago I've complained about this and other people have burned themselves too in the meantime... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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 v3] x86: introduce int3-based instruction patching
On Thu, Jul 11, 2013 at 02:36:38PM -0700, H. Peter Anvin wrote: > On 07/11/2013 02:04 PM, Borislav Petkov wrote: > > On Thu, Jul 11, 2013 at 01:53:16PM -0700, H. Peter Anvin wrote: > >> Has anyone talked to AMD or VIA about this at all? > > > > I guess I can try to take care of the AMD part. Just to confirm, is this > > the exact sequence we're interested in: > > > > 1. Setup int3 handler for fixup. > > > > 2. Put a breakpoint (int3) on the first byte of modifying region, and > > synchronize code on all CPUs. > > > > 3. Modify other bytes of modifying region. > > > > 4. Modify the first byte of modifying region, and synchronize code on > > all CPUs. > > > > 5. Clear int3 handler. > > > > If a suitable int3 handler is left permanently in place then the > > synchronization in step 4 is unnecessary. > > > > Correct. Right, above sequence would work on AMD. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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 -next 2/2] kbuild: fix for updated LZ4 tool with the new streaming format
* Kyungsik Lee wrote: > LZ4 has been updated with LZ4 Streaming Format specification(v1.3). > lz4demo is replaced by lz4c. lz4c supports both the new streaming and > legacy format with -l option. > > This patch makes use of lz4c to support legacy format which is > used for LZ4 De/compression in the linux kernel. > > Link: https://code.google.com/p/lz4/source/checkout > Signed-off-by: Kyungsik Lee > Cc: "H. Peter Anvin" > Cc: Ingo Molnar > Cc: Thomas Gleixner > Cc: Russell King > Cc: Borislav Petkov > Cc: Florian Fainelli > Cc: Yann Collet > Cc: Chanho Min > --- > scripts/Makefile.lib | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index a0ab6d7..c9bfbb0 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -313,7 +313,7 @@ cmd_lzo = (cat $(filter-out FORCE,$^) | \ > > quiet_cmd_lz4 = LZ4 $@ > cmd_lz4 = (cat $(filter-out FORCE,$^) | \ > - lz4demo -c1 stdin stdout && $(call size_append, $(filter-out > FORCE,$^))) > $@ || \ > + lz4c -l -c1 stdin stdout && $(call size_append, $(filter-out > FORCE,$^))) > $@ || \ > (rm -f $@ ; false) None of the major distros I tried has the lz4 or lz4c binary available, and this breaks randconfig builds: /bin/sh: lz4c: command not found If: CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_LZ4=y CONFIG_RD_LZ4=y CONFIG_LZ4_DECOMPRESS=y CONFIG_DECOMPRESS_LZ4=y If a utility is not widely available yet and if the utility is not in the kernel proper, could you please at least make sure that randconfig does not stumble over non-buildable kernels? 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] i2c-designware: make *CNT values configurable
On 7/11/13 7:13 PM, Mika Westerberg wrote: On Thu, Jul 11, 2013 at 10:36:00AM +0300, Mika Westerberg wrote: On Wed, Jul 10, 2013 at 06:56:35PM +0200, Christian Ruppert wrote: On Wed, Jul 10, 2013 at 01:52:15PM +0300, Mika Westerberg wrote: On Tue, Jul 09, 2013 at 06:19:28PM +0200, Christian Ruppert wrote: What I meant is the following: The clock cycle time Tc is composed of the four components Tc = Th + Tf + Tl + Tr where Th: Time during which the signal is high Tf: Falling edge transition time Tl: Time during which the signal is low Tr: Rising edge transition time The I2C specification specifies a minimum for Tl and Th and a range (or maximum) for Tr and Tf. A maximum frequency is specified as the frequency obtained by adding the minima for Th and Tl to the maxima of Tr ant Tf. Since as you said, transition times are very much PCB dependent, one way to guarantee the max. frequency constraint (and to achieve a constant frequency at its max) is to define the constants Th' = Th + Tf := Th_min + Tf_max Tl' = Tl + Tr := Tl_min + Tr_max and to calculate the variables Th = Th' - Tf Tl = Tl' - Tr in function of Tf and Tr of the given PCB. If I understand the above, it leaves Tf and Tr to be PCB specific and then these values are passed to the core driver from platform data, right? That would be the idea: Calculate Th' and Tl' in function of the desired clock frequency and duty cycle and then adapt these values using measured transition times. What prevented me from implementing this rather academic approach are the following comments in i2c-designware-core.c: When we talk about I2C timing specs, we should not bring up "clock speed" things. All we have to do is to strictly meet timing constraints of tHIGH, tLOW, tHD;SATA, tr, tf, etc. The resulting "clock speed" is not a goal. /* * DesignWare I2C core doesn't seem to have solid strategy to meet * the tHD;STA timing spec. Configuring _HCNT based on tHIGH spec * will result in violation of the tHD;STA spec. */ /* ... * This is just experimental rule; the tHD;STA period * turned out to be proportinal to (_HCNT + 3). With this setting, * we could meet both tHIGH and tHD;STA timing specs. * ... */ If I interpret this right, the slow down of the clock is intentional to meet tHD;STA timing constraints. Correct. Yeah, looks like so. tHD;STA is the SDA hold time. I wonder if the above comments apply to some earlier version of the IP that didn't have the SDA hold register? If I remember DesignWare APB I2C spec correctly, SDA hold time register doesn't help to meet tHD;STA spec. Could someone confirm it really so with a real hardware, please? Shinya Scratch that. I re-read the spec and tHD;STA is hold time for (repeated) start. There is a constraint that says that the device must internally provide a hold time of at least 300ns for the SDA signal. Maybe that's the constraint the comment above is referring to? -- 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] ARM: dt: t114 dalmore: add dt entry for nct1008
Enable thermal sensor nct1008 for t114 dalmore.
Signed-off-by: Wei Ni
---
arch/arm/boot/dts/tegra114-dalmore.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
b/arch/arm/boot/dts/tegra114-dalmore.dts
index cb640eb..47ec7eb 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -738,6 +738,13 @@
realtek,ldo1-en-gpios =
< TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
};
+
+ nct1008 {
+ compatible = "onnn,nct1008";
+ reg = <0x4c>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
};
i2c@7000d000 {
--
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/
[PATCH v3 0/4] Lm90 Enhancements
This patch set enhance the lm90 driver, it make the driver more readable and easier to use thermal framework. This series is v2, previous version patches: [RFC]: http://thread.gmane.org/gmane.linux.power-management.general/31056 [v1]: http://thread.gmane.org/gmane.linux.ports.tegra/11710/ [v2]: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg46.html Changes from v2: 1. update the defines for status bit, and go into a separate patch. 2. introduce the new lm90_is_tripped() for lm90_irq_thread and lm90_alert. Changes from v1: 1. change the string "irq" to "IRQ" 2. add macro defines for the alarm status 3. consider the shared IRQ. Changes from RFC: 1. change _show_temp() to read_temp(), _set_temp() to write_temp(). 2. simply return value for the read_temp(), not use pointer. 3. use devm_request_threaded_irq() to request irq and set flag IRQF_ONESHOT. Wei Ni (4): hwmon: (lm90) split set temp as common codes hwmon: (lm90) use macro defines for the status bit hwmon: (lm90) add support to handle IRQ hwmon: (lm90) use enums for the indexes of temp8 and temp11 drivers/hwmon/lm90.c | 387 +- 1 file changed, 256 insertions(+), 131 deletions(-) -- 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/
[PATCH v3 3/4] hwmon: (lm90) add support to handle IRQ
When the temperature exceed the limit range value,
the driver can handle the interrupt.
Signed-off-by: Wei Ni
---
drivers/hwmon/lm90.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index c90037f..1cc3d19 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -89,6 +89,7 @@
#include
#include
#include
+#include
/*
* Addresses to scan
@@ -1460,6 +1461,17 @@ static bool lm90_is_tripped(struct i2c_client *client)
return true;
}
+static irqreturn_t lm90_irq_thread(int irq, void *dev_id)
+{
+ struct lm90_data *data = dev_id;
+ struct i2c_client *client = to_i2c_client(data->hwmon_dev->parent);
+
+ if (lm90_is_tripped(client))
+ return IRQ_HANDLED;
+ else
+ return IRQ_NONE;
+}
+
static int lm90_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -1536,6 +1548,18 @@ static int lm90_probe(struct i2c_client *client,
goto exit_remove_files;
}
+ if (client->irq >= 0) {
+ dev_dbg(dev, "lm90 IRQ: %d\n", client->irq);
+ err = devm_request_threaded_irq(dev, client->irq,
+ NULL, lm90_irq_thread,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ "lm90", data);
+ if (err < 0) {
+ dev_err(dev, "cannot request interrupt\n");
+ goto exit_remove_files;
+ }
+ }
+
return 0;
exit_remove_files:
--
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/
[PATCH v3 1/4] hwmon: (lm90) split set temp as common codes
Split set temp codes as common functions, so we can use it directly when
implement linux thermal framework.
Signed-off-by: Wei Ni
---
drivers/hwmon/lm90.c | 112 +++---
1 file changed, 69 insertions(+), 43 deletions(-)
diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index 8eeb141..5f30f90 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -702,29 +702,34 @@ static u16 temp_to_u16_adt7461(struct lm90_data *data,
long val)
* Sysfs stuff
*/
-static ssize_t show_temp8(struct device *dev, struct device_attribute *devattr,
- char *buf)
+static int read_temp8(struct device *dev, int index)
{
- struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
struct lm90_data *data = lm90_update_device(dev);
int temp;
if (data->kind == adt7461)
- temp = temp_from_u8_adt7461(data, data->temp8[attr->index]);
+ temp = temp_from_u8_adt7461(data, data->temp8[index]);
else if (data->kind == max6646)
- temp = temp_from_u8(data->temp8[attr->index]);
+ temp = temp_from_u8(data->temp8[index]);
else
- temp = temp_from_s8(data->temp8[attr->index]);
+ temp = temp_from_s8(data->temp8[index]);
/* +16 degrees offset for temp2 for the LM99 */
- if (data->kind == lm99 && attr->index == 3)
+ if (data->kind == lm99 && index == 3)
temp += 16000;
- return sprintf(buf, "%d\n", temp);
+ return temp;
}
-static ssize_t set_temp8(struct device *dev, struct device_attribute *devattr,
-const char *buf, size_t count)
+static ssize_t show_temp8(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+
+ return sprintf(buf, "%d\n", read_temp8(dev, attr->index));
+}
+
+static void write_temp8(struct device *dev, int index, long val)
{
static const u8 reg[8] = {
LM90_REG_W_LOCAL_LOW,
@@ -737,60 +742,73 @@ static ssize_t set_temp8(struct device *dev, struct
device_attribute *devattr,
MAX6659_REG_W_REMOTE_EMERG,
};
- struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
struct i2c_client *client = to_i2c_client(dev);
struct lm90_data *data = i2c_get_clientdata(client);
- int nr = attr->index;
- long val;
- int err;
-
- err = kstrtol(buf, 10, );
- if (err < 0)
- return err;
/* +16 degrees offset for temp2 for the LM99 */
- if (data->kind == lm99 && attr->index == 3)
+ if (data->kind == lm99 && index == 3)
val -= 16000;
mutex_lock(>update_lock);
if (data->kind == adt7461)
- data->temp8[nr] = temp_to_u8_adt7461(data, val);
+ data->temp8[index] = temp_to_u8_adt7461(data, val);
else if (data->kind == max6646)
- data->temp8[nr] = temp_to_u8(val);
+ data->temp8[index] = temp_to_u8(val);
else
- data->temp8[nr] = temp_to_s8(val);
+ data->temp8[index] = temp_to_s8(val);
- lm90_select_remote_channel(client, data, nr >= 6);
- i2c_smbus_write_byte_data(client, reg[nr], data->temp8[nr]);
+ lm90_select_remote_channel(client, data, index >= 6);
+ i2c_smbus_write_byte_data(client, reg[index], data->temp8[index]);
lm90_select_remote_channel(client, data, 0);
mutex_unlock(>update_lock);
+}
+
+static ssize_t set_temp8(struct device *dev, struct device_attribute *devattr,
+const char *buf, size_t count)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ int index = attr->index;
+ long val;
+ int err;
+
+ err = kstrtol(buf, 10, );
+ if (err < 0)
+ return err;
+
+ write_temp8(dev, index, val);
+
return count;
}
-static ssize_t show_temp11(struct device *dev, struct device_attribute
*devattr,
- char *buf)
+static int read_temp11(struct device *dev, int index)
{
- struct sensor_device_attribute_2 *attr = to_sensor_dev_attr_2(devattr);
struct lm90_data *data = lm90_update_device(dev);
int temp;
if (data->kind == adt7461)
- temp = temp_from_u16_adt7461(data, data->temp11[attr->index]);
+ temp = temp_from_u16_adt7461(data, data->temp11[index]);
else if (data->kind == max6646)
- temp = temp_from_u16(data->temp11[attr->index]);
+ temp = temp_from_u16(data->temp11[index]);
else
- temp = temp_from_s16(data->temp11[attr->index]);
+ temp = temp_from_s16(data->temp11[index]);
/* +16 degrees offset for temp2 for the LM99 */
- if (data->kind ==
[PATCH v3 0/2] Enable lm90 in Tegra30 and Tegra114.
Enable thermal sensor lm90 for Tegra30 Cardhu and Tegra114 Dalmore. This series is v2, previous version patches: [RFC 1/9]: http://thread.gmane.org/gmane.linux.power-management.general/31056 [v1]: http://thread.gmane.org/gmane.linux.ports.tegra/11713/ [v2]: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg465561.html Changes from v2: 1. remove the label "nct1008". Changes from v1: 1. add vendor strings "onnn" for nct1008 node. Changes from RFC: 1. Enable it for Tegra114 Dalmore. Wei Ni (2): ARM: dt: t30 cardhu: add dt entry for nct1008 ARM: dt: t114 dalmore: add dt entry for nct1008 arch/arm/boot/dts/tegra114-dalmore.dts |7 +++ arch/arm/boot/dts/tegra30-cardhu.dtsi |7 +++ 2 files changed, 14 insertions(+) -- 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/
[PATCH v3 1/2] ARM: dt: t30 cardhu: add dt entry for nct1008
Enable thermal sensor nct1008 for t30 cardhu.
Signed-off-by: Wei Ni
---
arch/arm/boot/dts/tegra30-cardhu.dtsi |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi
b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index f65b53d..e5759ca 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -286,6 +286,13 @@
};
};
};
+
+ nct1008 {
+ compatible = "onnn,nct1008";
+ reg = <0x4c>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
};
spi@7000da00 {
--
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/
[PATCH v3 4/4] hwmon: (lm90) use enums for the indexes of temp8 and temp11
Using enums for the indexes and nrs of temp8 and temp11.
This make the code much more readable.
Signed-off-by: Wei Ni
---
drivers/hwmon/lm90.c | 179 --
1 file changed, 114 insertions(+), 65 deletions(-)
diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index 1cc3d19..8cb5dd0 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -310,6 +310,59 @@ static const struct lm90_params lm90_params[] = {
};
/*
+ * TEMP8 register index
+ */
+enum lm90_temp8_reg_index {
+ TEMP8_LOCAL_LOW = 0,/* 0: local low limit */
+ TEMP8_LOCAL_HIGH, /* 1: local high limit */
+ TEMP8_LOCAL_CRIT, /* 2: local critical limit */
+ TEMP8_REMOTE_CRIT, /* 3: remote critical limit */
+ TEMP8_LOCAL_EMERG, /* 4: local emergency limit
+* (max6659 and max6695/96)
+*/
+ TEMP8_REMOTE_EMERG, /* 5: remote emergency limit
+* (max6659 and max6695/96)
+*/
+ TEMP8_REMOTE2_CRIT, /* 6: remote 2 critical limit
+* (max6695/96 only)
+*/
+ TEMP8_REMOTE2_EMERG,/* 7: remote 2 emergency limit
+* (max6695/96 only)
+*/
+ TEMP8_REG_NUM
+};
+
+/*
+ * TEMP11 register index
+ */
+enum lm90_temp11_reg_index {
+ TEMP11_REMOTE_TEMP = 0, /* 0: remote input */
+ TEMP11_REMOTE_LOW, /* 1: remote low limit */
+ TEMP11_REMOTE_HIGH, /* 2: remote high limit */
+ TEMP11_REMOTE_OFFSET, /* 3: remote offset
+* (except max6646, max6657/58/59,
+* and max6695/96)
+*/
+ TEMP11_LOCAL_TEMP, /* 4: local input */
+ TEMP11_REMOTE2_TEMP,/* 5: remote 2 input (max6695/96 only) */
+ TEMP11_REMOTE2_LOW, /* 6: remote 2 low limit (max6695/96 only) */
+ TEMP11_REMOTE2_HIGH,/* 7: remote 2 high limit (max6695/96 only) */
+ TEMP11_REG_NUM
+};
+
+/*
+ * TEMP11 register NR
+ */
+enum lm90_temp11_reg_nr {
+ NR_CHAN_0_REMOTE_LOW = 0, /* 0: channel 0, remote low limit */
+ NR_CHAN_0_REMOTE_HIGH, /* 1: channel 0, remote high limit */
+ NR_CHAN_0_REMOTE_OFFSET,/* 2: channel 0, remote offset */
+ NR_CHAN_1_REMOTE_LOW, /* 3: channel 1, remote low limit */
+ NR_CHAN_1_REMOTE_HIGH, /* 4: channel 1, remote high limit */
+ NR_NUM /* number of the NRs for temp11 */
+};
+
+/*
* Client data (each client gets its own)
*/
@@ -331,25 +384,8 @@ struct lm90_data {
u8 reg_local_ext; /* local extension register offset */
/* registers values */
- s8 temp8[8];/* 0: local low limit
-* 1: local high limit
-* 2: local critical limit
-* 3: remote critical limit
-* 4: local emergency limit (max6659 and max6695/96)
-* 5: remote emergency limit (max6659 and max6695/96)
-* 6: remote 2 critical limit (max6695/96 only)
-* 7: remote 2 emergency limit (max6695/96 only)
-*/
- s16 temp11[8]; /* 0: remote input
-* 1: remote low limit
-* 2: remote high limit
-* 3: remote offset (except max6646, max6657/58/59,
-* and max6695/96)
-* 4: local input
-* 5: remote 2 input (max6695/96 only)
-* 6: remote 2 low limit (max6695/96 only)
-* 7: remote 2 high limit (max6695/96 only)
-*/
+ s8 temp8[TEMP8_REG_NUM];
+ s16 temp11[TEMP11_REG_NUM];
u8 temp_hyst;
u16 alarms; /* bitvector (upper 8 bits for max6695/96) */
};
@@ -491,37 +527,42 @@ static struct lm90_data *lm90_update_device(struct device
*dev)
u8 alarms;
dev_dbg(>dev, "Updating lm90 data.\n");
- lm90_read_reg(client, LM90_REG_R_LOCAL_LOW, >temp8[0]);
- lm90_read_reg(client, LM90_REG_R_LOCAL_HIGH, >temp8[1]);
- lm90_read_reg(client, LM90_REG_R_LOCAL_CRIT, >temp8[2]);
- lm90_read_reg(client, LM90_REG_R_REMOTE_CRIT, >temp8[3]);
+ lm90_read_reg(client, LM90_REG_R_LOCAL_LOW,
+ >temp8[TEMP8_LOCAL_LOW]);
+ lm90_read_reg(client, LM90_REG_R_LOCAL_HIGH,
+ >temp8[TEMP8_LOCAL_HIGH]);
+ lm90_read_reg(client, LM90_REG_R_LOCAL_CRIT,
+ >temp8[TEMP8_LOCAL_CRIT]);
+ lm90_read_reg(client,
[PATCH v3 2/4] hwmon: (lm90) use macro defines for the status bit
Add bit defines for the status register.
Signed-off-by: Wei Ni
---
drivers/hwmon/lm90.c | 72 ++
1 file changed, 49 insertions(+), 23 deletions(-)
diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index 5f30f90..c90037f 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -179,6 +179,19 @@ enum chips { lm90, adm1032, lm99, lm86, max6657, max6659,
adt7461, max6680,
#define LM90_HAVE_TEMP3(1 << 6) /* 3rd temperature sensor
*/
#define LM90_HAVE_BROKEN_ALERT (1 << 7) /* Broken alert*/
+/* LM90 status */
+#define LM90_STATUS_LTHRM (1 << 0) /* local THERM limit tripped */
+#define LM90_STATUS_RTHRM (1 << 1) /* remote THERM limit tripped */
+#define LM90_STATUS_OPEN (1 << 2) /* remote is an open circuit */
+#define LM90_STATUS_RLOW (1 << 3) /* remote low temp limit tripped */
+#define LM90_STATUS_RHIGH (1 << 4) /* remote high temp limit tripped */
+#define LM90_STATUS_LLOW (1 << 5) /* local low temp limit tripped */
+#define LM90_STATUS_LHIGH (1 << 6) /* local high temp limit tripped */
+#define LM90_STATUS_BUSY (1 << 7) /* ADC is converting */
+
+#define MAX6696_STATUS2_RLOW (1 << 3) /* remote2 low temp limit tripped */
+#define MAX6696_STATUS2_RHIGH (1 << 4) /* remote2 high temp limit tripped */
+
/*
* Driver data (common to all clients)
*/
@@ -1417,6 +1430,36 @@ static void lm90_init_client(struct i2c_client *client)
i2c_smbus_write_byte_data(client, LM90_REG_W_CONFIG1, config);
}
+static bool lm90_is_tripped(struct i2c_client *client)
+{
+ struct lm90_data *data = i2c_get_clientdata(client);
+ u8 status, status2 = 0;
+
+ lm90_read_reg(client, LM90_REG_R_STATUS, );
+
+ if (data->kind == max6696)
+ lm90_read_reg(client, MAX6696_REG_R_STATUS2, );
+
+ if ((status & 0x7f) == 0 && (status2 & 0xfe) == 0)
+ return false;
+
+ if (status & (LM90_STATUS_LLOW | LM90_STATUS_LHIGH | LM90_STATUS_LTHRM))
+ dev_warn(>dev,
+"temp%d out of range, please check!\n", 1);
+ if (status & (LM90_STATUS_RLOW | LM90_STATUS_RHIGH | LM90_STATUS_RTHRM))
+ dev_warn(>dev,
+"temp%d out of range, please check!\n", 2);
+ if (status & LM90_STATUS_OPEN)
+ dev_warn(>dev,
+"temp%d diode open, please check!\n", 2);
+
+ if (status2 & (MAX6696_STATUS2_RLOW | MAX6696_STATUS2_RHIGH))
+ dev_warn(>dev,
+"temp%d out of range, please check!\n", 3);
+
+ return true;
+}
+
static int lm90_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -1515,36 +1558,19 @@ static int lm90_remove(struct i2c_client *client)
static void lm90_alert(struct i2c_client *client, unsigned int flag)
{
- struct lm90_data *data = i2c_get_clientdata(client);
- u8 config, alarms, alarms2 = 0;
-
- lm90_read_reg(client, LM90_REG_R_STATUS, );
-
- if (data->kind == max6696)
- lm90_read_reg(client, MAX6696_REG_R_STATUS2, );
-
- if ((alarms & 0x7f) == 0 && (alarms2 & 0xfe) == 0) {
+ if (!lm90_is_tripped(client)) {
dev_info(>dev, "Everything OK\n");
} else {
- if (alarms & 0x61)
- dev_warn(>dev,
-"temp%d out of range, please check!\n", 1);
- if (alarms & 0x1a)
- dev_warn(>dev,
-"temp%d out of range, please check!\n", 2);
- if (alarms & 0x04)
- dev_warn(>dev,
-"temp%d diode open, please check!\n", 2);
-
- if (alarms2 & 0x18)
- dev_warn(>dev,
-"temp%d out of range, please check!\n", 3);
-
/*
* Disable ALERT# output, because these chips don't implement
* SMBus alert correctly; they should only hold the alert line
* low briefly.
*/
+ struct lm90_data *data = i2c_get_clientdata(client);
+ u8 config, alarms;
+
+ lm90_read_reg(client, LM90_REG_R_STATUS, );
+
if ((data->flags & LM90_HAVE_BROKEN_ALERT)
&& (alarms & data->alert_alarms)) {
dev_dbg(>dev, "Disabling ALERT#\n");
--
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/
Re: [RFC 2/4] Have __free_pages_memory() free in larger chunks.
After sleeping on this, why can't we change __free_pages_bootmem
to not take an order, but rather nr_pages? If we did that,
then __free_pages_memory could just calculate nr_pages and call
__free_pages_bootmem one time.
I don't see why any of the callers of __free_pages_bootmem would not
easily support that change. Maybe I will work that up as part of a -v2
and see if it boots/runs.
At the very least, I think we could change to:
static void __init __free_pages_memory(unsigned long start, unsigned long end)
{
int order;
while (start < end) {
order = ffs(start);
while (start + (1UL << order) > end)
order--;
__free_pages_bootmem(start, order);
start += (1UL << order);
}
}
Robin
On Thu, Jul 11, 2013 at 09:03:53PM -0500, Robin Holt wrote:
> Currently, when free_all_bootmem() calls __free_pages_memory(), the
> number of contiguous pages that __free_pages_memory() passes to the
> buddy allocator is limited to BITS_PER_LONG. In order to be able to
> free only the first page of a 2MiB chunk, we need that to be increased
> to PTRS_PER_PMD.
>
> Signed-off-by: Robin Holt
> Signed-off-by: Nate Zimmer
> To: "H. Peter Anvin"
> To: Ingo Molnar
> Cc: Linux Kernel
> Cc: Linux MM
> Cc: Rob Landley
> Cc: Mike Travis
> Cc: Daniel J Blueman
> Cc: Andrew Morton
> Cc: Greg KH
> Cc: Yinghai Lu
> Cc: Mel Gorman
> ---
> mm/nobootmem.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/mm/nobootmem.c b/mm/nobootmem.c
> index bdd3fa2..3b512ca 100644
> --- a/mm/nobootmem.c
> +++ b/mm/nobootmem.c
> @@ -83,10 +83,10 @@ void __init free_bootmem_late(unsigned long addr,
> unsigned long size)
> static void __init __free_pages_memory(unsigned long start, unsigned long
> end)
> {
> unsigned long i, start_aligned, end_aligned;
> - int order = ilog2(BITS_PER_LONG);
> + int order = ilog2(max(BITS_PER_LONG, PTRS_PER_PMD));
>
> - start_aligned = (start + (BITS_PER_LONG - 1)) & ~(BITS_PER_LONG - 1);
> - end_aligned = end & ~(BITS_PER_LONG - 1);
> + start_aligned = (start + ((1UL << order) - 1)) & ~((1UL << order) - 1);
> + end_aligned = end & ~((1UL << order) - 1);
>
> if (end_aligned <= start_aligned) {
> for (i = start; i < end; i++)
> @@ -98,7 +98,7 @@ static void __init __free_pages_memory(unsigned long start,
> unsigned long end)
> for (i = start; i < start_aligned; i++)
> __free_pages_bootmem(pfn_to_page(i), 0);
>
> - for (i = start_aligned; i < end_aligned; i += BITS_PER_LONG)
> + for (i = start_aligned; i < end_aligned; i += 1 << order)
> __free_pages_bootmem(pfn_to_page(i), order);
>
> for (i = end_aligned; i < end; i++)
> --
> 1.8.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] input: don't call input_dev_release_keys() in resume
On 09:46 Fri 05 Jul , Oskar Andero wrote:
> Hi Dmitry,
>
> On 18:33 Thu 04 Apr , Dmitry Torokhov wrote:
> > Hi Oskar,
> >
> > On Thu, Mar 07, 2013 at 03:01:22PM +0100, oskar.and...@sonymobile.com wrote:
> > > From: Aleksej Makarov
> > >
> > > When waking up the platform by pressing a specific key, sending a
> > > release on that key makes it impossible to react on the event in
> > > user-space.
> > >
> >
> > No, we can not simply not release keys after resume from suspend, as
> > this leads to keys being stuck. Consider you are holding an 'I' key on
> > your external USB keyboard and close your laptop's lid. Then you release
> > the key and leave. Later you come back, open the lid waking the laptop
> > and observe endless stream of 'I' in your open terminal.
> >
> > Maybe we should release the keys during suspend time? I am not sure how
> > Android infrastructure will react to this though...
>
> I finally got the time to try this out. Releasing the keys in suspend
> also solves our problem. Would such patch work for the USB keyboard
> case you described? Theoretically, I think it should, right?
>
> So, basically:
>
> static int input_dev_suspend(struct device *dev)
> {
> struct input_dev *input_dev = to_input_dev(dev);
>
> - mutex_lock(_dev->mutex);
> -
> - if (input_dev->users)
> - input_dev_toggle(input_dev, false);
> -
> - mutex_unlock(_dev->mutex);
> + input_reset_device(input_dev);
>
> return 0;
> }
>
> static int input_dev_resume(struct device *dev)
> {
> - struct input_dev *input_dev = to_input_dev(dev);
> -
> - input_reset_device(input_dev);
> -
> return 0;
> }
>
> Should I send the patch?
Ping. Any thoughts on this?
Thanks!
-Oskar
--
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 RESEND 0/1] AHCI: Optimize interrupt processing
On Thu, Jul 11, 2013 at 04:00:37PM -0700, Nicholas A. Bellinger wrote:
> On Thu, 2013-07-11 at 12:26 +0200, Alexander Gordeev wrote:
> > On Wed, May 22, 2013 at 07:03:05PM +0200, Jens Axboe wrote:
> > > On Wed, May 22 2013, Alexander Gordeev wrote:
> > > > On Wed, May 22, 2013 at 08:50:03AM +0900, Tejun Heo wrote:
> > > > > Hmm. I'd normally apply this patch but block layer is just
> > > > > growing multi-queue support and libata is likely to be converted to mq
> > > > > in foreseeable future, so I'm a bit hesitant to make irq handling more
> > > > > sophiscated right now. Would you be interested in looking into
> > > > > converting libata to blk mq support? I'm pretty sure it'd yield far
> > > > > better outcome if done properly.
> > > >
> > > > I am not committing, but will look into it, sure.
> > >
> > > Would be most awesome, I'm sure Nic would not mind a bit of help on the
> > > SCSI/libata side :-)
> >
> > Hi Nicholas,
> >
> > Could you please clarify the status of SCSI MQ support? Is it usable now?
> >
>
> Hi Alexander,
>
> Thanks for taking a look. I've not made further progress in the last
> weeks on scsi-mq, but am still using virtio-scsi + scsi-mq <->
> vhost-scsi + per-cpu-ida for quite a bit for benchmarking purposes.
Thanks for the clarification, Nicholas.
> > I tried
> > git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git,
> > but it does not appear working without (at least) changes below to SCSI lib:
> >
>
> The only scsi-mq LLD conversions so far have been to virtio-scsi +
> scsi_debug to nop REQ_TYPE_FS.
I see. Do you think the changes I made is a right way to go?
I had to make it to avoid a NULL-pointer assignent and make BIO bounce
buffers work, but I do not really understand the mixture of old and
new code ( neither in fact :) )
> Just so I understand, your patch below is required in order to make what
> LLD function with scsi-mq..?
ata_piix
>
> Thanks!
>
> --nab
>
> > Thanks!
> >
> > diff --git a/drivers/scsi/scsi-mq.c b/drivers/scsi/scsi-mq.c
> > index ca6ff67..d8cc7a4 100644
> > --- a/drivers/scsi/scsi-mq.c
> > +++ b/drivers/scsi/scsi-mq.c
> > @@ -155,6 +155,7 @@ void scsi_mq_done(struct scsi_cmnd *sc)
> > static struct blk_mq_ops scsi_mq_ops = {
> > .queue_rq = scsi_mq_queue_rq,
> > .map_queue = blk_mq_map_queue,
> > + .timeout= scsi_times_out,
> > .alloc_hctx = blk_mq_alloc_single_hw_queue,
> > .free_hctx = blk_mq_free_single_hw_queue,
> > };
> > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > index 65360db..33aa373 100644
> > --- a/drivers/scsi/scsi_lib.c
> > +++ b/drivers/scsi/scsi_lib.c
> > @@ -283,7 +283,10 @@ int scsi_execute(struct scsi_device *sdev, const
> > unsigned char *cmd,
> > /*
> > * head injection *required* here otherwise quiesce won't work
> > */
> > - blk_execute_rq(req->q, NULL, req, 1);
> > + if (q->mq_ops)
> > + blk_mq_execute_rq(req->q, req);
> > + else
> > + blk_execute_rq(req->q, NULL, req, 1);
> >
> > /*
> > * Some devices (USB mass-storage in particular) may transfer
> > @@ -298,12 +301,8 @@ int scsi_execute(struct scsi_device *sdev, const
> > unsigned char *cmd,
> > *resid = req->resid_len;
> > ret = req->errors;
> > out:
> > - if (q->mq_ops) {
> > - printk("scsi_execute(): Calling blk_mq_free_request >>>\n");
> > - blk_mq_free_request(req);
> > - } else {
> > + if (!q->mq_ops)
> > blk_put_request(req);
> > - }
> >
> > return ret;
> > }
> >
> >
> > > And personally, can't wait to run it on the laptop! That's right, I
> > > alpha test on the laptop.
> > >
> > > --
> > > Jens Axboe
> > >
> >
>
>
--
Regards,
Alexander Gordeev
agord...@redhat.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 6/6] [RFC] usb: gadget: USB_GADGET should depend on HAS_DMA
Alan Stern writes: > On Thu, 11 Jul 2013, Geert Uytterhoeven wrote: > >> If NO_DMA=y: >> >> drivers/built-in.o: In function `dma_set_coherent_mask': >> include/linux/dma-mapping.h:93: undefined reference to `dma_supported' >> include/linux/dma-mapping.h:93: undefined reference to `dma_supported' >> drivers/built-in.o: In function `usb_gadget_unmap_request': >> drivers/usb/gadget/udc-core.c:91: undefined reference to `dma_unmap_sg' >> drivers/usb/gadget/udc-core.c:96: undefined reference to `dma_unmap_single' >> drivers/built-in.o: In function `usb_gadget_map_request': >> drivers/usb/gadget/udc-core.c:62: undefined reference to `dma_map_sg' >> drivers/usb/gadget/udc-core.c:71: undefined reference to `dma_map_single' >> drivers/usb/gadget/udc-core.c:74: undefined reference to `dma_mapping_error' >> >> Signed-off-by: Geert Uytterhoeven >> --- >> This one is very debatable: probably the parts using the DMA API should >> be factored out, instead of disabling the whole USB gadget subsystem. > > Indeed. How does this look instead? This one is much better. FWIW, Acked-by: Alexander Shishkin Regards, -- Alex -- 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: [Ksummit-2013-discuss] When to push bug fixes to mainline
On Thu, 2013-07-11 at 20:34 -0700, Greg Kroah-Hartman wrote: > On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote: > > On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote: > > > > > In any case, I've been very conservative in _not_ pushing bug fixes to > > > Linus after -rc3 (unless they are fixing a regression or the bug fix > > > is super-serious); I'd much rather have them cook in the ext4 tree > > > where they can get a lot more testing (a full regression test run for > > > ext4 takes over 24 hours), and for people trying out linux-next. > > > > > > Maybe the pendulum has swung too far in the direction of holding back > > > changes and trying to avoid the risk of introducing regressions; > > > perhaps this would be a good topic to discuss at the Kernel Summit. > > > > Yes, there does seem to be a certain ebb and flow as to how strict > > the rules are about what should go into stable, what fixes are "good > > enough" for a given -rc, how tight those rule are in -rc2 vs in -rc6, > > etc. If nothing else, a good repetitive flogging and a restatement of > > the One True Way to handle these things might be worthwhile once again... > > The rules are documented in stable_kernel_rules.txt for what I will > accept. > > I have been beating on maintainers for 8 years now to actually mark > patches for stable, and only this past year have I finally seen people > do it (we FINALLY got SCSI patches marked for stable in this merge > window!!!) What do you mean FINALLY? There've been SCSI patches marked for stable in every other merge window as well. The whole reason I ran the stable patch tracker before you took it over was so I could get the Cc: to stable stuff working. James > So now that maintainers are finally realizing that they need > to mark patches, I'll be pushing back harder on the patches that they do > submit, because the distros are rightfully pushing back on me for > accepting things that are outside of the stable_kernel_rules.txt > guidelines. > > If you look on the stable@vger list, I've already rejected 3 today and > asked about the huge 21 powerpc patches. Sure, it's not a lot, when > staring down 174 more to go, but it's a start... > > greg k-h > ___ > Ksummit-2013-discuss mailing list > ksummit-2013-disc...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-2013-discuss -- 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 6/8] cpufreq: Introduce a flag ('frozen') to separate full vs temporary init/teardown
On 12 July 2013 03:46, Srivatsa S. Bhat wrote: > During suspend/resume we would like to do a light-weight init/teardown of > CPUs in the cpufreq subsystem and preserve certain things such as sysfs files > etc across suspend/resume transitions. Add a flag called 'frozen' to help > distinguish the full init/teardown sequence from the light-weight one. > > Signed-off-by: Srivatsa S. Bhat > --- > > drivers/cpufreq/cpufreq.c | 66 > - > 1 file changed, 41 insertions(+), 25 deletions(-) Acked-by: Viresh Kumar -- 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: trace: remove __init from race_selftest_startup_function() and trace_selftest_startup_function_graph()
On 07/12/2013 11:04 AM, Chen Gang wrote:
> On 07/12/2013 10:38 AM, Steven Rostedt wrote:
>> On Fri, 2013-07-12 at 09:58 +0800, Chen Gang wrote:
>>> On 07/12/2013 09:41 AM, Steven Rostedt wrote:
On Fri, 2013-07-12 at 07:51 +0800, Chen Gang wrote:
>> Hmm, can all trace_selftest_startup_* (*selftest* in trace_selftest.c)
>> use '__init', so not waste memory keeping them around ?
Yeah, they should all be set to __init, but that's pretty low on the
totem poll, as distros don't enable selftests in their main kernels.
>>>
>>> Excuse me, my English is not quite well, I guess your meaning is:
>>>
>>> they should all be set to '__init', although it is minor in real world.
>>>
>>> Is it correct ?
>>
>> Correct.
>>
>>>
>>>
>>> For me, I recommend to let all *selftest* as the same: "all add '
>>> __init' or none add '__init'" (if choose add, all report warnings).
>>>
>>> Is it suitable to still send new related patch for it ? If so, could
>>> you provide your suggesting choice (all add, or none add) ?
>>
>> Does this patch fix your warning?
>>
>> -- Steve
>>
>
After the test, they will not report the related warning.
Hmm..., but that will let another none *selftest* functions miss
'__read_mostly'.
Do the original *selftest* intend to have no '__init' so can fit other
none *selftest* with '__read_mostly', and without warnings ?
Welcome any members' suggestions or completions.
Thanks.
> I guess it can (although I do not give a compiling test), it seems a
> better fixing.
>
> And is it suitable to let all *selftest* as the same ? (all add, or none
> add '__init').
>
> Thanks.
>
>> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
>> index a4ed382..5e794d1 100644
>> --- a/kernel/trace/trace.h
>> +++ b/kernel/trace/trace.h
>> @@ -680,6 +680,15 @@ extern int trace_selftest_startup_sched_switch(struct
>> tracer *trace,
>> struct trace_array *tr);
>> extern int trace_selftest_startup_branch(struct tracer *trace,
>> struct trace_array *tr);
>> +/*
>> + * Tracer data references selftest functions that only occur
>> + * on boot up. These can be __init functions. Thus, when selftests
>> + * are enabled, then the tracers need to reference __init functions.
>> + */
>> +#define __tracer_data __refdata
>> +#else
>> +/* Tracers are seldom changed. Optimize when selftests are disabled. */
>> +#define __tracer_data __read_mostly
>> #endif /* CONFIG_FTRACE_STARTUP_TEST */
>>
>> extern void *head_page(struct trace_array_cpu *data);
>> diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
>> index b863f93..38fe148 100644
>> --- a/kernel/trace/trace_functions.c
>> +++ b/kernel/trace/trace_functions.c
>> @@ -199,7 +199,7 @@ static int func_set_flag(u32 old_flags, u32 bit, int set)
>> return 0;
>> }
>>
>> -static struct tracer function_trace __read_mostly =
>> +static struct tracer function_trace __tracer_data =
>> {
>> .name = "function",
>> .init = function_trace_init,
>>
>>
>>
>>
>
>
--
Chen Gang
--
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] iio: hid-sensor: add module alias for autoload
Am 11.07.2013 19:27, schrieb Srinivas Pandruvada: On 07/10/2013 08:58 AM, Alexander Holler wrote: Am 10.07.2013 17:27, schrieb Srinivas Pandruvada: Hi, There was no intention to prevent auto loading. Did you get chance to test these changes? Sure, I always test patches before I send them out. Ok, I haven't tested the changes with the iio HID drivers (I don't have any commercial HID sensor hub, so I've just compile tested these patches here, double reading them), but I've tested the similiar changes with a patch for rtc-hid-sensor-time I've send out yesterday. (sorry, no link, lkml.org seems dead, just search for "rtc-hid-sensor-time: add module alias") It works just fine. An example output is now Jul 9 19:27:21 dockstar3 kernel: [5.12] rtc_hid_sensor_time HID-SENSOR-2000a0.0: milliseconds supported Jul 9 19:27:21 dockstar3 kernel: [5.132864] rtc_hid_sensor_time HID-SENSOR-2000a0.0: rtc core: setting system clock to 2013-07-09 17:26:51:328000 UTC (1373390811) Jul 9 19:27:21 dockstar3 kernel: [5.146105] rtc_hid_sensor_time HID-SENSOR-2000a0.0: rtc core: registered hid-sensor-time as rtc0 Before the output was e.g. HID-SENSOR-2000a0 HID-SENSOR-2000a0.0: rtc core: registered hid-sensor-time as rtc0 instead of the above with the descriptive rtc_hid_sensor_time. Automatic loading of modules works too and it works on ARM, Intel and AMD as module or static linked. ;) Do you have tested the patches with a real device? I assume you have one. ;) Regards, Alexander Holler -- 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 6/6] [RFC] usb: gadget: USB_GADGET should depend on HAS_DMA
Hi Alan,
On Thu, Jul 11, 2013 at 5:51 PM, Alan Stern wrote:
> On Thu, 11 Jul 2013, Geert Uytterhoeven wrote:
>
>> If NO_DMA=y:
>>
>> drivers/built-in.o: In function `dma_set_coherent_mask':
>> include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
>> include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
>> drivers/built-in.o: In function `usb_gadget_unmap_request':
>> drivers/usb/gadget/udc-core.c:91: undefined reference to `dma_unmap_sg'
>> drivers/usb/gadget/udc-core.c:96: undefined reference to `dma_unmap_single'
>> drivers/built-in.o: In function `usb_gadget_map_request':
>> drivers/usb/gadget/udc-core.c:62: undefined reference to `dma_map_sg'
>> drivers/usb/gadget/udc-core.c:71: undefined reference to `dma_map_single'
>> drivers/usb/gadget/udc-core.c:74: undefined reference to `dma_mapping_error'
>>
>> Signed-off-by: Geert Uytterhoeven
>> ---
>> This one is very debatable: probably the parts using the DMA API should
>> be factored out, instead of disabling the whole USB gadget subsystem.
>
> Indeed. How does this look instead?
>
> Alan Stern
>
>
>
> Index: usb-3.10/drivers/usb/gadget/udc-core.c
> ===
> --- usb-3.10.orig/drivers/usb/gadget/udc-core.c
> +++ usb-3.10/drivers/usb/gadget/udc-core.c
> @@ -50,6 +50,8 @@ static DEFINE_MUTEX(udc_lock);
>
> /* -
> */
>
> +#ifdef CONFIG_HAS_DMA
> +
> int usb_gadget_map_request(struct usb_gadget *gadget,
> struct usb_request *req, int is_in)
> {
> @@ -99,6 +101,8 @@ void usb_gadget_unmap_request(struct usb
> }
> EXPORT_SYMBOL_GPL(usb_gadget_unmap_request);
>
> +#endif /* CONFIG_HAS_DMA */
> +
> /* -
> */
>
> void usb_gadget_set_state(struct usb_gadget *gadget,
> @@ -194,9 +198,11 @@ int usb_add_gadget_udc_release(struct de
> dev_set_name(>dev, "gadget");
> gadget->dev.parent = parent;
>
> +#ifdef CONFIG_HAS_DMA
> dma_set_coherent_mask(>dev, parent->coherent_dma_mask);
> gadget->dev.dma_parms = parent->dma_parms;
> gadget->dev.dma_mask = parent->dma_mask;
> +#endif
>
> if (release)
> gadget->dev.release = release;
Thanks, that works!
(after adding a few more dependencies on HAS_DMA for drivers that call
into usb_gadget_{,un}map_request() and/or dma_set_coherent_mask(),
for which I'll send separate patches).
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 5/8] cpufreq: Extract the handover of policy cpu to a helper function
On 12 July 2013 03:46, Srivatsa S. Bhat wrote: > During cpu offline, when the policy->cpu is going down, some other CPU > present in the policy->cpus mask is nominated as the new policy->cpu. > Extract this functionality from __cpufreq_remove_dev() and implement > it in a helper function. This helps in upcoming code reorganization. > > Signed-off-by: Srivatsa S. Bhat > --- > > drivers/cpufreq/cpufreq.c | 62 > - > 1 file changed, 38 insertions(+), 24 deletions(-) Acked-by: Viresh Kumar -- 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 1/2] ARM: dts: twl: Add GPADC data to device tree
GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.
Signed-off-by: Oleksandr Kozaruk
---
arch/arm/boot/dts/twl6030.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..434842c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};
+
+ gpadc: twl6030_gpadc {
+ compatible = "ti,twl6030_gpadc";
+ interrupts = <3>;
+ #io-channel-cells = <1>;
+ };
};
--
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/
[PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels are calibrated in 2 points, having offsets from ideal values kept in trim registers. This is used to correct measurements. The differences between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver exports function returning converted value for requested channels. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Signed-off-by: Balaji T K Graeme Gregory Signed-off-by: Oleksandr Kozaruk --- drivers/iio/adc/Kconfig |8 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1019 +++ 3 files changed, 1028 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index ab0767e6..87d699e 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -157,4 +157,12 @@ config VIPERBOARD_ADC Say yes here to access the ADC part of the Nano River Technologies Viperboard. +config TWL6030_GPADC + tristate "TWL6030 GPADC (General Purpose A/D Convertor) Support" + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030 General Purpose + A/D Convertor. + endmenu diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 0a825be..8b05633 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..6ceb789 --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,1019 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat + * Balaji T K + * Graeme Gregory + * Girish S Ghongdemath + * Ambresh K + * Oleksandr Kozaruk + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"twl6030_gpadc" + +#define TWL6030_GPADC_MAX_CHANNELS 17 +#define TWL6032_GPADC_MAX_CHANNELS 19 +/* Define this as the biggest of all chips using this driver */ +#define GPADC_MAX_CHANNELS TWL6032_GPADC_MAX_CHANNELS + +#define TWL6030_GPADC_CTRL 0x00/* 0x2e */ +#define TWL6030_GPADC_CTRL20x01/* 0x2f */ + +#define TWL6030_GPADC_CTRL_P1 0x05 +#define TWL6030_GPADC_CTRL_P2 0x06 + +#define TWL6032_GPADC_GPSELECT_ISB 0x07 +#define TWL6032_GPADC_CTRL_P1 0x08 + +#define TWL6032_GPADC_RTCH0_LSB0x09 +#define TWL6032_GPADC_RTCH0_MSB0x0a +#define TWL6032_GPADC_RTCH1_LSB0x0b +#define TWL6032_GPADC_RTCH1_MSB0x0c +#define TWL6032_GPADC_GPCH0_LSB0x0d +#define TWL6032_GPADC_GPCH0_MSB0x0e + +#define TWL6030_GPADC_CTRL_P1_SP1 BIT(3) +#define TWL6030_GPADC_CTRL_P1_EOCRTBIT(2) +#define TWL6030_GPADC_CTRL_P1_EOCP1BIT(1) +#define TWL6030_GPADC_CTRL_P1_BUSY BIT(0) + +#define TWL6030_GPADC_CTRL_P2_SP2 BIT(2) +#define TWL6030_GPADC_CTRL_P2_EOCP2BIT(1) +#define TWL6030_GPADC_CTRL_P1_BUSY BIT(0) + +#define TWL6030_GPADC_EOC_SW
[PATCH v3 0/2] TWL6030, TWL6032 GPADC driver
Hello, v3 - fixed compiler warning v2 - the driver put in drivers/iio, and converted using iio facilities as suggested by Graeme. TWL603[02] GPADC is used to measure battery voltage, battery temperature, battery presence ID, and could be used to measure twl603[02] die temperature. This is used on TI blaze, blaze tablet platforms. The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements, other channels measure voltage, (i.e. battery voltage), and have inbuilt voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels could be calibrated in 2 points, having offsets from ideal values in trim registers. The difference between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver exports function returning converted value for requested channels. Sysfs entries are added to start and read conversion result in millivolts for chosen channel. The driver is derived from git://git.omapzoom.org/kernel/omap.git The original driver's authors and contributors are Balaji T K, Graeme Gregory, Ambresh K, Girish S Ghongdemath. The changes to the original driver: - device tree adaptation; - drop ioctl support - never been used; - unified measurement method for both devices; - get rid of "if (device == X)" code style to data driven; - drop polling end of conversion and use interrupt instead; - iio framework is used Tested with on blaze tablet 2 with OMAP4430(twl6030), and OMAP4470(twl6032) SOMs. The patches were tested against 3.10-rc7 Oleksandr Kozaruk (2): ARM: dts: twl: Add GPADC data to device tree iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver arch/arm/boot/dts/twl6030.dtsi |6 + drivers/iio/adc/Kconfig |8 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1019 +++ 4 files changed, 1034 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c -- 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/
Re: [PATCH 1/8] cpufreq: Revert commit a66b2e to fix cpufreq regression during suspend/resume
On 12 July 2013 03:45, Srivatsa S. Bhat wrote: > commit a66b2e (cpufreq: Preserve sysfs files across suspend/resume) has > unfortunately caused several things in the cpufreq subsystem to break subtly > after a suspend/resume cycle. > > The intention of that patch was to retain the file permissions of the > cpufreq related sysfs files across suspend/resume. To achieve that, the commit > completely removed the calls to cpufreq_add_dev() and __cpufreq_remove_dev() > during suspend/resume transitions. But the problem is that those functions > do 2 kinds of things: > 1. Low-level initialization/tear-down that are critical to the correct > functioning of cpufreq-core. > 2. Kobject and sysfs related initialization/teardown. > > Ideally we should have reorganized the code to cleanly separate these two > responsibilities, and skipped only the sysfs related parts during > suspend/resume. Since we skipped the entire callbacks instead (which also > included some CPU and cpufreq-specific critical components), cpufreq > subsystem started behaving erratically after suspend/resume. > > So revert the commit to fix the regression. We'll revisit and address the > original goal of that commit separately, since it involves quite a bit of > careful code reorganization and appears to be non-trivial. > > (While reverting the commit, note that another commit f51e1eb "cpufreq: > Fix cpufreq regression after suspend/resume" already reverted part of the > original set of changes. So revert only the remaining ones). > > Cc: sta...@vger.kernel.org > Signed-off-by: Srivatsa S. Bhat > --- > > drivers/cpufreq/cpufreq.c |4 +++- > drivers/cpufreq/cpufreq_stats.c |6 ++ > 2 files changed, 5 insertions(+), 5 deletions(-) Acked-by: Viresh Kumar -- 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 4/8] cpufreq: Extract non-interface related stuff from cpufreq_add_dev_interface
On 12 July 2013 03:46, Srivatsa S. Bhat wrote: > cpufreq_add_dev_interface() includes the work of exposing the interface > to the device, as well as a lot of unrelated stuff. Move the latter to > cpufreq_add_dev(), where it is more appropriate. > > Signed-off-by: Srivatsa S. Bhat > --- > > drivers/cpufreq/cpufreq.c | 43 ++- > 1 file changed, 26 insertions(+), 17 deletions(-) Acked-by: Viresh Kumar -- 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] ic7xxx_osm: use kzalloc instead of kmalloc + memset
found using coccinelle.
Signed-off-by: Cosmin Stanescu
---
drivers/scsi/aic7xxx/aic7xxx_osm.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm.c
b/drivers/scsi/aic7xxx/aic7xxx_osm.c
index c0c6258..7167cfe 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_osm.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_osm.c
@@ -1223,10 +1223,9 @@ ahc_platform_alloc(struct ahc_softc *ahc, void
*platform_arg)
{
ahc->platform_data =
- kmalloc(sizeof(struct ahc_platform_data), GFP_ATOMIC);
+ kzalloc(sizeof(struct ahc_platform_data), GFP_ATOMIC);
if (ahc->platform_data == NULL)
return (ENOMEM);
- memset(ahc->platform_data, 0, sizeof(struct ahc_platform_data));
ahc->platform_data->irq = AHC_LINUX_NOIRQ;
ahc_lockinit(ahc);
ahc->seltime = (aic7xxx_seltime & 0x3) << 4;
--
1.7.10.4
--
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/8] cpufreq: Add helper to perform alloc/free of policy structure
On 12 July 2013 03:46, Srivatsa S. Bhat
wrote:
> Separate out the allocation of the cpufreq policy structure (along with
> its error handling) to a helper function. This makes the code easier to
> read and also helps with some upcoming code reorganization.
>
> Signed-off-by: Srivatsa S. Bhat
> ---
>
> drivers/cpufreq/cpufreq.c | 50
> -
> 1 file changed, 35 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index f8c3100..ca14dc2 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -943,6 +943,37 @@ static int cpufreq_add_policy_cpu(unsigned int cpu,
> unsigned int sibling,
> }
> #endif
>
> +static struct cpufreq_policy *cpufreq_policy_alloc(void)
> +{
> + struct cpufreq_policy *policy;
> +
> + policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
sizeof(*policy) ??
Acked-by: Viresh Kumar
--
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] [SCSI] lpfc 8.3.40: Remove useless cast
Found using coccinelle tool. Signed-off-by: Vladimir Cernov --- drivers/scsi/lpfc/lpfc_init.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index e0b20fa..b7621f6 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -4721,8 +4721,7 @@ lpfc_sli_driver_resource_setup(struct lpfc_hba *phba) } if (!phba->sli.ring) - phba->sli.ring = (struct lpfc_sli_ring *) - kzalloc(LPFC_SLI3_MAX_RING * + phba->sli.ring = kzalloc(LPFC_SLI3_MAX_RING * sizeof(struct lpfc_sli_ring), GFP_KERNEL); if (!phba->sli.ring) return -ENOMEM; -- 1.7.10.4 -- 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: zsmalloc: access page->private by using page_private macro
Signed-off-by: Sunghan Suh --- drivers/staging/zsmalloc/zsmalloc-main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c b/drivers/staging/zsmalloc/zsmalloc-main.c index 4bb275b..1a67537 100644 --- a/drivers/staging/zsmalloc/zsmalloc-main.c +++ b/drivers/staging/zsmalloc/zsmalloc-main.c @@ -423,7 +423,7 @@ static struct page *get_next_page(struct page *page) if (is_last_page(page)) next = NULL; else if (is_first_page(page)) - next = (struct page *)page->private; + next = (struct page *)page_private(page); else next = list_entry(page->lru.next, struct page, lru); @@ -581,7 +581,7 @@ static struct page *alloc_zspage(struct size_class *class, gfp_t flags) first_page->inuse = 0; } if (i == 1) - first_page->private = (unsigned long)page; + set_page_private(first_page, (unsigned long)page); if (i >= 1) page->first_page = first_page; if (i >= 2) -- 1.8.1.2 -- 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/8] cpufreq: Fix misplaced call to cpufreq_update_policy()
On 12 July 2013 03:45, Srivatsa S. Bhat wrote: > The call to cpufreq_update_policy() is placed in the CPU hotplug callback > of cpufreq_stats, which has a higher priority than the CPU hotplug callback > of cpufreq-core. As a result, during CPU_ONLINE/CPU_ONLINE_FROZEN, we end up > calling cpufreq_update_policy() *before* calling cpufreq_add_dev() ! > And for uninitialized CPUs, it just returns silently, not doing anything. Hmm.. > To add to it, cpufreq_stats is not even the right place to call > cpufreq_update_policy() to begin with. The cpufreq core ought to handle > this in its own callback, from an elegance/relevance perspective. > > So move the invocation of cpufreq_update_policy() to cpufreq_cpu_callback, > and place it *after* cpufreq_add_dev(). > > Signed-off-by: Srivatsa S. Bhat > --- > > drivers/cpufreq/cpufreq.c |1 + > drivers/cpufreq/cpufreq_stats.c |6 -- > 2 files changed, 1 insertion(+), 6 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index ccc6eab..f8c3100 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -1943,6 +1943,7 @@ static int __cpuinit cpufreq_cpu_callback(struct > notifier_block *nfb, > case CPU_ONLINE: > case CPU_ONLINE_FROZEN: > cpufreq_add_dev(dev, NULL); > + cpufreq_update_policy(cpu); Do we need to call this for every hotplug of cpu? I am not talking about suspend/resume here. -- 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/lustre/libcfs: replaced string duplication code with kstrdup
Modified cfs_strdup function to use kstrdup instead of duplicating its
implementation.
Found using Coccinelle.
Signed-off-by: Dragos Foianu
---
drivers/staging/lustre/lustre/libcfs/libcfs_string.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
b/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
index 9edccc9..4dba304 100644
--- a/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
+++ b/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
@@ -135,18 +135,7 @@ EXPORT_SYMBOL(cfs_str2mask);
/* Duplicate a string in a platform-independent way */
char *cfs_strdup(const char *str, u_int32_t flags)
{
- size_t lenz; /* length of str + zero byte */
- char *dup_str;
-
- lenz = strlen(str) + 1;
-
- dup_str = kmalloc(lenz, flags);
- if (dup_str == NULL)
- return NULL;
-
- memcpy(dup_str, str, lenz);
-
- return dup_str;
+ return kstrdup(str, flags);
}
EXPORT_SYMBOL(cfs_strdup);
--
1.7.10.4
--
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: silicom: Remove useless unneeded semicolons
From: Vladimir Found using coccinelle tool. Signed-off-by: Vladimir Cernov --- drivers/staging/silicom/bpctl_mod.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/staging/silicom/bpctl_mod.c b/drivers/staging/silicom/bpctl_mod.c index 48b9fb1..42d6d27 100644 --- a/drivers/staging/silicom/bpctl_mod.c +++ b/drivers/staging/silicom/bpctl_mod.c @@ -1809,7 +1809,7 @@ int cmnd_off(bpctl_dev_t *pbpctl_dev) else data_pulse(pbpctl_dev, CMND_OFF); ret = 0; - }; + } return ret; } @@ -1830,7 +1830,7 @@ int bypass_on(bpctl_dev_t *pbpctl_dev) } else data_pulse(pbpctl_dev, BYPASS_ON); ret = 0; - }; + } return ret; } @@ -1866,7 +1866,7 @@ int tap_off(bpctl_dev_t *pbpctl_dev) write_data(pbpctl_dev, TAP_OFF); msec_delay_bp(LATCH_DELAY); ret = 0; - }; + } return ret; } @@ -1879,7 +1879,7 @@ int tap_on(bpctl_dev_t *pbpctl_dev) write_data(pbpctl_dev, TAP_ON); msec_delay_bp(LATCH_DELAY); ret = 0; - }; + } return ret; } @@ -2025,7 +2025,7 @@ int wdt_off(bpctl_dev_t *pbpctl_dev) data_pulse(pbpctl_dev, WDT_OFF); pbpctl_dev->wdt_status = WDT_STATUS_DIS; ret = 0; - }; + } return ret; } @@ -2568,7 +2568,7 @@ int reset_cont(bpctl_dev_t *pbpctl_dev) else data_pulse(pbpctl_dev, RESET_CONT); ret = 0; - }; + } return ret; } @@ -3497,7 +3497,7 @@ int wdt_programmed(bpctl_dev_t *pbpctl_dev, int *timeout) *timeout = curr_wdt_status == 0 ? 0 : pbpctl_dev->bypass_timer_interval; - }; + } } else ret = BP_NOT_CAP; return ret; @@ -3548,7 +3548,7 @@ int normal_support(bpctl_dev_t *pbpctl_dev) NORMAL_UNSUPPORT_MASK) ? 0 : 1); } else ret = 1; - }; + } return ret; } @@ -5111,7 +5111,7 @@ int set_bypass_tpl_auto(bpctl_dev_t *pbpctl_dev, unsigned int param) pbpctl_dev->bp_tpl_flag = param; mod_timer(_dev->bp_tpl_timer, jiffies + 1); return BP_OK; - }; + } if ((!param) && (pbpctl_dev->bp_tpl_flag)) remove_bypass_tpl_auto(pbpctl_dev); -- 1.7.10.4 -- 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] usb: phy: samsung-usb2: Toggle HSIC GPIO from device tree
Hi, On Wed, Jul 10, 2013 at 10:42:27AM -0700, Julius Werner wrote: > Hi Felipe, > > This is intended to pull down a reset signal line, not to switch power > to the device. I could implement that with the regulator framework > too, but I think that would just be confusing and harder to understand > without providing any benefit. It's really just a plain old GPIO. alright, in that case how about using drivers/reset/ ? -- balbi signature.asc Description: Digital signature
Re: 3.10.0: Full dynticks = high load
On 11.07.2013, Dâniel Fraga wrote: > I upgraded to kernel 3.10.0 and decided to try the new "Full > dynticks system (tickless)" option, but now the system load is always > at 1 or above. > > Using the previous "Idle dynticks system (tickless idle)" solves > the problem, so it seems the new Full dynticks code is causing this. > This describes exactly what I have encountered, and "tickless idle" fixed it for me, too. So I'll second 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 v3 0/6] ARM: davinci: da850: add ethernet driver DT support
On 7/11/2013 10:42 PM, Prabhakar Lad wrote: > Hi Sekhar, > > On Sun, Jun 23, 2013 at 8:30 PM, Prabhakar Lad > wrote: >> From: "Lad, Prabhakar" >> >> This patch set enables Ethernet support through device tree model. >> This patch set enables mii interface only and is being tested to boot via >> rootfs. The rmii phy is present on the i2c gpio expander chip (UI board) >> for which yet support needs to be added, once the DT support for the chip >> is enabled, enabling rmii will be subsequnet patch. >> >> Changes for v2: >> 1: Enabled mdio device. >> 2: Fixed clock lookup. >> >> Changes for v3: >> 1: Fixed review comments pointed out by Sekhar. >> >> Lad, Prabhakar (6): >> ARM: davinci: da8xx: fix clock lookup for mdio device >> ARM: davinci: da850: add DT node for mdio device >> ARM: davinci: da850: add OF_DEV_AUXDATA entry for mdio. >> ARM: davinci: da850: add DT node for eth0. >> ARM: davinci: da850: add OF_DEV_AUXDATA entry for eth0. >> ARM: davinci: da850: configure system configuration chip(CFGCHIP3) >> for emac >> > gentle ping.. I haven't been able to get to reviewing patches meant for v3.12 yet. Most probably will happen next week. Thanks, Sekhar -- 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] fnic: use simple_open instead of fnic_trace_ctrl_open
This removes the open coded fnic_trace_ctrl_open() function
and replaces file operations references to the function
with simple_open() instead.
Found using coccinelle.
Signed-off-by: Camelia Groza
---
drivers/scsi/fnic/fnic_debugfs.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/scsi/fnic/fnic_debugfs.c b/drivers/scsi/fnic/fnic_debugfs.c
index cbcb012..ddc7e94 100644
--- a/drivers/scsi/fnic/fnic_debugfs.c
+++ b/drivers/scsi/fnic/fnic_debugfs.c
@@ -25,23 +25,6 @@ static struct dentry *fnic_trace_debugfs_file;
static struct dentry *fnic_trace_enable;
/*
- * fnic_trace_ctrl_open - Open the trace_enable file
- * @inode: The inode pointer.
- * @file: The file pointer to attach the trace enable/disable flag.
- *
- * Description:
- * This routine opens a debugsfs file trace_enable.
- *
- * Returns:
- * This function returns zero if successful.
- */
-static int fnic_trace_ctrl_open(struct inode *inode, struct file *filp)
-{
- filp->private_data = inode->i_private;
- return 0;
-}
-
-/*
* fnic_trace_ctrl_read - Read a trace_enable debugfs file
* @filp: The file pointer to read from.
* @ubuf: The buffer to copy the data to.
@@ -222,7 +205,7 @@ static int fnic_trace_debugfs_release(struct inode *inode,
static const struct file_operations fnic_trace_ctrl_fops = {
.owner = THIS_MODULE,
- .open = fnic_trace_ctrl_open,
+ .open = simple_open,
.read = fnic_trace_ctrl_read,
.write = fnic_trace_ctrl_write,
};
--
1.7.10.4
--
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 -v2 1/3] PCI: introduce PCIe Device Serial Number Capability support
On 07/11/2013 09:38 PM, Yijing Wang wrote:
Hi Don,
Thanks for your review and comments very much!
+dev->sn = pci_device_serial_number(dev);
+
Finally, 'the comment below':
I know you were following Bjorn's suggestion, which I thought
was an improvement, but why not do above assignment in
pci_device_serial_number() ?
I don't do assignment in pci_device_serial_number() because
pci_device_serial_number()
is an EXPORT_SYMBOL, and will be used to get dsn for non-scaned device, for
example:
1. we have pcie device in slot before suspend.
2. we removed the device during suspend.
3. we reinserted a new device during suspend.
4. we should check the device change during resume, so we
try to use pcie device serial number to identify changes.
But the pci_dev structure maybe the old stale data. So
I prefer to get dsn by return.
what about this:
static void pci_init_capabilities(struct pci_dev *dev)
pci_dsn_init(dev);
..
void pci_dsn_init(dev)
{
dev->sn = pci_device_serial_number(dev);
}
Looks good! I think that meets all the uses (use in init, post-suspend).
- Don
See above
- Don
/* Vital Product Data */
pci_vpd_pci22_init(dev);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 0fd1f15..10d190b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -342,6 +342,7 @@ struct pci_dev {
struct list_head msi_list;
struct kset *msi_kset;
#endif
+u64 sn;/* device serieal number, 0 if not support */
struct pci_vpd *vpd;
#ifdef CONFIG_PCI_ATS
union {
@@ -995,6 +996,8 @@ ssize_t pci_read_vpd(struct pci_dev *dev, loff_t pos,
size_t count, void *buf);
ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const
void *buf);
int pci_vpd_truncate(struct pci_dev *dev, size_t size);
+u64 pci_device_serial_number(struct pci_dev *dev);
+
/* Helper functions for low-level code (drivers/pci/setup-[bus,res].c) */
resource_size_t pcibios_retrieve_fw_addr(struct pci_dev *dev, int idx);
void pci_bus_assign_resources(const struct pci_bus *bus);
.
--
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 V5 09/12] perf: make events stream always parsable
On 11/07/13 18:43, David Ahern wrote: > On 7/11/13 7:12 AM, Adrian Hunter wrote: >> The event stream is not always parsable because the format of a sample >> is dependent on the sample_type of the selected event. When there >> is more than one selected event and the sample_types are not the >> same then parsing becomes problematic. A sample can be matched to its >> selected event using the ID that is allocated when the event is opened. >> Unfortunately, to get the ID from the sample means first parsing it. > > Here's an alternative suggestion -- one that does not involve changing the > kernel API or requiring a common denominator in sample_type options. The kernel API is designed to be extensible. Extending it in a way that is perhaps unexpected but nevertheless backward compatible, is an appropriate solution. > > perf handles event streams through an mmap which can be directly tied to an > evsel (a single event) when the mmap is created. ie., when events are read > we know exactly which evsel they correspond to. (See > perf_evlist__mmap_per_cpu and perf_evlist__mmap_per_thread and add struct > perf_evsel *evsel entry to struct perf_mmap). > > Commands like perf-record can inject a user event into the stream and hence > the data file every time the evsel changes while walking all of the mmap's > reading events -- very similar to the way finished round is done. The event > would only contain a perf_event_header which is 8 bytes so this does not add > a lot to a data file. As an optimization the evsel event could only be > injected if the sample_types differ. > > Live commands would just use the evsel connected to the mmap -- no lookups > needed which would simplify things a bit processing the events. > > In short, the information to associate event streams to an event (evsel) is > currently available -- it's just being discarded in the many layers. > > I'll try to whip up some code that implements this in the next few days. > > 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: [GIT PULL REQUEST] watchdog - v3.11-rc1
Hi Wim, On Thu, 11 Jul 2013 22:34:24 +0200 Wim Van Sebroeck wrote: > > Please pull from 'master' branch of > git://www.linux-watchdog.org/linux-watchdog.git This was all rebased in the last day from what has been in linux-next for some time. All the patches are the same, so the rebase achieved nothing positive at all. Please don't do this (see I am still much nicer than Linus :-)). Just submit what you have in linux-next which has already been tested (presumably) and Linus can fix up any conflicts (in this case there were nothing significant anyway). Also, you might like to consider using "git request-pull" to generate a starting place for your pull request rather than sending all the commit messages and the diff in line. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpSalTUnt4jX.pgp Description: PGP signature
Re: [PATCH] PM: avoid 'autosleep' in shutdown progress
On Thu, 2013-07-11 at 16:03 +0800, shuox@intel.com wrote:
> From: Liu ShuoX
>
> In shutdown progress, system is possible to do power transition
> (such as suspend-to-ram) in parallel. It is unreasonable. So,
> fixes it by adding a system_state checking and queue try_to_suspend
> again when system status is not running.
>
> Signed-off-by: Liu ShuoX
> ---
> kernel/power/autosleep.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
Without this patch, we hit an hang issue on Android.
Scenario:
Kernel starts shutdown and calls all device driver's shutdown callback.
When a driver's shutdown is called, the last wakelock is released and
suspend-to-ram starts. However, as some driver's shut down callbacks
already shut down devices and disable runtime pm, the suspend-to-ram
calls driver's suspend callback without noticing that device is already
off and causes crash.
We know the drivers should be fixed, but can we also change generic
codes a little to make it stronger?
> diff --git a/kernel/power/autosleep.c b/kernel/power/autosleep.c
> index c6422ff..9012ecf 100644
> --- a/kernel/power/autosleep.c
> +++ b/kernel/power/autosleep.c
> @@ -32,7 +32,8 @@ static void try_to_suspend(struct work_struct *work)
>
> mutex_lock(_lock);
>
> - if (!pm_save_wakeup_count(initial_count)) {
> + if (!pm_save_wakeup_count(initial_count) ||
> + system_state != SYSTEM_RUNNING) {
> mutex_unlock(_lock);
> goto out;
> }
--
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] MIPS: loongson2: cpufreq: fix broken cpufreq
On Fri, Jul 12, 2013 at 1:04 AM, Aaro Koskinen wrote: > Commit 42913c799 (MIPS: Loongson2: Use clk API instead of direct > dereferences) broke the cpufreq functionality on Loongson2 boards: > clk_set_rate() is called before the CPU frequency table is initialized, > and therefore will always fail. > > Fix by moving the clk_set_rate() after the table initialization. > Tested on Lemote FuLoong mini-PC. > > Signed-off-by: Aaro Koskinen > Cc: sta...@vger.kernel.org > --- > drivers/cpufreq/loongson2_cpufreq.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) Ackec-by: Viresh Kumar -- 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] virtio-net: put virtio net header inline with data
"Michael S. Tsirkin" writes: > On Tue, Jul 09, 2013 at 11:46:23AM +0930, Rusty Russell wrote: >> "Michael S. Tsirkin" writes: >> > For small packets we can simplify xmit processing >> > by linearizing buffers with the header: >> > most packets seem to have enough head room >> > we can use for this purpose. >> > Since existing hypervisors require that header >> > is the first s/g element, we need a feature bit >> > for this. >> > >> > Signed-off-by: Michael S. Tsirkin >> > --- >> > >> > Note: this needs to be applied on top of patch >> > defining VIRTIO_F_ANY_LAYOUT - bit to be >> > selected by Rusty. >> > >> > The following patch should work for any definition of >> > VIRTIO_F_ANY_LAYOUT - I used bit 31 for testing. >> > Rusty, could you please pick a valid bit for VIRTIO_F_ANY_LAYOUT >> > and squeeze this patch into 3.11? >> >> Sorry, it's too late. >> >> First, I've been a bit lax in sending patches via DaveM, and this is >> definitely his territory (ie. more net than virtio). >> >> Secondly, it needs baking and testing time. >> >> Cheers, >> Rusty. > > Okay. But we can already commit the qemu change, right? > Also, can you submit the spec update please? The spec has been updated, BTW. Cheers, Rusty. -- 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] virtio-net: put virtio net header inline with data
Michael S. Tsirkin m...@redhat.com writes: On Tue, Jul 09, 2013 at 11:46:23AM +0930, Rusty Russell wrote: Michael S. Tsirkin m...@redhat.com writes: For small packets we can simplify xmit processing by linearizing buffers with the header: most packets seem to have enough head room we can use for this purpose. Since existing hypervisors require that header is the first s/g element, we need a feature bit for this. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- Note: this needs to be applied on top of patch defining VIRTIO_F_ANY_LAYOUT - bit to be selected by Rusty. The following patch should work for any definition of VIRTIO_F_ANY_LAYOUT - I used bit 31 for testing. Rusty, could you please pick a valid bit for VIRTIO_F_ANY_LAYOUT and squeeze this patch into 3.11? Sorry, it's too late. First, I've been a bit lax in sending patches via DaveM, and this is definitely his territory (ie. more net than virtio). Secondly, it needs baking and testing time. Cheers, Rusty. Okay. But we can already commit the qemu change, right? Also, can you submit the spec update please? The spec has been updated, BTW. Cheers, Rusty. -- 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] MIPS: loongson2: cpufreq: fix broken cpufreq
On Fri, Jul 12, 2013 at 1:04 AM, Aaro Koskinen aaro.koski...@iki.fi wrote: Commit 42913c799 (MIPS: Loongson2: Use clk API instead of direct dereferences) broke the cpufreq functionality on Loongson2 boards: clk_set_rate() is called before the CPU frequency table is initialized, and therefore will always fail. Fix by moving the clk_set_rate() after the table initialization. Tested on Lemote FuLoong mini-PC. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: sta...@vger.kernel.org --- drivers/cpufreq/loongson2_cpufreq.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) Ackec-by: Viresh Kumar viresh.ku...@linaro.org -- 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] PM: avoid 'autosleep' in shutdown progress
On Thu, 2013-07-11 at 16:03 +0800, shuox@intel.com wrote:
From: Liu ShuoX shuox@intel.com
In shutdown progress, system is possible to do power transition
(such as suspend-to-ram) in parallel. It is unreasonable. So,
fixes it by adding a system_state checking and queue try_to_suspend
again when system status is not running.
Signed-off-by: Liu ShuoX shuox@intel.com
---
kernel/power/autosleep.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
Without this patch, we hit an hang issue on Android.
Scenario:
Kernel starts shutdown and calls all device driver's shutdown callback.
When a driver's shutdown is called, the last wakelock is released and
suspend-to-ram starts. However, as some driver's shut down callbacks
already shut down devices and disable runtime pm, the suspend-to-ram
calls driver's suspend callback without noticing that device is already
off and causes crash.
We know the drivers should be fixed, but can we also change generic
codes a little to make it stronger?
diff --git a/kernel/power/autosleep.c b/kernel/power/autosleep.c
index c6422ff..9012ecf 100644
--- a/kernel/power/autosleep.c
+++ b/kernel/power/autosleep.c
@@ -32,7 +32,8 @@ static void try_to_suspend(struct work_struct *work)
mutex_lock(autosleep_lock);
- if (!pm_save_wakeup_count(initial_count)) {
+ if (!pm_save_wakeup_count(initial_count) ||
+ system_state != SYSTEM_RUNNING) {
mutex_unlock(autosleep_lock);
goto out;
}
--
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: [GIT PULL REQUEST] watchdog - v3.11-rc1
Hi Wim, On Thu, 11 Jul 2013 22:34:24 +0200 Wim Van Sebroeck w...@iguana.be wrote: Please pull from 'master' branch of git://www.linux-watchdog.org/linux-watchdog.git This was all rebased in the last day from what has been in linux-next for some time. All the patches are the same, so the rebase achieved nothing positive at all. Please don't do this (see I am still much nicer than Linus :-)). Just submit what you have in linux-next which has already been tested (presumably) and Linus can fix up any conflicts (in this case there were nothing significant anyway). Also, you might like to consider using git request-pull to generate a starting place for your pull request rather than sending all the commit messages and the diff in line. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpSalTUnt4jX.pgp Description: PGP signature
Re: [PATCH V5 09/12] perf: make events stream always parsable
On 11/07/13 18:43, David Ahern wrote: On 7/11/13 7:12 AM, Adrian Hunter wrote: The event stream is not always parsable because the format of a sample is dependent on the sample_type of the selected event. When there is more than one selected event and the sample_types are not the same then parsing becomes problematic. A sample can be matched to its selected event using the ID that is allocated when the event is opened. Unfortunately, to get the ID from the sample means first parsing it. Here's an alternative suggestion -- one that does not involve changing the kernel API or requiring a common denominator in sample_type options. The kernel API is designed to be extensible. Extending it in a way that is perhaps unexpected but nevertheless backward compatible, is an appropriate solution. perf handles event streams through an mmap which can be directly tied to an evsel (a single event) when the mmap is created. ie., when events are read we know exactly which evsel they correspond to. (See perf_evlist__mmap_per_cpu and perf_evlist__mmap_per_thread and add struct perf_evsel *evsel entry to struct perf_mmap). Commands like perf-record can inject a user event into the stream and hence the data file every time the evsel changes while walking all of the mmap's reading events -- very similar to the way finished round is done. The event would only contain a perf_event_header which is 8 bytes so this does not add a lot to a data file. As an optimization the evsel event could only be injected if the sample_types differ. Live commands would just use the evsel connected to the mmap -- no lookups needed which would simplify things a bit processing the events. In short, the information to associate event streams to an event (evsel) is currently available -- it's just being discarded in the many layers. I'll try to whip up some code that implements this in the next few days. 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 -v2 1/3] PCI: introduce PCIe Device Serial Number Capability support
On 07/11/2013 09:38 PM, Yijing Wang wrote:
Hi Don,
Thanks for your review and comments very much!
+dev-sn = pci_device_serial_number(dev);
+
Finally, 'the comment below':
I know you were following Bjorn's suggestion, which I thought
was an improvement, but why not do above assignment in
pci_device_serial_number() ?
I don't do assignment in pci_device_serial_number() because
pci_device_serial_number()
is an EXPORT_SYMBOL, and will be used to get dsn for non-scaned device, for
example:
1. we have pcie device in slot before suspend.
2. we removed the device during suspend.
3. we reinserted a new device during suspend.
4. we should check the device change during resume, so we
try to use pcie device serial number to identify changes.
But the pci_dev structure maybe the old stale data. So
I prefer to get dsn by return.
what about this:
static void pci_init_capabilities(struct pci_dev *dev)
pci_dsn_init(dev);
..
void pci_dsn_init(dev)
{
dev-sn = pci_device_serial_number(dev);
}
Looks good! I think that meets all the uses (use in init, post-suspend).
- Don
See above
- Don
/* Vital Product Data */
pci_vpd_pci22_init(dev);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 0fd1f15..10d190b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -342,6 +342,7 @@ struct pci_dev {
struct list_head msi_list;
struct kset *msi_kset;
#endif
+u64 sn;/* device serieal number, 0 if not support */
struct pci_vpd *vpd;
#ifdef CONFIG_PCI_ATS
union {
@@ -995,6 +996,8 @@ ssize_t pci_read_vpd(struct pci_dev *dev, loff_t pos,
size_t count, void *buf);
ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const
void *buf);
int pci_vpd_truncate(struct pci_dev *dev, size_t size);
+u64 pci_device_serial_number(struct pci_dev *dev);
+
/* Helper functions for low-level code (drivers/pci/setup-[bus,res].c) */
resource_size_t pcibios_retrieve_fw_addr(struct pci_dev *dev, int idx);
void pci_bus_assign_resources(const struct pci_bus *bus);
.
--
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] fnic: use simple_open instead of fnic_trace_ctrl_open
This removes the open coded fnic_trace_ctrl_open() function
and replaces file operations references to the function
with simple_open() instead.
Found using coccinelle.
Signed-off-by: Camelia Groza camelia.gr...@gmail.com
---
drivers/scsi/fnic/fnic_debugfs.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/scsi/fnic/fnic_debugfs.c b/drivers/scsi/fnic/fnic_debugfs.c
index cbcb012..ddc7e94 100644
--- a/drivers/scsi/fnic/fnic_debugfs.c
+++ b/drivers/scsi/fnic/fnic_debugfs.c
@@ -25,23 +25,6 @@ static struct dentry *fnic_trace_debugfs_file;
static struct dentry *fnic_trace_enable;
/*
- * fnic_trace_ctrl_open - Open the trace_enable file
- * @inode: The inode pointer.
- * @file: The file pointer to attach the trace enable/disable flag.
- *
- * Description:
- * This routine opens a debugsfs file trace_enable.
- *
- * Returns:
- * This function returns zero if successful.
- */
-static int fnic_trace_ctrl_open(struct inode *inode, struct file *filp)
-{
- filp-private_data = inode-i_private;
- return 0;
-}
-
-/*
* fnic_trace_ctrl_read - Read a trace_enable debugfs file
* @filp: The file pointer to read from.
* @ubuf: The buffer to copy the data to.
@@ -222,7 +205,7 @@ static int fnic_trace_debugfs_release(struct inode *inode,
static const struct file_operations fnic_trace_ctrl_fops = {
.owner = THIS_MODULE,
- .open = fnic_trace_ctrl_open,
+ .open = simple_open,
.read = fnic_trace_ctrl_read,
.write = fnic_trace_ctrl_write,
};
--
1.7.10.4
--
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 0/6] ARM: davinci: da850: add ethernet driver DT support
On 7/11/2013 10:42 PM, Prabhakar Lad wrote: Hi Sekhar, On Sun, Jun 23, 2013 at 8:30 PM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch set enables Ethernet support through device tree model. This patch set enables mii interface only and is being tested to boot via rootfs. The rmii phy is present on the i2c gpio expander chip (UI board) for which yet support needs to be added, once the DT support for the chip is enabled, enabling rmii will be subsequnet patch. Changes for v2: 1: Enabled mdio device. 2: Fixed clock lookup. Changes for v3: 1: Fixed review comments pointed out by Sekhar. Lad, Prabhakar (6): ARM: davinci: da8xx: fix clock lookup for mdio device ARM: davinci: da850: add DT node for mdio device ARM: davinci: da850: add OF_DEV_AUXDATA entry for mdio. ARM: davinci: da850: add DT node for eth0. ARM: davinci: da850: add OF_DEV_AUXDATA entry for eth0. ARM: davinci: da850: configure system configuration chip(CFGCHIP3) for emac gentle ping.. I haven't been able to get to reviewing patches meant for v3.12 yet. Most probably will happen next week. Thanks, Sekhar -- 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.10.0: Full dynticks = high load
On 11.07.2013, Dâniel Fraga wrote: I upgraded to kernel 3.10.0 and decided to try the new Full dynticks system (tickless) option, but now the system load is always at 1 or above. Using the previous Idle dynticks system (tickless idle) solves the problem, so it seems the new Full dynticks code is causing this. This describes exactly what I have encountered, and tickless idle fixed it for me, too. So I'll second 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] usb: phy: samsung-usb2: Toggle HSIC GPIO from device tree
Hi, On Wed, Jul 10, 2013 at 10:42:27AM -0700, Julius Werner wrote: Hi Felipe, This is intended to pull down a reset signal line, not to switch power to the device. I could implement that with the regulator framework too, but I think that would just be confusing and harder to understand without providing any benefit. It's really just a plain old GPIO. alright, in that case how about using drivers/reset/ ? -- balbi signature.asc Description: Digital signature
[PATCH] Staging: silicom: Remove useless unneeded semicolons
From: Vladimir gg.kasper...@gmail.com Found using coccinelle tool. Signed-off-by: Vladimir Cernov gg.kasper...@gmail.com --- drivers/staging/silicom/bpctl_mod.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/staging/silicom/bpctl_mod.c b/drivers/staging/silicom/bpctl_mod.c index 48b9fb1..42d6d27 100644 --- a/drivers/staging/silicom/bpctl_mod.c +++ b/drivers/staging/silicom/bpctl_mod.c @@ -1809,7 +1809,7 @@ int cmnd_off(bpctl_dev_t *pbpctl_dev) else data_pulse(pbpctl_dev, CMND_OFF); ret = 0; - }; + } return ret; } @@ -1830,7 +1830,7 @@ int bypass_on(bpctl_dev_t *pbpctl_dev) } else data_pulse(pbpctl_dev, BYPASS_ON); ret = 0; - }; + } return ret; } @@ -1866,7 +1866,7 @@ int tap_off(bpctl_dev_t *pbpctl_dev) write_data(pbpctl_dev, TAP_OFF); msec_delay_bp(LATCH_DELAY); ret = 0; - }; + } return ret; } @@ -1879,7 +1879,7 @@ int tap_on(bpctl_dev_t *pbpctl_dev) write_data(pbpctl_dev, TAP_ON); msec_delay_bp(LATCH_DELAY); ret = 0; - }; + } return ret; } @@ -2025,7 +2025,7 @@ int wdt_off(bpctl_dev_t *pbpctl_dev) data_pulse(pbpctl_dev, WDT_OFF); pbpctl_dev-wdt_status = WDT_STATUS_DIS; ret = 0; - }; + } return ret; } @@ -2568,7 +2568,7 @@ int reset_cont(bpctl_dev_t *pbpctl_dev) else data_pulse(pbpctl_dev, RESET_CONT); ret = 0; - }; + } return ret; } @@ -3497,7 +3497,7 @@ int wdt_programmed(bpctl_dev_t *pbpctl_dev, int *timeout) *timeout = curr_wdt_status == 0 ? 0 : pbpctl_dev-bypass_timer_interval; - }; + } } else ret = BP_NOT_CAP; return ret; @@ -3548,7 +3548,7 @@ int normal_support(bpctl_dev_t *pbpctl_dev) NORMAL_UNSUPPORT_MASK) ? 0 : 1); } else ret = 1; - }; + } return ret; } @@ -5111,7 +5111,7 @@ int set_bypass_tpl_auto(bpctl_dev_t *pbpctl_dev, unsigned int param) pbpctl_dev-bp_tpl_flag = param; mod_timer(pbpctl_dev-bp_tpl_timer, jiffies + 1); return BP_OK; - }; + } if ((!param) (pbpctl_dev-bp_tpl_flag)) remove_bypass_tpl_auto(pbpctl_dev); -- 1.7.10.4 -- 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/lustre/libcfs: replaced string duplication code with kstrdup
Modified cfs_strdup function to use kstrdup instead of duplicating its
implementation.
Found using Coccinelle.
Signed-off-by: Dragos Foianu dragos.foi...@gmail.com
---
drivers/staging/lustre/lustre/libcfs/libcfs_string.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
b/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
index 9edccc9..4dba304 100644
--- a/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
+++ b/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
@@ -135,18 +135,7 @@ EXPORT_SYMBOL(cfs_str2mask);
/* Duplicate a string in a platform-independent way */
char *cfs_strdup(const char *str, u_int32_t flags)
{
- size_t lenz; /* length of str + zero byte */
- char *dup_str;
-
- lenz = strlen(str) + 1;
-
- dup_str = kmalloc(lenz, flags);
- if (dup_str == NULL)
- return NULL;
-
- memcpy(dup_str, str, lenz);
-
- return dup_str;
+ return kstrdup(str, flags);
}
EXPORT_SYMBOL(cfs_strdup);
--
1.7.10.4
--
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/8] cpufreq: Fix misplaced call to cpufreq_update_policy()
On 12 July 2013 03:45, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: The call to cpufreq_update_policy() is placed in the CPU hotplug callback of cpufreq_stats, which has a higher priority than the CPU hotplug callback of cpufreq-core. As a result, during CPU_ONLINE/CPU_ONLINE_FROZEN, we end up calling cpufreq_update_policy() *before* calling cpufreq_add_dev() ! And for uninitialized CPUs, it just returns silently, not doing anything. Hmm.. To add to it, cpufreq_stats is not even the right place to call cpufreq_update_policy() to begin with. The cpufreq core ought to handle this in its own callback, from an elegance/relevance perspective. So move the invocation of cpufreq_update_policy() to cpufreq_cpu_callback, and place it *after* cpufreq_add_dev(). Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- drivers/cpufreq/cpufreq.c |1 + drivers/cpufreq/cpufreq_stats.c |6 -- 2 files changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index ccc6eab..f8c3100 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1943,6 +1943,7 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, case CPU_ONLINE: case CPU_ONLINE_FROZEN: cpufreq_add_dev(dev, NULL); + cpufreq_update_policy(cpu); Do we need to call this for every hotplug of cpu? I am not talking about suspend/resume here. -- 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: zsmalloc: access page-private by using page_private macro
Signed-off-by: Sunghan Suh sunghan@samsung.com --- drivers/staging/zsmalloc/zsmalloc-main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c b/drivers/staging/zsmalloc/zsmalloc-main.c index 4bb275b..1a67537 100644 --- a/drivers/staging/zsmalloc/zsmalloc-main.c +++ b/drivers/staging/zsmalloc/zsmalloc-main.c @@ -423,7 +423,7 @@ static struct page *get_next_page(struct page *page) if (is_last_page(page)) next = NULL; else if (is_first_page(page)) - next = (struct page *)page-private; + next = (struct page *)page_private(page); else next = list_entry(page-lru.next, struct page, lru); @@ -581,7 +581,7 @@ static struct page *alloc_zspage(struct size_class *class, gfp_t flags) first_page-inuse = 0; } if (i == 1) - first_page-private = (unsigned long)page; + set_page_private(first_page, (unsigned long)page); if (i = 1) page-first_page = first_page; if (i = 2) -- 1.8.1.2 -- 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] [SCSI] lpfc 8.3.40: Remove useless cast
Found using coccinelle tool. Signed-off-by: Vladimir Cernov gg.kasper...@gmail.com --- drivers/scsi/lpfc/lpfc_init.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index e0b20fa..b7621f6 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -4721,8 +4721,7 @@ lpfc_sli_driver_resource_setup(struct lpfc_hba *phba) } if (!phba-sli.ring) - phba-sli.ring = (struct lpfc_sli_ring *) - kzalloc(LPFC_SLI3_MAX_RING * + phba-sli.ring = kzalloc(LPFC_SLI3_MAX_RING * sizeof(struct lpfc_sli_ring), GFP_KERNEL); if (!phba-sli.ring) return -ENOMEM; -- 1.7.10.4 -- 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/8] cpufreq: Add helper to perform alloc/free of policy structure
On 12 July 2013 03:46, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Separate out the allocation of the cpufreq policy structure (along with
its error handling) to a helper function. This makes the code easier to
read and also helps with some upcoming code reorganization.
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
drivers/cpufreq/cpufreq.c | 50
-
1 file changed, 35 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index f8c3100..ca14dc2 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -943,6 +943,37 @@ static int cpufreq_add_policy_cpu(unsigned int cpu,
unsigned int sibling,
}
#endif
+static struct cpufreq_policy *cpufreq_policy_alloc(void)
+{
+ struct cpufreq_policy *policy;
+
+ policy = kzalloc(sizeof(struct cpufreq_policy), GFP_KERNEL);
sizeof(*policy) ??
Acked-by: Viresh Kumar viresh.ku...@linaro.org
--
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] ic7xxx_osm: use kzalloc instead of kmalloc + memset
found using coccinelle.
Signed-off-by: Cosmin Stanescu cosmin90stane...@gmail.com
---
drivers/scsi/aic7xxx/aic7xxx_osm.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm.c
b/drivers/scsi/aic7xxx/aic7xxx_osm.c
index c0c6258..7167cfe 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_osm.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_osm.c
@@ -1223,10 +1223,9 @@ ahc_platform_alloc(struct ahc_softc *ahc, void
*platform_arg)
{
ahc-platform_data =
- kmalloc(sizeof(struct ahc_platform_data), GFP_ATOMIC);
+ kzalloc(sizeof(struct ahc_platform_data), GFP_ATOMIC);
if (ahc-platform_data == NULL)
return (ENOMEM);
- memset(ahc-platform_data, 0, sizeof(struct ahc_platform_data));
ahc-platform_data-irq = AHC_LINUX_NOIRQ;
ahc_lockinit(ahc);
ahc-seltime = (aic7xxx_seltime 0x3) 4;
--
1.7.10.4
--
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/8] cpufreq: Revert commit a66b2e to fix cpufreq regression during suspend/resume
On 12 July 2013 03:45, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: commit a66b2e (cpufreq: Preserve sysfs files across suspend/resume) has unfortunately caused several things in the cpufreq subsystem to break subtly after a suspend/resume cycle. The intention of that patch was to retain the file permissions of the cpufreq related sysfs files across suspend/resume. To achieve that, the commit completely removed the calls to cpufreq_add_dev() and __cpufreq_remove_dev() during suspend/resume transitions. But the problem is that those functions do 2 kinds of things: 1. Low-level initialization/tear-down that are critical to the correct functioning of cpufreq-core. 2. Kobject and sysfs related initialization/teardown. Ideally we should have reorganized the code to cleanly separate these two responsibilities, and skipped only the sysfs related parts during suspend/resume. Since we skipped the entire callbacks instead (which also included some CPU and cpufreq-specific critical components), cpufreq subsystem started behaving erratically after suspend/resume. So revert the commit to fix the regression. We'll revisit and address the original goal of that commit separately, since it involves quite a bit of careful code reorganization and appears to be non-trivial. (While reverting the commit, note that another commit f51e1eb cpufreq: Fix cpufreq regression after suspend/resume already reverted part of the original set of changes. So revert only the remaining ones). Cc: sta...@vger.kernel.org Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- drivers/cpufreq/cpufreq.c |4 +++- drivers/cpufreq/cpufreq_stats.c |6 ++ 2 files changed, 5 insertions(+), 5 deletions(-) Acked-by: Viresh Kumar viresh.ku...@linaro.org -- 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 4/8] cpufreq: Extract non-interface related stuff from cpufreq_add_dev_interface
On 12 July 2013 03:46, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: cpufreq_add_dev_interface() includes the work of exposing the interface to the device, as well as a lot of unrelated stuff. Move the latter to cpufreq_add_dev(), where it is more appropriate. Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- drivers/cpufreq/cpufreq.c | 43 ++- 1 file changed, 26 insertions(+), 17 deletions(-) Acked-by: Viresh Kumar viresh.ku...@linaro.org -- 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 0/2] TWL6030, TWL6032 GPADC driver
Hello, v3 - fixed compiler warning v2 - the driver put in drivers/iio, and converted using iio facilities as suggested by Graeme. TWL603[02] GPADC is used to measure battery voltage, battery temperature, battery presence ID, and could be used to measure twl603[02] die temperature. This is used on TI blaze, blaze tablet platforms. The TWL6030/TWL6032 is a PMIC that has a GPADC with 17/19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements, other channels measure voltage, (i.e. battery voltage), and have inbuilt voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels could be calibrated in 2 points, having offsets from ideal values in trim registers. The difference between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver exports function returning converted value for requested channels. Sysfs entries are added to start and read conversion result in millivolts for chosen channel. The driver is derived from git://git.omapzoom.org/kernel/omap.git The original driver's authors and contributors are Balaji T K, Graeme Gregory, Ambresh K, Girish S Ghongdemath. The changes to the original driver: - device tree adaptation; - drop ioctl support - never been used; - unified measurement method for both devices; - get rid of if (device == X) code style to data driven; - drop polling end of conversion and use interrupt instead; - iio framework is used Tested with on blaze tablet 2 with OMAP4430(twl6030), and OMAP4470(twl6032) SOMs. The patches were tested against 3.10-rc7 Oleksandr Kozaruk (2): ARM: dts: twl: Add GPADC data to device tree iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver arch/arm/boot/dts/twl6030.dtsi |6 + drivers/iio/adc/Kconfig |8 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1019 +++ 4 files changed, 1034 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c -- 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/
[PATCH v3 1/2] ARM: dts: twl: Add GPADC data to device tree
GPADC is the general purpose ADC present on twl6030.
The dt data is interrupt used to trigger end of ADC
conversion.
Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com
---
arch/arm/boot/dts/twl6030.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 2e3bd31..434842c 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -103,4 +103,10 @@
compatible = ti,twl6030-pwmled;
#pwm-cells = 2;
};
+
+ gpadc: twl6030_gpadc {
+ compatible = ti,twl6030_gpadc;
+ interrupts = 3;
+ #io-channel-cells = 1;
+ };
};
--
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/
[PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver
The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring voltage drop on resistive load for detecting battery ID resistance, or measuring voltage drop on NTC resistors for external temperature measurements. Some channels measure voltage, (i.e. battery voltage), and have voltage dividers, thus, capable to scale voltage. Some channels are dedicated for measuring die temperature. Some channels are calibrated in 2 points, having offsets from ideal values kept in trim registers. This is used to correct measurements. The differences between GPADC in TWL6030 and TWL6032: - 10 bit vs 12 bit ADC; - 17 vs 19 channels; - channels have different purpose(i. e. battery voltage channel 8 vs channel 18); - trim values are interpreted differently. The driver exports function returning converted value for requested channels. Based on the driver patched from Balaji TK, Graeme Gregory, Ambresh K, Girish S Ghongdemath. Signed-off-by: Balaji T K balaj...@ti.com Graeme Gregory g...@slimlogic.co.uk Signed-off-by: Oleksandr Kozaruk oleksandr.koza...@ti.com --- drivers/iio/adc/Kconfig |8 + drivers/iio/adc/Makefile|1 + drivers/iio/adc/twl6030-gpadc.c | 1019 +++ 3 files changed, 1028 insertions(+) create mode 100644 drivers/iio/adc/twl6030-gpadc.c diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index ab0767e6..87d699e 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -157,4 +157,12 @@ config VIPERBOARD_ADC Say yes here to access the ADC part of the Nano River Technologies Viperboard. +config TWL6030_GPADC + tristate TWL6030 GPADC (General Purpose A/D Convertor) Support + depends on TWL4030_CORE + default n + help + Say yes here if you want support for the TWL6030 General Purpose + A/D Convertor. + endmenu diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index 0a825be..8b05633 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -17,3 +17,4 @@ obj-$(CONFIG_MAX1363) += max1363.o obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o +obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o diff --git a/drivers/iio/adc/twl6030-gpadc.c b/drivers/iio/adc/twl6030-gpadc.c new file mode 100644 index 000..6ceb789 --- /dev/null +++ b/drivers/iio/adc/twl6030-gpadc.c @@ -0,0 +1,1019 @@ +/* + * TWL6030 GPADC module driver + * + * Copyright (C) 2009-2013 Texas Instruments Inc. + * Nishant Kamat nska...@ti.com + * Balaji T K balaj...@ti.com + * Graeme Gregory g...@slimlogic.co.uk + * Girish S Ghongdemath giris...@ti.com + * Ambresh K ambr...@ti.com + * Oleksandr Kozaruk oleksandr.koza...@ti.com + * + * Based on twl4030-madc.c + * Copyright (C) 2008 Nokia Corporation + * Mikko Ylinen mikko.k.yli...@nokia.com + * + * 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA + * 02110-1301 USA + * + */ +#include linux/init.h +#include linux/interrupt.h +#include linux/kernel.h +#include linux/module.h +#include linux/platform_device.h +#include linux/of_platform.h +#include linux/i2c/twl.h +#include linux/iio/iio.h +#include linux/iio/sysfs.h + +#define DRIVER_NAMEtwl6030_gpadc + +#define TWL6030_GPADC_MAX_CHANNELS 17 +#define TWL6032_GPADC_MAX_CHANNELS 19 +/* Define this as the biggest of all chips using this driver */ +#define GPADC_MAX_CHANNELS TWL6032_GPADC_MAX_CHANNELS + +#define TWL6030_GPADC_CTRL 0x00/* 0x2e */ +#define TWL6030_GPADC_CTRL20x01/* 0x2f */ + +#define TWL6030_GPADC_CTRL_P1 0x05 +#define TWL6030_GPADC_CTRL_P2 0x06 + +#define TWL6032_GPADC_GPSELECT_ISB 0x07 +#define TWL6032_GPADC_CTRL_P1 0x08 + +#define TWL6032_GPADC_RTCH0_LSB0x09 +#define TWL6032_GPADC_RTCH0_MSB0x0a +#define TWL6032_GPADC_RTCH1_LSB0x0b +#define TWL6032_GPADC_RTCH1_MSB0x0c +#define TWL6032_GPADC_GPCH0_LSB0x0d +#define TWL6032_GPADC_GPCH0_MSB0x0e + +#define
Re: [PATCH 5/8] cpufreq: Extract the handover of policy cpu to a helper function
On 12 July 2013 03:46, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: During cpu offline, when the policy-cpu is going down, some other CPU present in the policy-cpus mask is nominated as the new policy-cpu. Extract this functionality from __cpufreq_remove_dev() and implement it in a helper function. This helps in upcoming code reorganization. Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- drivers/cpufreq/cpufreq.c | 62 - 1 file changed, 38 insertions(+), 24 deletions(-) Acked-by: Viresh Kumar viresh.ku...@linaro.org -- 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 6/6] [RFC] usb: gadget: USB_GADGET should depend on HAS_DMA
Hi Alan,
On Thu, Jul 11, 2013 at 5:51 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 11 Jul 2013, Geert Uytterhoeven wrote:
If NO_DMA=y:
drivers/built-in.o: In function `dma_set_coherent_mask':
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
drivers/built-in.o: In function `usb_gadget_unmap_request':
drivers/usb/gadget/udc-core.c:91: undefined reference to `dma_unmap_sg'
drivers/usb/gadget/udc-core.c:96: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `usb_gadget_map_request':
drivers/usb/gadget/udc-core.c:62: undefined reference to `dma_map_sg'
drivers/usb/gadget/udc-core.c:71: undefined reference to `dma_map_single'
drivers/usb/gadget/udc-core.c:74: undefined reference to `dma_mapping_error'
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
This one is very debatable: probably the parts using the DMA API should
be factored out, instead of disabling the whole USB gadget subsystem.
Indeed. How does this look instead?
Alan Stern
Index: usb-3.10/drivers/usb/gadget/udc-core.c
===
--- usb-3.10.orig/drivers/usb/gadget/udc-core.c
+++ usb-3.10/drivers/usb/gadget/udc-core.c
@@ -50,6 +50,8 @@ static DEFINE_MUTEX(udc_lock);
/* -
*/
+#ifdef CONFIG_HAS_DMA
+
int usb_gadget_map_request(struct usb_gadget *gadget,
struct usb_request *req, int is_in)
{
@@ -99,6 +101,8 @@ void usb_gadget_unmap_request(struct usb
}
EXPORT_SYMBOL_GPL(usb_gadget_unmap_request);
+#endif /* CONFIG_HAS_DMA */
+
/* -
*/
void usb_gadget_set_state(struct usb_gadget *gadget,
@@ -194,9 +198,11 @@ int usb_add_gadget_udc_release(struct de
dev_set_name(gadget-dev, gadget);
gadget-dev.parent = parent;
+#ifdef CONFIG_HAS_DMA
dma_set_coherent_mask(gadget-dev, parent-coherent_dma_mask);
gadget-dev.dma_parms = parent-dma_parms;
gadget-dev.dma_mask = parent-dma_mask;
+#endif
if (release)
gadget-dev.release = release;
Thanks, that works!
(after adding a few more dependencies on HAS_DMA for drivers that call
into usb_gadget_{,un}map_request() and/or dma_set_coherent_mask(),
for which I'll send separate patches).
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] iio: hid-sensor: add module alias for autoload
Am 11.07.2013 19:27, schrieb Srinivas Pandruvada: On 07/10/2013 08:58 AM, Alexander Holler wrote: Am 10.07.2013 17:27, schrieb Srinivas Pandruvada: Hi, There was no intention to prevent auto loading. Did you get chance to test these changes? Sure, I always test patches before I send them out. Ok, I haven't tested the changes with the iio HID drivers (I don't have any commercial HID sensor hub, so I've just compile tested these patches here, double reading them), but I've tested the similiar changes with a patch for rtc-hid-sensor-time I've send out yesterday. (sorry, no link, lkml.org seems dead, just search for rtc-hid-sensor-time: add module alias) It works just fine. An example output is now Jul 9 19:27:21 dockstar3 kernel: [5.12] rtc_hid_sensor_time HID-SENSOR-2000a0.0: milliseconds supported Jul 9 19:27:21 dockstar3 kernel: [5.132864] rtc_hid_sensor_time HID-SENSOR-2000a0.0: rtc core: setting system clock to 2013-07-09 17:26:51:328000 UTC (1373390811) Jul 9 19:27:21 dockstar3 kernel: [5.146105] rtc_hid_sensor_time HID-SENSOR-2000a0.0: rtc core: registered hid-sensor-time as rtc0 Before the output was e.g. HID-SENSOR-2000a0 HID-SENSOR-2000a0.0: rtc core: registered hid-sensor-time as rtc0 instead of the above with the descriptive rtc_hid_sensor_time. Agreed. This is better. Automatic loading of modules works too and it works on ARM, Intel and AMD as module or static linked. ;) Do you have tested the patches with a real device? I assume you have one. ;) Regards, Alexander Holler -- 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: trace: remove __init from race_selftest_startup_function() and trace_selftest_startup_function_graph()
On 07/12/2013 11:04 AM, Chen Gang wrote:
On 07/12/2013 10:38 AM, Steven Rostedt wrote:
On Fri, 2013-07-12 at 09:58 +0800, Chen Gang wrote:
On 07/12/2013 09:41 AM, Steven Rostedt wrote:
On Fri, 2013-07-12 at 07:51 +0800, Chen Gang wrote:
Hmm, can all trace_selftest_startup_* (*selftest* in trace_selftest.c)
use '__init', so not waste memory keeping them around ?
Yeah, they should all be set to __init, but that's pretty low on the
totem poll, as distros don't enable selftests in their main kernels.
Excuse me, my English is not quite well, I guess your meaning is:
they should all be set to '__init', although it is minor in real world.
Is it correct ?
Correct.
For me, I recommend to let all *selftest* as the same: all add '
__init' or none add '__init' (if choose add, all report warnings).
Is it suitable to still send new related patch for it ? If so, could
you provide your suggesting choice (all add, or none add) ?
Does this patch fix your warning?
-- Steve
After the test, they will not report the related warning.
Hmm..., but that will let another none *selftest* functions miss
'__read_mostly'.
Do the original *selftest* intend to have no '__init' so can fit other
none *selftest* with '__read_mostly', and without warnings ?
Welcome any members' suggestions or completions.
Thanks.
I guess it can (although I do not give a compiling test), it seems a
better fixing.
And is it suitable to let all *selftest* as the same ? (all add, or none
add '__init').
Thanks.
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index a4ed382..5e794d1 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -680,6 +680,15 @@ extern int trace_selftest_startup_sched_switch(struct
tracer *trace,
struct trace_array *tr);
extern int trace_selftest_startup_branch(struct tracer *trace,
struct trace_array *tr);
+/*
+ * Tracer data references selftest functions that only occur
+ * on boot up. These can be __init functions. Thus, when selftests
+ * are enabled, then the tracers need to reference __init functions.
+ */
+#define __tracer_data __refdata
+#else
+/* Tracers are seldom changed. Optimize when selftests are disabled. */
+#define __tracer_data __read_mostly
#endif /* CONFIG_FTRACE_STARTUP_TEST */
extern void *head_page(struct trace_array_cpu *data);
diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
index b863f93..38fe148 100644
--- a/kernel/trace/trace_functions.c
+++ b/kernel/trace/trace_functions.c
@@ -199,7 +199,7 @@ static int func_set_flag(u32 old_flags, u32 bit, int set)
return 0;
}
-static struct tracer function_trace __read_mostly =
+static struct tracer function_trace __tracer_data =
{
.name = function,
.init = function_trace_init,
--
Chen Gang
--
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 6/8] cpufreq: Introduce a flag ('frozen') to separate full vs temporary init/teardown
On 12 July 2013 03:46, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: During suspend/resume we would like to do a light-weight init/teardown of CPUs in the cpufreq subsystem and preserve certain things such as sysfs files etc across suspend/resume transitions. Add a flag called 'frozen' to help distinguish the full init/teardown sequence from the light-weight one. Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- drivers/cpufreq/cpufreq.c | 66 - 1 file changed, 41 insertions(+), 25 deletions(-) Acked-by: Viresh Kumar viresh.ku...@linaro.org -- 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: [Ksummit-2013-discuss] When to push bug fixes to mainline
On Thu, 2013-07-11 at 20:34 -0700, Greg Kroah-Hartman wrote: On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote: On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote: In any case, I've been very conservative in _not_ pushing bug fixes to Linus after -rc3 (unless they are fixing a regression or the bug fix is super-serious); I'd much rather have them cook in the ext4 tree where they can get a lot more testing (a full regression test run for ext4 takes over 24 hours), and for people trying out linux-next. Maybe the pendulum has swung too far in the direction of holding back changes and trying to avoid the risk of introducing regressions; perhaps this would be a good topic to discuss at the Kernel Summit. Yes, there does seem to be a certain ebb and flow as to how strict the rules are about what should go into stable, what fixes are good enough for a given -rc, how tight those rule are in -rc2 vs in -rc6, etc. If nothing else, a good repetitive flogging and a restatement of the One True Way to handle these things might be worthwhile once again... The rules are documented in stable_kernel_rules.txt for what I will accept. I have been beating on maintainers for 8 years now to actually mark patches for stable, and only this past year have I finally seen people do it (we FINALLY got SCSI patches marked for stable in this merge window!!!) What do you mean FINALLY? There've been SCSI patches marked for stable in every other merge window as well. The whole reason I ran the stable patch tracker before you took it over was so I could get the Cc: to stable stuff working. James So now that maintainers are finally realizing that they need to mark patches, I'll be pushing back harder on the patches that they do submit, because the distros are rightfully pushing back on me for accepting things that are outside of the stable_kernel_rules.txt guidelines. If you look on the stable@vger list, I've already rejected 3 today and asked about the huge 21 powerpc patches. Sure, it's not a lot, when staring down 174 more to go, but it's a start... greg k-h ___ Ksummit-2013-discuss mailing list ksummit-2013-disc...@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-2013-discuss -- 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 6/6] [RFC] usb: gadget: USB_GADGET should depend on HAS_DMA
Alan Stern st...@rowland.harvard.edu writes: On Thu, 11 Jul 2013, Geert Uytterhoeven wrote: If NO_DMA=y: drivers/built-in.o: In function `dma_set_coherent_mask': include/linux/dma-mapping.h:93: undefined reference to `dma_supported' include/linux/dma-mapping.h:93: undefined reference to `dma_supported' drivers/built-in.o: In function `usb_gadget_unmap_request': drivers/usb/gadget/udc-core.c:91: undefined reference to `dma_unmap_sg' drivers/usb/gadget/udc-core.c:96: undefined reference to `dma_unmap_single' drivers/built-in.o: In function `usb_gadget_map_request': drivers/usb/gadget/udc-core.c:62: undefined reference to `dma_map_sg' drivers/usb/gadget/udc-core.c:71: undefined reference to `dma_map_single' drivers/usb/gadget/udc-core.c:74: undefined reference to `dma_mapping_error' Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- This one is very debatable: probably the parts using the DMA API should be factored out, instead of disabling the whole USB gadget subsystem. Indeed. How does this look instead? This one is much better. FWIW, Acked-by: Alexander Shishkin alexander.shish...@linux.intel.com Regards, -- Alex -- 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 RESEND 0/1] AHCI: Optimize interrupt processing
On Thu, Jul 11, 2013 at 04:00:37PM -0700, Nicholas A. Bellinger wrote:
On Thu, 2013-07-11 at 12:26 +0200, Alexander Gordeev wrote:
On Wed, May 22, 2013 at 07:03:05PM +0200, Jens Axboe wrote:
On Wed, May 22 2013, Alexander Gordeev wrote:
On Wed, May 22, 2013 at 08:50:03AM +0900, Tejun Heo wrote:
Hmm. I'd normally apply this patch but block layer is just
growing multi-queue support and libata is likely to be converted to mq
in foreseeable future, so I'm a bit hesitant to make irq handling more
sophiscated right now. Would you be interested in looking into
converting libata to blk mq support? I'm pretty sure it'd yield far
better outcome if done properly.
I am not committing, but will look into it, sure.
Would be most awesome, I'm sure Nic would not mind a bit of help on the
SCSI/libata side :-)
Hi Nicholas,
Could you please clarify the status of SCSI MQ support? Is it usable now?
Hi Alexander,
Thanks for taking a look. I've not made further progress in the last
weeks on scsi-mq, but am still using virtio-scsi + scsi-mq -
vhost-scsi + per-cpu-ida for quite a bit for benchmarking purposes.
Thanks for the clarification, Nicholas.
I tried
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git,
but it does not appear working without (at least) changes below to SCSI lib:
The only scsi-mq LLD conversions so far have been to virtio-scsi +
scsi_debug to nop REQ_TYPE_FS.
I see. Do you think the changes I made is a right way to go?
I had to make it to avoid a NULL-pointer assignent and make BIO bounce
buffers work, but I do not really understand the mixture of old and
new code ( neither in fact :) )
Just so I understand, your patch below is required in order to make what
LLD function with scsi-mq..?
ata_piix
Thanks!
--nab
Thanks!
diff --git a/drivers/scsi/scsi-mq.c b/drivers/scsi/scsi-mq.c
index ca6ff67..d8cc7a4 100644
--- a/drivers/scsi/scsi-mq.c
+++ b/drivers/scsi/scsi-mq.c
@@ -155,6 +155,7 @@ void scsi_mq_done(struct scsi_cmnd *sc)
static struct blk_mq_ops scsi_mq_ops = {
.queue_rq = scsi_mq_queue_rq,
.map_queue = blk_mq_map_queue,
+ .timeout= scsi_times_out,
.alloc_hctx = blk_mq_alloc_single_hw_queue,
.free_hctx = blk_mq_free_single_hw_queue,
};
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 65360db..33aa373 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -283,7 +283,10 @@ int scsi_execute(struct scsi_device *sdev, const
unsigned char *cmd,
/*
* head injection *required* here otherwise quiesce won't work
*/
- blk_execute_rq(req-q, NULL, req, 1);
+ if (q-mq_ops)
+ blk_mq_execute_rq(req-q, req);
+ else
+ blk_execute_rq(req-q, NULL, req, 1);
/*
* Some devices (USB mass-storage in particular) may transfer
@@ -298,12 +301,8 @@ int scsi_execute(struct scsi_device *sdev, const
unsigned char *cmd,
*resid = req-resid_len;
ret = req-errors;
out:
- if (q-mq_ops) {
- printk(scsi_execute(): Calling blk_mq_free_request \n);
- blk_mq_free_request(req);
- } else {
+ if (!q-mq_ops)
blk_put_request(req);
- }
return ret;
}
And personally, can't wait to run it on the laptop! That's right, I
alpha test on the laptop.
--
Jens Axboe
--
Regards,
Alexander Gordeev
agord...@redhat.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] input: don't call input_dev_release_keys() in resume
On 09:46 Fri 05 Jul , Oskar Andero wrote:
Hi Dmitry,
On 18:33 Thu 04 Apr , Dmitry Torokhov wrote:
Hi Oskar,
On Thu, Mar 07, 2013 at 03:01:22PM +0100, oskar.and...@sonymobile.com wrote:
From: Aleksej Makarov aleksej.maka...@sonymobile.com
When waking up the platform by pressing a specific key, sending a
release on that key makes it impossible to react on the event in
user-space.
No, we can not simply not release keys after resume from suspend, as
this leads to keys being stuck. Consider you are holding an 'I' key on
your external USB keyboard and close your laptop's lid. Then you release
the key and leave. Later you come back, open the lid waking the laptop
and observe endless stream of 'I' in your open terminal.
Maybe we should release the keys during suspend time? I am not sure how
Android infrastructure will react to this though...
I finally got the time to try this out. Releasing the keys in suspend
also solves our problem. Would such patch work for the USB keyboard
case you described? Theoretically, I think it should, right?
So, basically:
static int input_dev_suspend(struct device *dev)
{
struct input_dev *input_dev = to_input_dev(dev);
- mutex_lock(input_dev-mutex);
-
- if (input_dev-users)
- input_dev_toggle(input_dev, false);
-
- mutex_unlock(input_dev-mutex);
+ input_reset_device(input_dev);
return 0;
}
static int input_dev_resume(struct device *dev)
{
- struct input_dev *input_dev = to_input_dev(dev);
-
- input_reset_device(input_dev);
-
return 0;
}
Should I send the patch?
Ping. Any thoughts on this?
Thanks!
-Oskar
--
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/
