Re: [PATCH] jbd2: get rid of superfluous __GFP_REPEAT
On Thu 26-11-15 15:18:17, Theodore Ts'o wrote: > On Thu, Nov 26, 2015 at 04:10:17PM +0100, Michal Hocko wrote: > > Hi Ted, > > are there any objections for the patch or should I just repost it? > > Sorry, when you first posted it I was crazy busy before going on a two > week vacation/pilgrimage (and in fact I'm still in Jerusalem, but I'm > going to be heading home soon). I am starting to work on some > patches, and expect to have time to do more work on the airplane. The > patches are queued up, and so I haven't lost them. So feel free to > repost them if you want, but it's not necessary unless you have some > fixup to the patch. Sure, no worry, this is nothing urgent, I just wanted to make sure it doesn't fall thought the cracks. If you have the latest one I was replying to then everything should be ok. Thanks -- Michal Hocko SUSE Labs -- 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 6/6] arm64: dts: berlin4ct: add pll and clock nodes
On 24.11.2015 03:35, Jisheng Zhang wrote:
On Mon, 23 Nov 2015 16:54:44 +0800
Jisheng Zhang wrote:
On Mon, 23 Nov 2015 09:30:42 +0100
Sebastian Hesselbarth wrote:
On 23.11.2015 08:21, Jisheng Zhang wrote:
On Fri, 20 Nov 2015 22:06:59 +0100
Sebastian Hesselbarth wrote:
On 20.11.2015 09:42, Jisheng Zhang wrote:
Add syspll, mempll, cpupll, gateclk and berlin-clk nodes.
Signed-off-by: Jisheng Zhang
---
[...]
+ syspll: syspll {
+ compatible = "marvell,berlin-pll";
+ reg = <0xea0200 0x14>, <0xea0710 4>;
+ #clock-cells = <0>;
+ clocks = <>;
+ bypass-shift = /bits/ 8 <0>;
+ };
+
+ gateclk: gateclk {
+ compatible = "marvell,berlin4ct-gateclk";
+ reg = <0xea0700 4>;
+ #clock-cells = <1>;
+ };
+
+ clk: clk {
+ compatible = "marvell,berlin4ct-clk";
+ reg = <0xea0720 0x144>;
Looking at the reg ranges, I'd say that they are all clock related
and pretty close to each other:
gateclk: reg = <0xea0700 4>;
bypass: reg = <0xea0710 4>;
clk: reg = <0xea0720 0x144>;
Although these ranges sit close, but we should represent HW structure as you
said.
Then how do you argue that you have to share the gate clock register
with every PLL? The answer is quite simple: You are not separating by
HW either but existing SW API.
No, PLLs don't share register any more. You can find what all clock nodes will
look like in:
Jisheng,
referring to the sunxi clock related thread, I am glad you finally
picked up the idea of merging clock nodes. Before you start reworking
bg4 clocks, I think I should be a little bit more clear about what I
expect to be the outcome.
When I said "one single clock complex node", I was referring to the
clocks located within the system-controller reg region, i.e. those at
0xea. With bg2x we came to the conclusion that those registers
cannot be not cleanly separated by functions, so we decided to have
a single system-controller simple-mfd node with sub-nodes for
pinctrl, clock, reset, and whatever we will find there in the future.
Please also follow this scheme for bg4 because when you start looking
at reset, you'll likely see the same issues we were facing: Either you
have a reset controller node with a plethora of reg property entries
or you constantly undermine the concept of requested resources by using
of_iomap().
Using simple-mfd is a compromise between detailed HW description and
usability. It will also automatically deal with concurrent accesses to
the same register for e.g. clock and reset because simple-mfd and syscon
install an access lock for the reg region. Even though there may be no
real concurrent accesses to the same register, it does no real harm
because we are locking resisters that aren't supposed to be used in
high-speed applications. Some of them are touched once at boot, most
of them are never touched by Linux at all.
For the other PLLs at <0x922000 0x14> and <0x940034 0x14>, I do accept
that they are not part of the system-controller sub-node. For the short
run, I would accept separate nodes for the PLLs alone, but on the long
run they should be hidden within the functional node they belong to,
i.e. mempll should be a clock provided by some memory-controller node.
As soon as you look at power saving modes for the memory-controller,
you would need access to memory-controller register _and_ mempll anyway.
We do have our DT tagged unstable, so we still can easily revert our
limited view of some nodes later.
BTW, if the clock provided by mempll is used to generate peripheral
clocks that are dealt with in the sysctrl clock complex, you should,
of course, expose that relation in DT, e.g.:
sysctrl: system-controller {
reg = <0xea0700 0xfoo>;
sysclk: clock {
#clock-cells = <1>;
clocks = <>, < 0>;
clock-names = "osc", "mempll";
};
};
memctrl: memory-controller {
reg = <0x92 0xbar>;
/*
* clock-cells can also be 0
* if there is no other clock provided
*/
#clock-cells = <1>;
clocks = <>;
clock-names = "osc";
};
some-peripheral: bla {
clocks = < SOME_PERIPHERAL_CLOCK_ID>;
};
Sebastian
If you would really want to just describe the HW, then you'd have to
have a single node for _all_ clocks that get controlled by 0xea0700/0x4,
feed some 32+ clocks into the node, and out again. Obviously, this
isn't what we want, right?
I represented the HW by "kind", for example, gateclks, common-clks, pllclk.
And let common PLLs follow this rule as well:
one node for all common plls
reg <0x922000 0x14>, <0x940034 0x14>, <0xea0200 0x14>
So, the idea of berlin2 sysctrl nodes (and similar other SoCs) is: Some
SoCs just dump some functions into a bunch
Re: [PATCH 2/3] perf callchain: Stop resolving callchains after invalid address
* Namhyung Kim wrote:
> Hi Ingo,
>
> On Thu, Nov 26, 2015 at 08:43:35AM +0100, Ingo Molnar wrote:
> >
> > * Namhyung Kim wrote:
> >
> > > Unwinding optimized binaries using frame pointer gives garbage. Check
> > > callchain address and stop if it's under vm.mmap_min_addr sysctl value.
> > >
> > > Before:
> > > $ perf report --stdio --no-children -g callee
> > > ...
> > >
> > >1.37% perf[kernel.vmlinux][k] smp_call_function_single
> > >|
> > >---smp_call_function_single
> > > _perf_event_enable
> > > perf_event_for_each_child
> > > perf_ioctl
> > > do_vfs_ioctl
> > > sys_ioctl
> > > entry_SYSCALL_64_fastpath
> > > __GI___ioctl
> > > 0
> > > 0
> > > 0x1c5aa70
> > > 0x1c5b910
> > > 0x1c5aa70
> > > 0x1c5b910
> > > 0x1c5aa70
> > > 0x1c5b910
> > > 0x1c5aa70
> > > 0x1c5b910
> > > 0x1c5aa70
> > > 0x1c5b910
> > > ...
> > >
> > > After:
> > > $ perf report --stdio --no-children -g callee
> > > ...
> > >
> > >1.37% perf[kernel.vmlinux][k] smp_call_function_single
> > >|
> > >---smp_call_function_single
> > > _perf_event_enable
> > > perf_event_for_each_child
> > > perf_ioctl
> > > do_vfs_ioctl
> > > sys_ioctl
> > > entry_SYSCALL_64_fastpath
> > > __GI___ioctl
> >
> > In addition to that, would it make sense to terminate the callchain with an
> > indicator that we found something anomalous? Such an extra line:
> >
> > ...
> >
> > would not be intrusive, but would tell the informed reader that it's not a
> > normal
> > ending of the call chain.
> >
> > This assumes that we can tell apart 'normal end of call chain' from 'seems
> > to end
> > with garbage poiner' cases - can do we that?
>
> In case of fp unwind, I'm not sure we can determine whether it's
> normal end or not especially for optimized binaries. It seems kernel
> also can stop callchain anytime if it sees a broken frame.
>
> For dwarf unwind, I think it's also hard to tell since it can be
> stopped for various reasons like insufficient dump size or broken CFI,
But but. Doesn't your patch 'detect' an anomaly to begin with?
+ /*
+* Callchain value under mmap_min_addr means it's broken
+* or the end of callchain. Stop.
+*/
+ if (ip < mmap_min_addr) {
+ if (callchain_param.order == ORDER_CALLEE)
+ break;
all I'm asking for is to indicate it in some low-key visual fashion when we
encounter such a 'broken' call-chain.
I presume the 'old' way of ending the call-chain was that 'ip' was zero, right?
We
should not print the indicator in that case.
Also, in the dwarf case I'd also see value in indicating if any of these events
occured:
> For dwarf unwind, I think it's also hard to tell since it can be stopped
for
> various reasons like insufficient dump size or broken CFI,
even if we cannot catch all anomalies. Performance analysis must stand firm on
a
hard rock of reliability and dependability, and we should always propagate
information about possible profiling data corruption/unreliability. That's why
we
print the 'IO overload' messages during perf record for example.
Even if the problem is not caused by perf, but by external factors such as the
compiler/linker.
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/core] bpf tools: Add helper function for updating bpf maps elements
Commit-ID: 43798bf37215fe242e592fd4605d804e2da0781b
Gitweb: http://git.kernel.org/tip/43798bf37215fe242e592fd4605d804e2da0781b
Author: He Kuang
AuthorDate: Tue, 24 Nov 2015 13:36:08 +
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Nov 2015 17:21:24 -0300
bpf tools: Add helper function for updating bpf maps elements
Add bpf_map_update_elem() helper function which calls the sys_bpf
syscall to update elements in bpf maps. Upcoming patches will use it to
adjust data in map through the perf command line.
Signed-off-by: He Kuang
Cc: Alexei Starovoitov
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Wang Nan
Cc: Zefan Li
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/r/1448372181-151723-4-git-send-email-wangn...@huawei.com
Signed-off-by: Wang Nan
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/bpf/bpf.c | 14 ++
tools/lib/bpf/bpf.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index a633105..5bdc6ea 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -83,3 +83,17 @@ int bpf_load_program(enum bpf_prog_type type, struct
bpf_insn *insns,
log_buf[0] = 0;
return sys_bpf(BPF_PROG_LOAD, , sizeof(attr));
}
+
+int bpf_map_update_elem(int fd, void *key, void *value,
+ u64 flags)
+{
+ union bpf_attr attr;
+
+ bzero(, sizeof(attr));
+ attr.map_fd = fd;
+ attr.key = ptr_to_u64(key);
+ attr.value = ptr_to_u64(value);
+ attr.flags = flags;
+
+ return sys_bpf(BPF_MAP_UPDATE_ELEM, , sizeof(attr));
+}
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index 854b736..a764655 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -20,4 +20,6 @@ int bpf_load_program(enum bpf_prog_type type, struct bpf_insn
*insns,
u32 kern_version, char *log_buf,
size_t log_buf_sz);
+int bpf_map_update_elem(int fd, void *key, void *value,
+ u64 flags);
#endif
--
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/core] perf symbols: Add the path to vmlinux.debug
Commit-ID: f55ae9540d16a355e61cb57b035aab9e1ae2da28
Gitweb: http://git.kernel.org/tip/f55ae9540d16a355e61cb57b035aab9e1ae2da28
Author: Ekaterina Tumanova
AuthorDate: Wed, 25 Nov 2015 17:32:46 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Nov 2015 16:50:35 -0300
perf symbols: Add the path to vmlinux.debug
Currently when debuginfo is separated to vmlinux.debug, it's contents
get ignored. Let's change that and add it to the vmlinux_path list.
Signed-off-by: Ekaterina Tumanova
Acked-by: Alexander Yarygin
Acked-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Christian Borntraeger
Cc: David Ahern
Cc: Namhyung Kim
Cc: Naveen N. Rao
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1448469166-61363-3-git-send-email-tuman...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/symbol.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index e2ac6b6..d51abd2 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1869,7 +1869,8 @@ static const char * const vmlinux_paths_upd[] = {
"/boot/vmlinux-%s",
"/usr/lib/debug/boot/vmlinux-%s",
"/lib/modules/%s/build/vmlinux",
- "/usr/lib/debug/lib/modules/%s/vmlinux"
+ "/usr/lib/debug/lib/modules/%s/vmlinux",
+ "/usr/lib/debug/boot/vmlinux-%s.debug"
};
static int vmlinux_path__add(const char *new_entry)
--
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/core] perf evlist: Display WEIGHT sample type bit
Commit-ID: dcdd184b60c3943fb678dcbaf899a26f845901ad
Gitweb: http://git.kernel.org/tip/dcdd184b60c3943fb678dcbaf899a26f845901ad
Author: Jiri Olsa
AuthorDate: Wed, 25 Nov 2015 16:36:55 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Nov 2015 16:54:00 -0300
perf evlist: Display WEIGHT sample type bit
Adding WIEGHT bit_name call to display sample_type properly.
$ perf evlist -v
cpu/mem-loads/pp: ...SNIP... sample_type:
IP|TID|TIME|ADDR|ID|CPU|DATA_SRC|WEIGHT ...
Signed-off-by: Jiri Olsa
Tested-by: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1448465815-27404-2-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evsel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 397fb4e..0a1f4d9 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1192,6 +1192,7 @@ static void __p_sample_type(char *buf, size_t size, u64
value)
bit_name(PERIOD), bit_name(STREAM_ID), bit_name(RAW),
bit_name(BRANCH_STACK), bit_name(REGS_USER),
bit_name(STACK_USER),
bit_name(IDENTIFIER), bit_name(REGS_INTR), bit_name(DATA_SRC),
+ bit_name(WEIGHT),
{ .name = NULL, }
};
#undef bit_name
--
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/core] perf stat: Clear sample_(type|period) for counting
Commit-ID: 6acd8e9271cdeaec458fd4eec4a6765d16e0e61c
Gitweb: http://git.kernel.org/tip/6acd8e9271cdeaec458fd4eec4a6765d16e0e61c
Author: Jiri Olsa
AuthorDate: Wed, 25 Nov 2015 16:36:54 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Nov 2015 16:52:28 -0300
perf stat: Clear sample_(type|period) for counting
Clear sample_(type|period) for counting, as it only confuses debug
output with unwanted sampling details:
Before:
$ sudo perf stat -e 'raw_syscalls:sys_enter' -vv ls
perf_event_attr:
type 2
size 112
config 0x11
{ sample_period, sample_freq } 1
sample_type TIME|CPU|PERIOD|RAW
read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
disabled 1
inherit 1
enable_on_exec 1
exclude_guest1
...
After:
$ sudo perf stat -e 'raw_syscalls:sys_enter' -vv ls
perf_event_attr:
type 2
size 112
config 0x11
read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING
disabled 1
inherit 1
enable_on_exec 1
exclude_guest1
...
Signed-off-by: Jiri Olsa
Tested-by: Arnaldo Carvalho de Melo
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1448465815-27404-1-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index e77880b..df2fbf0 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -161,6 +161,13 @@ static int create_perf_stat_counter(struct perf_evsel
*evsel)
attr->inherit = !no_inherit;
+ /*
+* Some events get initialized with sample_(period/type) set,
+* like tracepoints. Clear it up for counting.
+*/
+ attr->sample_period = 0;
+ attr->sample_type = 0;
+
if (target__has_cpu())
return perf_evsel__open_per_cpu(evsel, perf_evsel__cpus(evsel));
--
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/core] perf symbols: Refactor vmlinux_path__init() to ease path additions
Commit-ID: aac4864727f4b3838ec1c03277bbc47a237b7516
Gitweb: http://git.kernel.org/tip/aac4864727f4b3838ec1c03277bbc47a237b7516
Author: Ekaterina Tumanova
AuthorDate: Wed, 25 Nov 2015 17:32:45 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Nov 2015 16:49:29 -0300
perf symbols: Refactor vmlinux_path__init() to ease path additions
Refactor vmlinux_path__init() to ease subsequent additions of new
vmlinux locations.
Signed-off-by: Ekaterina Tumanova
Acked-by: Alexander Yarygin
Acked-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Christian Borntraeger
Cc: David Ahern
Cc: Namhyung Kim
Cc: Naveen N. Rao
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1448469166-61363-2-git-send-email-tuman...@linux.vnet.ibm.com
[ Rename vmlinux_path__update() to vmlinux_path__add() ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/symbol.c | 64 +---
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index cd08027..e2ac6b6 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1860,24 +1860,43 @@ static void vmlinux_path__exit(void)
zfree(_path);
}
+static const char * const vmlinux_paths[] = {
+ "vmlinux",
+ "/boot/vmlinux"
+};
+
+static const char * const vmlinux_paths_upd[] = {
+ "/boot/vmlinux-%s",
+ "/usr/lib/debug/boot/vmlinux-%s",
+ "/lib/modules/%s/build/vmlinux",
+ "/usr/lib/debug/lib/modules/%s/vmlinux"
+};
+
+static int vmlinux_path__add(const char *new_entry)
+{
+ vmlinux_path[vmlinux_path__nr_entries] = strdup(new_entry);
+ if (vmlinux_path[vmlinux_path__nr_entries] == NULL)
+ return -1;
+ ++vmlinux_path__nr_entries;
+
+ return 0;
+}
+
static int vmlinux_path__init(struct perf_env *env)
{
struct utsname uts;
char bf[PATH_MAX];
char *kernel_version;
+ unsigned int i;
- vmlinux_path = malloc(sizeof(char *) * 6);
+ vmlinux_path = malloc(sizeof(char *) * (ARRAY_SIZE(vmlinux_paths) +
+ ARRAY_SIZE(vmlinux_paths_upd)));
if (vmlinux_path == NULL)
return -1;
- vmlinux_path[vmlinux_path__nr_entries] = strdup("vmlinux");
- if (vmlinux_path[vmlinux_path__nr_entries] == NULL)
- goto out_fail;
- ++vmlinux_path__nr_entries;
- vmlinux_path[vmlinux_path__nr_entries] = strdup("/boot/vmlinux");
- if (vmlinux_path[vmlinux_path__nr_entries] == NULL)
- goto out_fail;
- ++vmlinux_path__nr_entries;
+ for (i = 0; i < ARRAY_SIZE(vmlinux_paths); i++)
+ if (vmlinux_path__add(vmlinux_paths[i]) < 0)
+ goto out_fail;
/* only try kernel version if no symfs was given */
if (symbol_conf.symfs[0] != 0)
@@ -1892,28 +1911,11 @@ static int vmlinux_path__init(struct perf_env *env)
kernel_version = uts.release;
}
- snprintf(bf, sizeof(bf), "/boot/vmlinux-%s", kernel_version);
- vmlinux_path[vmlinux_path__nr_entries] = strdup(bf);
- if (vmlinux_path[vmlinux_path__nr_entries] == NULL)
- goto out_fail;
- ++vmlinux_path__nr_entries;
- snprintf(bf, sizeof(bf), "/usr/lib/debug/boot/vmlinux-%s",
-kernel_version);
- vmlinux_path[vmlinux_path__nr_entries] = strdup(bf);
- if (vmlinux_path[vmlinux_path__nr_entries] == NULL)
- goto out_fail;
-++vmlinux_path__nr_entries;
- snprintf(bf, sizeof(bf), "/lib/modules/%s/build/vmlinux",
kernel_version);
- vmlinux_path[vmlinux_path__nr_entries] = strdup(bf);
- if (vmlinux_path[vmlinux_path__nr_entries] == NULL)
- goto out_fail;
- ++vmlinux_path__nr_entries;
- snprintf(bf, sizeof(bf), "/usr/lib/debug/lib/modules/%s/vmlinux",
-kernel_version);
- vmlinux_path[vmlinux_path__nr_entries] = strdup(bf);
- if (vmlinux_path[vmlinux_path__nr_entries] == NULL)
- goto out_fail;
- ++vmlinux_path__nr_entries;
+ for (i = 0; i < ARRAY_SIZE(vmlinux_paths_upd); i++) {
+ snprintf(bf, sizeof(bf), vmlinux_paths_upd[i], kernel_version);
+ if (vmlinux_path__add(bf) < 0)
+ goto out_fail;
+ }
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] tools build: Use fixdep with OUTPUT path prefix
Commit-ID: 5e50426d5d9049dfdb8b2b18e761717e7e80a6ad
Gitweb: http://git.kernel.org/tip/5e50426d5d9049dfdb8b2b18e761717e7e80a6ad
Author: Jiri Olsa
AuthorDate: Thu, 26 Nov 2015 19:50:55 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Nov 2015 16:32:24 -0300
tools build: Use fixdep with OUTPUT path prefix
Adding OUTPUT path prefix for fixdep target so we use it properly in out
of tree builds.
If the fixdep already existed in the tree, the out of tree build would
see it already exist and did not build the out of tree version, as
reported by Arnaldo:
[acme@zoo linux]$ make O=/tmp/build/perf -C tools/perf
make: Entering directory '/home/git/linux/tools/perf'
BUILD: Doing 'make -j4' parallel build
make[2]: Nothing to be done for 'fixdep'.
make: Leaving directory '/home/git/linux/tools/perf'
Reported-and-Tested-by: Arnaldo Carvalho de Melo
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/r/20151126185055.gc19...@krava.brq.redhat.com
[ Fixed conflict with 5725dd8fa888 ("tools build: Clean CFLAGS and LDFLAGS for
fixdep") ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/build/Makefile | 2 +-
tools/build/Makefile.include | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/build/Makefile b/tools/build/Makefile
index a930362..0d5a0e3 100644
--- a/tools/build/Makefile
+++ b/tools/build/Makefile
@@ -25,7 +25,7 @@ export Q srctree CC LD
MAKEFLAGS := --no-print-directory
build := -f $(srctree)/tools/build/Makefile.build dir=. obj
-all: fixdep
+all: $(OUTPUT)fixdep
clean:
$(call QUIET_CLEAN, fixdep)
diff --git a/tools/build/Makefile.include b/tools/build/Makefile.include
index 6254760..be630be 100644
--- a/tools/build/Makefile.include
+++ b/tools/build/Makefile.include
@@ -4,7 +4,7 @@ ifdef CROSS_COMPILE
fixdep:
else
fixdep:
- $(Q)$(MAKE) -C $(srctree)/tools/build CFLAGS= LDFLAGS= fixdep
+ $(Q)$(MAKE) -C $(srctree)/tools/build CFLAGS= LDFLAGS= $(OUTPUT)fixdep
endif
.PHONY: fixdep
--
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/core] perf script: Pass perf_script into process_event
Commit-ID: 809e9423d7bc72e50d94d8267bab010a007a6137
Gitweb: http://git.kernel.org/tip/809e9423d7bc72e50d94d8267bab010a007a6137
Author: Jiri Olsa
AuthorDate: Thu, 26 Nov 2015 18:55:21 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Nov 2015 16:06:16 -0300
perf script: Pass perf_script into process_event
Passing perf_script struct into process_event function, so we could
process configuration data for event printing.
It will be used in following patch to get event name string width.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20151126175521.ga18...@krava.brq.redhat.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-script.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 8e3f804..3c3f8d0 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -588,8 +588,17 @@ static void print_sample_flags(u32 flags)
printf(" %-4s ", str);
}
-static void process_event(union perf_event *event, struct perf_sample *sample,
- struct perf_evsel *evsel, struct addr_location *al)
+struct perf_script {
+ struct perf_tooltool;
+ struct perf_session *session;
+ boolshow_task_events;
+ boolshow_mmap_events;
+ boolshow_switch_events;
+};
+
+static void process_event(struct perf_script *script __maybe_unused, union
perf_event *event,
+ struct perf_sample *sample, struct perf_evsel *evsel,
+ struct addr_location *al)
{
struct thread *thread = al->thread;
struct perf_event_attr *attr = >attr;
@@ -663,12 +672,13 @@ static int cleanup_scripting(void)
return scripting_ops ? scripting_ops->stop_script() : 0;
}
-static int process_sample_event(struct perf_tool *tool __maybe_unused,
+static int process_sample_event(struct perf_tool *tool,
union perf_event *event,
struct perf_sample *sample,
struct perf_evsel *evsel,
struct machine *machine)
{
+ struct perf_script *scr = container_of(tool, struct perf_script, tool);
struct addr_location al;
if (debug_mode) {
@@ -697,21 +707,13 @@ static int process_sample_event(struct perf_tool *tool
__maybe_unused,
if (scripting_ops)
scripting_ops->process_event(event, sample, evsel, );
else
- process_event(event, sample, evsel, );
+ process_event(scr, event, sample, evsel, );
out_put:
addr_location__put();
return 0;
}
-struct perf_script {
- struct perf_tooltool;
- struct perf_session *session;
- boolshow_task_events;
- boolshow_mmap_events;
- boolshow_switch_events;
-};
-
static int process_attr(struct perf_tool *tool, union perf_event *event,
struct perf_evlist **pevlist)
{
--
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/core] perf script: Remove default_scripting_ops
Commit-ID: 2aaecfc51bc65532152e141df3268fda06cae029
Gitweb: http://git.kernel.org/tip/2aaecfc51bc65532152e141df3268fda06cae029
Author: Jiri Olsa
AuthorDate: Thu, 26 Nov 2015 14:55:23 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Nov 2015 13:33:00 -0300
perf script: Remove default_scripting_ops
The default script handler (the one that displays samples on screen) is
implemented scripting_ops instance with process_event callback.
This way we can't pass any script config into display function, because
we don't want perl or python handlers to be depended on perf script
internals.
Removing the default_scripting_ops and calling process event function
directly. This way it's possible to pass perf_script struct and process
configuration data in following commit.
Signed-off-by: Jiri Olsa
Acked-by: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1448546125-29245-1-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-script.c | 43 +++
1 file changed, 7 insertions(+), 36 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 72b5deb..8e3f804 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -643,57 +643,24 @@ static void process_event(union perf_event *event, struct
perf_sample *sample,
printf("\n");
}
-static int default_start_script(const char *script __maybe_unused,
- int argc __maybe_unused,
- const char **argv __maybe_unused)
-{
- return 0;
-}
-
-static int default_flush_script(void)
-{
- return 0;
-}
-
-static int default_stop_script(void)
-{
- return 0;
-}
-
-static int default_generate_script(struct pevent *pevent __maybe_unused,
- const char *outfile __maybe_unused)
-{
- return 0;
-}
-
-static struct scripting_ops default_scripting_ops = {
- .start_script = default_start_script,
- .flush_script = default_flush_script,
- .stop_script= default_stop_script,
- .process_event = process_event,
- .generate_script= default_generate_script,
-};
-
static struct scripting_ops*scripting_ops;
static void setup_scripting(void)
{
setup_perl_scripting();
setup_python_scripting();
-
- scripting_ops = _scripting_ops;
}
static int flush_scripting(void)
{
- return scripting_ops->flush_script();
+ return scripting_ops ? scripting_ops->flush_script() : 0;
}
static int cleanup_scripting(void)
{
pr_debug("\nperf script stopped\n");
- return scripting_ops->stop_script();
+ return scripting_ops ? scripting_ops->stop_script() : 0;
}
static int process_sample_event(struct perf_tool *tool __maybe_unused,
@@ -727,7 +694,11 @@ static int process_sample_event(struct perf_tool *tool
__maybe_unused,
if (cpu_list && !test_bit(sample->cpu, cpu_bitmap))
goto out_put;
- scripting_ops->process_event(event, sample, evsel, );
+ if (scripting_ops)
+ scripting_ops->process_event(event, sample, evsel, );
+ else
+ process_event(event, sample, evsel, );
+
out_put:
addr_location__put();
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tools: Correctly identify anon_hugepage when generating map (v2)
Commit-ID: b2be5451f660e0ee230969cc24121d9e210a91de
Gitweb: http://git.kernel.org/tip/b2be5451f660e0ee230969cc24121d9e210a91de
Author: Yannick Brosseau
AuthorDate: Thu, 26 Nov 2015 03:42:32 -0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Nov 2015 14:08:17 -0300
perf tools: Correctly identify anon_hugepage when generating map (v2)
When parsing /proc/xxx/maps, the sscanf in perf_event__synthesize_mmap_events
truncate the map name at the space in "/anon_hugepage (deleted)".
is_anon_memory() then only receives the string "/anon_hugepage" and does
not detect it. We change is_anon_memory() to only compare the first
part of the string, effectively ignoring if " (deleted)" is there.
Signed-off-by: Yannick Brosseau
Tested-by: Arnaldo Carvalho de Melo
Cc: Andi Kleen
Cc: Joshua Zhu
Cc: kernel-t...@fb.com
Link: http://lkml.kernel.org/r/1448538152-2898-1-git-send-email-scient...@fb.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/map.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index afc6b56..93d9f1c 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -26,8 +26,8 @@ const char *map_type__name[MAP__NR_TYPES] = {
static inline int is_anon_memory(const char *filename)
{
return !strcmp(filename, "//anon") ||
- !strcmp(filename, "/dev/zero (deleted)") ||
- !strcmp(filename, "/anon_hugepage (deleted)");
+ !strncmp(filename, "/dev/zero", sizeof("/dev/zero") - 1) ||
+ !strncmp(filename, "/anon_hugepage", sizeof("/anon_hugepage") -
1);
}
static inline int is_no_dso_memory(const char *filename)
--
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:x86/platform] x86/pm: Introduce quirk framework to save/ restore extra MSR registers around suspend/resume
Commit-ID: 7a9c2dd08eadd5c6943115dbbec040c38d2e0822
Gitweb: http://git.kernel.org/tip/7a9c2dd08eadd5c6943115dbbec040c38d2e0822
Author: Chen Yu
AuthorDate: Wed, 25 Nov 2015 01:03:41 +0800
Committer: Ingo Molnar
CommitDate: Thu, 26 Nov 2015 10:04:53 +0100
x86/pm: Introduce quirk framework to save/restore extra MSR registers around
suspend/resume
A bug was reported that on certain Broadwell platforms, after
resuming from S3, the CPU is running at an anomalously low
speed.
It turns out that the BIOS has modified the value of the
THERM_CONTROL register during S3, and changed it from 0 to 0x10,
thus enabled clock modulation(bit4), but with undefined CPU Duty
Cycle(bit1:3) - which causes the problem.
Here is a simple scenario to reproduce the issue:
1. Boot up the system
2. Get MSR 0x19a, it should be 0
3. Put the system into sleep, then wake it up
4. Get MSR 0x19a, it shows 0x10, while it should be 0
Although some BIOSen want to change the CPU Duty Cycle during
S3, in our case we don't want the BIOS to do any modification.
Fix this issue by introducing a more generic x86 framework to
save/restore specified MSR registers(THERM_CONTROL in this case)
for suspend/resume. This allows us to fix similar bugs in a much
simpler way in the future.
When the kernel wants to protect certain MSRs during suspending,
we simply add a quirk entry in msr_save_dmi_table, and customize
the MSR registers inside the quirk callback, for example:
u32 msr_id_need_to_save[] = {MSR_ID0, MSR_ID1, MSR_ID2...};
and the quirk mechanism ensures that, once resumed from suspend,
the MSRs indicated by these IDs will be restored to their
original, pre-suspend values.
Since both 64-bit and 32-bit kernels are affected, this patch
covers the common 64/32-bit suspend/resume code path. And
because the MSRs specified by the user might not be available or
readable in any situation, we use rdmsrl_safe() to safely save
these MSRs.
Reported-and-tested-by: Marcin Kaszewski
Signed-off-by: Chen Yu
Acked-by: Rafael J. Wysocki
Acked-by: Pavel Machek
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: b...@suse.de
Cc: len.br...@intel.com
Cc: li...@horizon.com
Cc: l...@kernel.org
Cc: r...@rjwysocki.net
Link:
http://lkml.kernel.org/r/c9abdcbc173dd2f57e8990e304376f19287e92ba.1448382971.git.yu.c.c...@intel.com
[ More edits to the naming of data structures. ]
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/msr.h| 10 +
arch/x86/include/asm/suspend_32.h | 1 +
arch/x86/include/asm/suspend_64.h | 1 +
arch/x86/power/cpu.c | 92 +++
4 files changed, 104 insertions(+)
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 77d8b28..24feb3c 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -32,6 +32,16 @@ struct msr_regs_info {
int err;
};
+struct saved_msr {
+ bool valid;
+ struct msr_info info;
+};
+
+struct saved_msrs {
+ unsigned int num;
+ struct saved_msr *array;
+};
+
static inline unsigned long long native_read_tscp(unsigned int *aux)
{
unsigned long low, high;
diff --git a/arch/x86/include/asm/suspend_32.h
b/arch/x86/include/asm/suspend_32.h
index d1793f0..8e9dbe7 100644
--- a/arch/x86/include/asm/suspend_32.h
+++ b/arch/x86/include/asm/suspend_32.h
@@ -15,6 +15,7 @@ struct saved_context {
unsigned long cr0, cr2, cr3, cr4;
u64 misc_enable;
bool misc_enable_saved;
+ struct saved_msrs saved_msrs;
struct desc_ptr gdt_desc;
struct desc_ptr idt;
u16 ldt;
diff --git a/arch/x86/include/asm/suspend_64.h
b/arch/x86/include/asm/suspend_64.h
index 7ebf0eb..6136a18 100644
--- a/arch/x86/include/asm/suspend_64.h
+++ b/arch/x86/include/asm/suspend_64.h
@@ -24,6 +24,7 @@ struct saved_context {
unsigned long cr0, cr2, cr3, cr4, cr8;
u64 misc_enable;
bool misc_enable_saved;
+ struct saved_msrs saved_msrs;
unsigned long efer;
u16 gdt_pad; /* Unused */
struct desc_ptr gdt_desc;
diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
index 9ab5279..d5f6499 100644
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86_32
__visible unsigned long saved_context_ebx;
@@ -32,6 +33,29 @@ __visible unsigned long saved_context_eflags;
#endif
struct saved_context saved_context;
+static void msr_save_context(struct saved_context *ctxt)
+{
+ struct saved_msr *msr = ctxt->saved_msrs.array;
+ struct saved_msr *end = msr + ctxt->saved_msrs.num;
+
+ while (msr < end) {
+ msr->valid = !rdmsrl_safe(msr->info.msr_no, >info.reg.q);
+ msr++;
+ }
+}
+
+static void msr_restore_context(struct saved_context *ctxt)
+{
+ struct saved_msr *msr =
[tip:perf/core] perf machine: Adjust dso-> long_name for offline module
Commit-ID: c03d5184f0e92fa696e4b57f54ffc3b19a92f704
Gitweb: http://git.kernel.org/tip/c03d5184f0e92fa696e4b57f54ffc3b19a92f704
Author: Wang Nan
AuthorDate: Thu, 26 Nov 2015 03:59:57 +
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Nov 2015 13:47:43 -0300
perf machine: Adjust dso->long_name for offline module
Something unexpected may happen if copy statically linked perf to a
production environment:
# ./perf probe -m ./mymodule.ko my_func
[mymodule] with build id 326ab42550ef3d24944f53c817533728367effeb not found,
continuing without symbols
Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
Error: Failed to add events.
# ./perf buildid-cache -a ./mymodule.ko
# ./perf probe -m ./mymodule.ko my_func
Added new event:
probe:my_func(on my_func in /home/wangnan/kmodule/mymodule.ko)
You can now use it in all perf tools, such as:
perf record -e probe:my_func -aR sleep 1
Where:
# ldd ./perf
not a dynamic executable
# strace -e open ./perf probe -m ./mymodule.ko my_func
...
open("/home/wangnan/kmodule/mymodule.ko", O_RDONLY) = 3
open("/home/wangnan/kmodule/../lib64/elfutils/libebl_x86_64.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...
open("/lib64/tls/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
open("/lib64/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
open("/usr/lib64/tls/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
such file or directory)
open("/usr/lib64/libebl_x86_64.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
open("[mymodule]", O_RDONLY)= -1 ENOENT (No such file or
directory)
open("/home/wangnan/.debug/.build-id/32/6ab42550ef3d24944f53c817533728367effeb",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("[mymodule]", O_RDONLY)= -1 ENOENT (No such file or
directory)
In the above example, probe fails before we put the module into
buildid-cache. However, user would expect it success in both case
because perf is able to find probe points actually.
The reason is because perf won't utilize module's full path if it failed
to open debuginfo. In:
convert_to_probe_trace_events ->
find_probe_trace_events_from_map ->
get_target_map ->
kernel_get_module_map ->
machine__findnew_module_map ->
map_groups__find_by_name
map_groups__find_by_name() is able to find the map of that module, but
this information is found from /proc/module before it knows the real
path of the offline module. Therefore, the map->dso->long_name is set to
something like '[mymodule]', which prevent dso__load() find the real
path of the module file.
In another aspect, if dso__load() can get the offline module through
buildid cache, it can read symble table from that ko. Even if debuginfo
is not available, 'perf probe' can success if the '.symtab' can be
found.
This patch improves machine__findnew_module_map(): when dso->long_name
is leading with '[' (doesn't find path of module when parsing
/proc/modules), fixes it by dso__set_long_name(), so following
dso__load() is possible to find the symbol table.
This patch won't interfere with buildid matching. Here is the test
result:
# ./perf probe -m ./mymodule.ko my_func
Added new event:
probe:my_func(on my_func in /home/wangnan/kmodule/mymodule.ko)
You can now use it in all perf tools, such as:
perf record -e probe:my_func -aR sleep 1
# ./perf probe -d '*'
Removed event: probe:my_func
# mv ./mymodule.{ko,.bak}
# mv ./moduleb.ko mymodule.ko
# ./perf probe -m ./mymodule.ko my_func
/home/wangnan/kmodule/mymodule.ko with build id
326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
Error: Failed to add events.
# ./perf probe -v -m ./mymodule.ko my_func
probe-definition(0): my_func
symbol:my_func file:(null) line:0 offset:0 return:0 lazy:(null)
0 arguments
Could not open debuginfo. Try to use symbols.
symsrc__init: build id mismatch for /home/wangnan/kmodule/mymodule.ko.
/home/wangnan/kmodule/mymodule.ko with build id
326ab42550ef3d24944f53c817533728367effeb not found, continuing without symbols
Failed to find symbol my_func in /home/wangnan/kmodule/mymodule.ko
Error: Failed to add events. Reason: No such file or directory (Code: -2)
Signed-off-by: Wang Nan
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/r/1448510397-187965-1-git-send-email-wangn...@huawei.com
[ Renamed adjust_dso_long_name() do dso__adjust_kmod_long_name() ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/machine.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/machine.c
[tip:perf/core] perf top: Fix freeze on --call-graph flat/folded
Commit-ID: 0356218a68551f051998f4fb5074a1eed7a346fe
Gitweb: http://git.kernel.org/tip/0356218a68551f051998f4fb5074a1eed7a346fe
Author: Namhyung Kim
AuthorDate: Thu, 26 Nov 2015 16:08:18 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Nov 2015 13:32:08 -0300
perf top: Fix freeze on --call-graph flat/folded
The callchain rbtree is rebuilt periodically, so it needs to
reinitialize the root everytime. Otherwise it can be stuck in the
rbtree insertion with stale pointers.
Signed-off-by: Namhyung Kim
Cc: Andi Kleen
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Kan Liang
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1448521700-32062-1-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/callchain.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index fc3b1e0..564377d 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -290,6 +290,7 @@ static void
sort_chain_flat(struct rb_root *rb_root, struct callchain_root *root,
u64 min_hit, struct callchain_param *param __maybe_unused)
{
+ *rb_root = RB_ROOT;
__sort_chain_flat(rb_root, >node, min_hit);
}
--
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/core] perf build: Fix traceevent plugins build race
Commit-ID: 67befc652845c8ffbefc8d173a6e6ced14d472f1 Gitweb: http://git.kernel.org/tip/67befc652845c8ffbefc8d173a6e6ced14d472f1 Author: Jiri Olsa AuthorDate: Thu, 26 Nov 2015 14:54:04 +0100 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 26 Nov 2015 13:35:38 -0300 perf build: Fix traceevent plugins build race Ingo reported following build failure: $ make clean install ... CC plugin_kmem.o fixdep: error opening depfile: ./.plugin_hrtimer.o.d: No such file or directory /home/mingo/tip/tools/build/Makefile.build:77: recipe for target 'plugin_hrtimer.o' failed make[3]: *** [plugin_hrtimer.o] Error 2 Makefile:189: recipe for target 'plugin_hrtimer-in.o' failed make[2]: *** [plugin_hrtimer-in.o] Error 2 Makefile.perf:414: recipe for target 'libtraceevent_plugins' failed make[1]: *** [libtraceevent_plugins] Error 2 make[1]: *** Waiting for unfinished jobs Currently we have the install-traceevent-plugins target being dependent on $(LIBTRACEEVENT), which will actualy not build any plugin. So the install-traceevent-plugins target itself will try to build plugins, but.. Plugins built is also triggered by perf build itself via libtraceevent_plugins target. This might cause a race having one make thread removing temp files from another and result in above error. Fixing this by having proper plugins build dependency before installing plugins. Reported-and-Tested-by:: Ingo Molnar Signed-off-by: Jiri Olsa Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1448546044-28973-3-git-send-email-jo...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Makefile.perf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 0d19d54..929a32b 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -420,7 +420,7 @@ $(LIBTRACEEVENT)-clean: $(call QUIET_CLEAN, libtraceevent) $(Q)$(MAKE) -C $(TRACE_EVENT_DIR) O=$(OUTPUT) clean >/dev/null -install-traceevent-plugins: $(LIBTRACEEVENT) +install-traceevent-plugins: libtraceevent_plugins $(Q)$(MAKE) -C $(TRACE_EVENT_DIR) $(LIBTRACEEVENT_FLAGS) O=$(OUTPUT) install_plugins $(LIBAPI): fixdep FORCE -- 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/core] perf callchain: Honor hide_unresolved
Commit-ID: b49a8fe52626814968b9a9d27d7ad1cadc5532ed
Gitweb: http://git.kernel.org/tip/b49a8fe52626814968b9a9d27d7ad1cadc5532ed
Author: Namhyung Kim
AuthorDate: Thu, 26 Nov 2015 16:08:20 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 26 Nov 2015 13:19:39 -0300
perf callchain: Honor hide_unresolved
If user requested to hide unresolved entries, skip unresolved callchains
as well as hist entries.
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: Andi Kleen
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Kan Liang
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1448521700-32062-3-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 7 +++
tools/perf/util/machine.c | 5 +
tools/perf/util/symbol.h| 3 ++-
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 1442834..8a9c690 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -45,7 +45,6 @@ struct report {
struct perf_tooltool;
struct perf_session *session;
booluse_tui, use_gtk, use_stdio;
- boolhide_unresolved;
booldont_use_callchains;
boolshow_full_info;
boolshow_threads;
@@ -146,7 +145,7 @@ static int process_sample_event(struct perf_tool *tool,
struct hist_entry_iter iter = {
.evsel = evsel,
.sample = sample,
- .hide_unresolved= rep->hide_unresolved,
+ .hide_unresolved= symbol_conf.hide_unresolved,
.add_entry_cb = hist_iter__report_callback,
};
int ret = 0;
@@ -157,7 +156,7 @@ static int process_sample_event(struct perf_tool *tool,
return -1;
}
- if (rep->hide_unresolved && al.sym == NULL)
+ if (symbol_conf.hide_unresolved && al.sym == NULL)
goto out_put;
if (rep->cpu_list && !test_bit(sample->cpu, rep->cpu_bitmap))
@@ -740,7 +739,7 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_STRING_NOEMPTY('t', "field-separator", _conf.field_sep,
"separator",
"separator for columns, no spaces will be added between "
"columns '.' is reserved."),
- OPT_BOOLEAN('U', "hide-unresolved", _unresolved,
+ OPT_BOOLEAN('U', "hide-unresolved", _conf.hide_unresolved,
"Only display entries resolved to a symbol"),
OPT_STRING(0, "symfs", _conf.symfs, "directory",
"Look for files with symbols relative to this directory"),
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 7f5071a..f0019b7 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1618,6 +1618,8 @@ static int add_callchain_ip(struct thread *thread,
}
}
+ if (symbol_conf.hide_unresolved && al.sym == NULL)
+ return 0;
return callchain_cursor_append(_cursor, al.addr, al.map,
al.sym);
}
@@ -1872,6 +1874,9 @@ check_calls:
static int unwind_entry(struct unwind_entry *entry, void *arg)
{
struct callchain_cursor *cursor = arg;
+
+ if (symbol_conf.hide_unresolved && entry->sym == NULL)
+ return 0;
return callchain_cursor_append(cursor, entry->ip,
entry->map, entry->sym);
}
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index dcd786e..857f707 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -108,7 +108,8 @@ struct symbol_conf {
show_hist_headers,
branch_callstack,
has_filter,
- show_ref_callgraph;
+ show_ref_callgraph,
+ hide_unresolved;
const char *vmlinux_name,
*kallsyms_name,
*source_prefix,
--
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/
From Office Of Mr. James Dimon CEO
>From Office Of Mr. James Dimon CEO JP Morgan Chase Bank Wa1-2213 5508n Division St Spokane, WA 99208 Direct Tele: Number: (509) 592-9622 Fax 630-733-6138 My office e-mail: customerc...@jpchaseinfo.com chasebank43...@gmail.com DATE: 11 / 26 / 2015 Urgent Attention My Dear Friend, How are you today? hope fine. well my dear, this is to let you know that this fund was Approved in the name of one Melo one of our contractors that have not recieve their contract payment, but from the information we recieved telling us that Mr Robert J Penalva is no more alive to claim his contract fund worth of usd$5,000 000 00 only Now my dear, i will like you to make this as a deal between you and i for me to make sure that this fund. My dear this is to let you know that after our board meeting last week Friday, the JP Morgan Chase Bank wishes to inform Mr Robert J Penalva that we have come to conclusion that we really need to set up an online account in the name of Beneficiary here in our Bank so that Chase Bank can credit your online account with your Fund valued Usd$5,000.000.00 (Five Million United States Dollars) immediately and give you the online details which you can view your account information's to see your Fund and make transfer of your Fund to any bank of your choice you can call to speak with Customer careline 509 592-9622 Chase Bank. Now what i like you to know is that everything in regards of the transfer of this fund into your online account with JP Morgan Chase Bank will be made here at my office as the Executive Chairman, Chief Executive Officer, President Mr. James Dimon CEO before i will forward the transfer order to the Key Tested Telex Transfer Department of this Bank for immediate transfer of this fund into your online account. To enable me carry on the process of transfer of this fund in your favour, i will like you to send the following information to me. 1) Your full name. 2) Phone, fax and mobile#. 3) Company name and address. 4) Profession, age and marital status. Scan Copy of your ID Card. Please my dear make sure you forward all these to me for it will enable us tramsfer this fund to you without any further delay, meanwhile after the transfer of this fund into your online account, we are going to share the money You 70% Me 30% NEXT OF KIN and i will come over to your country to invest my own share ok. This transaction is 100% risk free and i will like you to keep it so confidencial untill the transfer take place and also give me all your attention to make this transaction a suceess. Meanwhile view the attachment file for my international passport and official working identity Card for your clearification. This is information of Name Mr Robert J Penalva Address 429 w. Doncrest St. Monterey Park, CA. 91754-5522 And Number 323304-8335 And E-mail address pena...@pacbell.ne Get back to me immediately you recieve this mail for unward transaction. Waiting for your Urgent respons. Thanks. Mr. Jamie Dimon.Executive Chairman, Chief Executive Officer, President and Member of Operating Committee, JPMorgan Chase & Co Chase Bank is a full service financial firm and the largest U.S -- 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: kernel: stop_machine: report (un)dead code (and feedback request)
* Chris Wilson wrote:
> On Thu, Nov 26, 2015 at 03:45:59PM +0100, Valentin Rothberg wrote:
> > Hi Chris,
> >
> > your commit 4c477de14237 ("kernel: remove stop_machine() Kconfig
> > dependency") has shown up in today's linux-next tree (20151126).
> > The commit changes the #ifdef condition in kernel/stop_machine.c
> > from/to:
> >
> > -#if defined(CONFIG_STOP_MACHINE) && defined(CONFIG_SMP)
> > +#if defined(CONFIG_SMP) || defined(CONFIG_HOTPLUG_CPU)
> >
> > Although this change fixes certain configs on X86, the condition now is
> > a tautology since CONFIG_SMP is already required to compile the file:
> >
> > kernel/Makefile:65:obj-$(CONFIG_SMP) += stop_machine.o
> >
> > AFAIU, we can safely remove this #ifdef?
>
> That seems logical. The argument in favour of it would be to keep the
> ifdeffery around the function defintion the same as the function
> declaration in stop_machine.h.
But this would introduce a bit of fragility: we could re-introduce the same
regression that the commit fixes, if we ever changed the SMP dependency for
stop_machine.c.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] x86: mm: clean up probe_memory_block_size()
* Seth Jennings wrote:
> v2:
> remove local bz variable (Ingo) and debug message since, if
> the 2GB message doesn't print, there is only one possible
> block size.
I'd not remove the info message, it would print the memory block size
regardless
of memory size. Yes, one could decode the 'no message' case as 'the kernel used
the default value' - but that's very version dependent and obscure in any case.
Please keep the debug message in both code paths, like the original code had it.
But, on a second thought, I'd definitely harmonize the messages, instead of:
> pr_info("Using 2GB memory block size for large-memory
> system\n");
> printk(KERN_DEBUG "memory block size : %ldMB\n", bz >> 20);
I'd print:
> pr_info("x86/mm: Memory block size: 2GB, large-memory
> system\n");
> pr_info("x86/mm: Memory block size: %ldMB\n", bz >> 20);
Also note how I changed both printouts to pr_info(), so that we have the memory
block size information printed unconditionally.
(And btw., doing this printout means that we should keep the 'bz' local
variable.)
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/2] drm: add support for for clk and de polarity
On 26/11/15 16:20, Manfred Schlaegl wrote: > On 2015-11-25 18:22, Philipp Zabel wrote: >> Am Mittwoch, den 15.07.2015, 17:50 +0200 schrieb Manfred Schlaegl: >>> To get full support for parallel and LVDS displays with drm: >>> Add representation for clock and data enable polarity in drm_display_mode >>> flags (similar to HSYNC/VSYNC polarity) and update conversion functions >>> from/to videomode accordingly. >>> >>> This is especially important for embedded devices where parallel(RGB) and >>> LVDS displays are still widely used and drm already plays an important >>> role. >>> >>> Tested on Freescale i.MX53(parallel) and i.MX6(LVDS). >>> >>> Background: >>> There was the ability to set polarity of clock and data enable signals >>> in devicetree(display-timing), struct display_timing and struct videomode, >>> but there was no representation for this in struct drm_display_mode. >>> Example on Freescale i.MX53/i.MX6 SoC's: >>> * A parallel display using different clock polarity is set up using >>>display-timing in devicetree >>> * ipuv3 parallel outputs clock with wrong polarity >>> >>> Signed-off-by: Manfred Schlaegl >> >> Any comments on whether data enable and pixel clock polarity flags can >> be added to the visible DRM_MODE_FLAGs, and if not, where else this >> information should be kept? struct drm_display_info? >> >> This patch and the following IPUv3 patch are useful and necessary for >> quite some panels connected to i.MX SoCs, but adding DRM_MODE_FLAGs is >> somewhat out of my jurisdiction. >> >> best regards >> Philipp >> > > Good to see that this discussion is triggered. I seem to have missed this one. This is important for omapdrm also. We've had similar patch in TI's linux for a while, but I have never had time to start upstreaming it. Two comments: The "pixclock polarity" could be explained a bit, as it's not really about polarity. This was discussed when the display-timings stuff was worked on, and display-timings.txt explains what the "pixelclk-active" property means. So here I think you could maybe have a comment pointing to display-timings.txt, or perhaps a short comment about what the flag is. Or if you come up with a great name for the define, that's good too =). The other comment is not about this patch as such, but similar flags that OMAP has, and possibly some other platforms too: 1) sync signals driven on rising or falling edge of pixel clock 2) hsync and vsync happen at the same time or hsync happens first, followed by vsync Any other platforms have similar features? Tomi signature.asc Description: OpenPGP digital signature
[PATCH 1/2] staging: most: return error value
On error we were returning retval, but retval is not having the error
value. We will get the error value using PTR_ERR.
Signed-off-by: Sudip Mukherjee
---
This series doesnot depend on my earlier pending series.
drivers/staging/most/aim-cdev/cdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/most/aim-cdev/cdev.c
b/drivers/staging/most/aim-cdev/cdev.c
index dc3fb25..3f7c8bb 100644
--- a/drivers/staging/most/aim-cdev/cdev.c
+++ b/drivers/staging/most/aim-cdev/cdev.c
@@ -468,8 +468,8 @@ static int aim_probe(struct most_interface *iface, int
channel_id,
NULL,
"%s", name);
- retval = IS_ERR(channel->dev);
- if (retval) {
+ if (IS_ERR(channel->dev)) {
+ retval = PTR_ERR(channel->dev);
pr_info("failed to create new device node %s\n", name);
goto error_create_device;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] staging: most: avoid assignment in if
checkpatch is giving a warning about an assignment in the if condition.
The assignment was there as the valid mbo pointer was used after we have
woken up from wait_event_interruptible(). Now even though we donot
assign the pointer to mbo but we will still be able to get the valid
pointer for later use.
Signed-off-by: Sudip Mukherjee
---
drivers/staging/most/aim-cdev/cdev.c | 10 +-
drivers/staging/most/aim-network/networking.c | 2 +-
drivers/staging/most/aim-sound/sound.c| 4 ++--
drivers/staging/most/hdm-dim2/dim2_hdm.c | 2 +-
drivers/staging/most/mostcore/core.c | 3 ++-
drivers/staging/most/mostcore/mostcore.h | 2 +-
6 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/most/aim-cdev/cdev.c
b/drivers/staging/most/aim-cdev/cdev.c
index 3f7c8bb..ff35967 100644
--- a/drivers/staging/most/aim-cdev/cdev.c
+++ b/drivers/staging/most/aim-cdev/cdev.c
@@ -168,17 +168,17 @@ static ssize_t aim_write(struct file *filp, const char
__user *buf,
}
mutex_unlock(>io_mutex);
- mbo = most_get_mbo(channel->iface, channel->channel_id, _aim);
+ mbo = most_get_mbo(channel->iface, channel->channel_id,
+ _aim, );
if (!mbo) {
if ((filp->f_flags & O_NONBLOCK))
return -EAGAIN;
if (wait_event_interruptible(
channel->wq,
- (mbo = most_get_mbo(channel->iface,
- channel->channel_id,
- _aim)) ||
- (!channel->dev)))
+ most_get_mbo(channel->iface, channel->channel_id,
+_aim, )) ||
+ (!channel->dev))
return -ERESTARTSYS;
}
diff --git a/drivers/staging/most/aim-network/networking.c
b/drivers/staging/most/aim-network/networking.c
index 3c7beb0..84678bb 100644
--- a/drivers/staging/most/aim-network/networking.c
+++ b/drivers/staging/most/aim-network/networking.c
@@ -241,7 +241,7 @@ static netdev_tx_t most_nd_start_xmit(struct sk_buff *skb,
BUG_ON(nd->dev != dev);
- mbo = most_get_mbo(nd->iface, nd->tx.ch_id, );
+ mbo = most_get_mbo(nd->iface, nd->tx.ch_id, , );
if (!mbo) {
netif_stop_queue(dev);
diff --git a/drivers/staging/most/aim-sound/sound.c
b/drivers/staging/most/aim-sound/sound.c
index 9c64580..f5d5d87 100644
--- a/drivers/staging/most/aim-sound/sound.c
+++ b/drivers/staging/most/aim-sound/sound.c
@@ -240,8 +240,8 @@ static int playback_thread(void *data)
channel->playback_waitq,
kthread_should_stop() ||
(channel->is_stream_running &&
-(mbo = most_get_mbo(channel->iface, channel->id,
-_aim;
+most_get_mbo(channel->iface, channel->id,
+ _aim, )));
if (!mbo)
continue;
diff --git a/drivers/staging/most/hdm-dim2/dim2_hdm.c
b/drivers/staging/most/hdm-dim2/dim2_hdm.c
index 327d738..ef0ca59 100644
--- a/drivers/staging/most/hdm-dim2/dim2_hdm.c
+++ b/drivers/staging/most/hdm-dim2/dim2_hdm.c
@@ -667,7 +667,7 @@ static void request_netinfo(struct most_interface
*most_iface, int ch_idx)
return;
}
- mbo = most_get_mbo(>most_iface, dev->atx_idx, NULL);
+ mbo = most_get_mbo(>most_iface, dev->atx_idx, NULL, );
if (!mbo)
return;
diff --git a/drivers/staging/most/mostcore/core.c
b/drivers/staging/most/mostcore/core.c
index ed1ed25..535c79b 100644
--- a/drivers/staging/most/mostcore/core.c
+++ b/drivers/staging/most/mostcore/core.c
@@ -1412,7 +1412,7 @@ EXPORT_SYMBOL_GPL(channel_has_mbo);
* Returns a pointer to MBO on success or NULL otherwise.
*/
struct mbo *most_get_mbo(struct most_interface *iface, int id,
-struct most_aim *aim)
+struct most_aim *aim, struct mbo **mbo_p)
{
struct mbo *mbo;
struct most_c_obj *c;
@@ -1446,6 +1446,7 @@ struct mbo *most_get_mbo(struct most_interface *iface,
int id,
mbo->num_buffers_ptr = num_buffers_ptr;
mbo->buffer_length = c->cfg.buffer_size;
+ *mbo_p = mbo;
return mbo;
}
EXPORT_SYMBOL_GPL(most_get_mbo);
diff --git a/drivers/staging/most/mostcore/mostcore.h
b/drivers/staging/most/mostcore/mostcore.h
index bda3850..a8957f5 100644
--- a/drivers/staging/most/mostcore/mostcore.h
+++ b/drivers/staging/most/mostcore/mostcore.h
@@ -308,7 +308,7 @@ void most_resume_enqueue(struct most_interface *iface, int
channel_idx);
int most_register_aim(struct most_aim *aim);
int most_deregister_aim(struct most_aim *aim);
struct mbo *most_get_mbo(struct most_interface *iface,
Re: [tpmdd-devel] [PATCH] base/platform: fix panic when probe function is NULL
On Do, 2015-11-26 at 13:30 -0700, Jason Gunthorpe wrote: > On Thu, Nov 26, 2015 at 08:01:34PM +0100, martin.wi...@ts.fujitsu.com wrote: > > From: Martin Wilck > > > > Since b8b2c7d845d5, platform_drv_probe() is called for all platform > > devices. If drv->probe is NULL, and dev_pm_domain_attach() fails, > > platform_drv_probe() will return the error code from dev_pm_domain_attach(). > > > > This causes real_probe() to enter the "probe_failed" path and set > > dev->driver to NULL. Before b8b2c7d845d5, real_probe() would assume > > success if both dev->bus->probe and drv->probe are missing. > > > > This may cause a panic later. For example, inserting the tpm_tis > > driver with parameter "force=1" (i.e. registering tpm_tis as a platform > > driver) will panic in tpmm_chip_alloc() because dev->driver is NULL: > > > > chip->cdev.owner = chip->pdev->driver->owner; > > Is this happening because tpm_tis is not creating the platform device > properly? ie it just calls platform_device_register_simple and then > force initializes it via tpm_tis_init, which expects to be called from > a probe function with an attached driver. > > Instead we should setup a proper platform device with the default > IO range for x86 and let the driver core call tpm_tis_init via > tis_drv.probe. > > Would changing things in this way fix the problem you've observed? I think so. Nonetheless, patch b8b2c7d845d5 introduced a change in the way platform device registration behaves. The platform device code seems to be prepared for cases where platform_driver->probe == NULL, so that case should be handled gracefully. Otherwise, failure should occur earlier, e.g. when platform_driver_register() is called with platform_driver->probe == NULL. tpm_tis may not be the only driver that uses platform_device_register_simple() in this way. > I have some patches to do this that are part of my OF enablement > series, but I can make something simpler that would deal with this > fairly quickly if you can test. Let's first wait what the platform guys say. Martin
Re: [PATCH 07/16] perf tools: Add API to config maps in bpf object
On 2015/11/24 21:36, Wang Nan wrote:
bpf__config_obj() is introduced as a core API to config BPF object
after loading. One configuration option of maps is introduced. After
this patch BPF object can accept configuration like:
maps:my_map:value=1234
(maps.my_map.value looks pretty. However, there's a small but hard
to fixed problem related to flex's greedy matching. Please see [1].
Choose ':' to avoid it in a simpler way.)
This patch is more complex than the work it really does because the
consideration of extension. In designing of BPF map configuration,
following things should be considered:
1. Array indics selection: perf should allow user setting different
value to different slots in an array, with syntax like:
maps:my_map:value[0,3...6]=1234;
2. A map can be config by different config terms, each for a part
of it. For example, set each slot to pid of a thread;
3. Type of value: integer is not the only valid value type. Perf
event can also be put into a map after commit 35578d7984003097af2b1e3
(bpf: Implement function bpf_perf_event_read() that get the selected
hardware PMU conuter);
4. For hash table, it is possible to use string or other as key;
5. It is possible that map configuration is unable to be setup
during parsing. Perf event is an example.
Therefore, this patch does following:
1. Instead of updating map element during parsing, this patch stores
map config options in 'struct bpf_map_priv'. Following patches
would apply those configs at proper time;
2. Link map operations to a list so a map can have multiple config
terms attached, so different parts can be configured separately;
3. Make 'struct bpf_map_priv' extensible so following patches can
add new types of keys and operations;
4. Use bpf_config_map_funcs array to support more maps config options.
Since the patch changing event parser to parse BPF object config is
relative large, I put in another commit. Code in this patch
could be tested after applying next patch.
[1] http://lkml.kernel.org/g/564ed621.4050...@huawei.com
Signed-off-by: Wang Nan
Signed-off-by: He Kuang
Cc: Alexei Starovoitov
Cc: Arnaldo Carvalho de Melo
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: pi3or...@163.com
---
tools/perf/util/bpf-loader.c | 255 +++
tools/perf/util/bpf-loader.h | 38 +++
2 files changed, 293 insertions(+)
diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index e8325a6..0cb94bc 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -739,6 +739,240 @@ int bpf__foreach_tev(struct bpf_object *obj,
return 0;
}
+enum bpf_map_op_type {
+ BPF_MAP_OP_SET_VALUE,
+};
+
+enum bpf_map_key_type {
+ BPF_MAP_KEY_ALL,
+};
+
+struct bpf_map_op {
+ struct list_head list;
+ enum bpf_map_op_type op_type;
+ enum bpf_map_key_type key_type;
+ union {
+ u64 value;
+ } v;
+};
+
+struct bpf_map_priv {
+ struct list_head ops_list;
+};
+
+static void
+bpf_map_op__free(struct bpf_map_op *op)
+{
+ if (!list_is_singular(>list))
This seems incorrect. bpf_map_op__free() should consider
following cases:
1. When the op is created but not linked to any list:
impossible. In bpf_map_op__alloc() it would be freed
directly;
2. Normal case, when the op is linked to a list;
3. After the op has already be removed.
list_is_singular() tests whether a list has only one entry. This is not
belone to any of the above cases.
Will change to:
if ((op->list.next != LIST_POISON1) && (op->list.prev !=
LIST_POISON2))
list_del(>list);
+ list_del(>list);
+ free(op);
+}
+
+static void
+bpf_map_priv__clear(struct bpf_map *map __maybe_unused,
+ void *_priv)
+{
+ struct bpf_map_priv *priv = _priv;
+ struct bpf_map_op *pos, *n;
+
+ list_for_each_entry_safe(pos, n, >ops_list, list)
+ bpf_map_op__free(pos);
+ free(priv);
+}
+
+static struct bpf_map_op *
+bpf_map_op__alloc(struct bpf_map *map)
+{
+ struct bpf_map_op *op;
+ struct bpf_map_priv *priv;
+ const char *map_name;
+ int err;
+
+ map_name = bpf_map__get_name(map);
+ err = bpf_map__get_private(map, (void **));
+ if (err) {
+ pr_debug("Failed to get private from map %s\n", map_name);
+ return ERR_PTR(err);
+ }
+
+ if (!priv) {
+ priv = zalloc(sizeof(*priv));
+ if (!priv) {
+ pr_debug("No enough memory to alloc map private\n");
+ return ERR_PTR(-ENOMEM);
+ }
+ INIT_LIST_HEAD(>ops_list);
+
+ if (bpf_map__set_private(map, priv, bpf_map_priv__clear)) {
+ free(priv);
+ return ERR_PTR(-BPF_LOADER_ERRNO__INTERNAL);
+
Re: [PATCH 12/16] perf tools: Support setting different slots in a BPF map separately
On 2015/11/24 21:36, Wang Nan wrote:
This patch introduces basic facilities to support config different
slots in a BPF map one by one.
array.nr_ranges and array.ranges are introduced into 'struct
parse_events_term', where ranges is an array of indices range (start,
length) which will be configured by this config term. nr_ranges
is the size of the array. The array is passed to 'struct bpf_map_priv'.
To indicate the new type of configuration, BPF_MAP_KEY_RANGES is
added as a new key type. bpf_map_config_foreach_key() is extended to
iterate over those indices instead of all possible keys.
Code in this commit will be enabled by following commit which enables
the indices syntax for array configuration.
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Arnaldo Carvalho de Melo
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: pi3or...@163.com
---
tools/perf/util/bpf-loader.c | 133 ++---
tools/perf/util/bpf-loader.h | 1 +
tools/perf/util/parse-events.c | 33 +-
tools/perf/util/parse-events.h | 12
4 files changed, 171 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index a6e4bde..185d2cf 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
[SNIP]
+static int
+bpf_map_op_setkey(struct bpf_map_op *op, struct parse_events_term *term,
+ const char *map_name)
+{
+ op->key_type = BPF_MAP_KEY_ALL;
+
+ if (term->array.nr_ranges) {
+ size_t memsz = term->array.nr_ranges *
+ sizeof(op->k.array.ranges[0]);
+
+ op->k.array.ranges = malloc(memsz);
+ if (!op->k.array.ranges) {
+ pr_debug("No enough memory to alloc indices for %s\n",
+map_name);
+ return -ENOMEM;
+ }
+ memcpy(op->k.array.ranges, term->array.ranges, memsz);
Here can use memdup.
+ op->key_type = BPF_MAP_KEY_RANGES;
+ op->k.array.nr_ranges = term->array.nr_ranges;
+ }
+ return 0;
+}
+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 00/13] perf/core improvements and fixes
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > > The following changes since commit a95a49fa0cc5eec730d8703b1544fa7ea6a11dec: > > Merge tag 'perf-core-for-mingo-2' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core > (2015-11-26 09:13:50 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-core-for-mingo > > for you to fetch changes up to 43798bf37215fe242e592fd4605d804e2da0781b: > > bpf tools: Add helper function for updating bpf maps elements (2015-11-26 > 17:21:24 -0300) > > > perf/core improvements and fixes: > > User visible: > > - Add 'vmlinux.debug' to the vmlinux seach path (Ekaterina Tumanova) > > - Do not show sample_(type|period) in the perf_event_attr dump when using > -v with 'perf stat' (Jiri Olsa) > > - Display the WEIGHT sample bit, when set, in 'perf evlist -v' (Jiri Olsa) > > - Honour --hide-unresolved in 'report', will honour it as well in 'top' > when --hide-unresolved gets supported in that tool (Namhyung Kim) > > - Fix freeze wit h--call-graph 'flat/folded' due to not properly > reinitializing the callchain rb_tree (Namhyumg Kim) > > - Set dso->long_name when a module name is passed as a parameter > to tools like 'perf probe' but the 'struct dso' associated to that module > still doesn't have the full path for the module, just the '[name]' one > obtained from /proc/modules (Wang Nan) > > - Fix anon_hugepage mmaps detection using scanf on /proc/PID/smaps (Yannick > Brosseau) > > Infrastructure: > > - Add helper function for updating bpf maps elements (He Kuang) > > - Fix traceevents plugins build race (Jiri Olsa) > > - Add the $OUTPUT path prefix with 'fixdep' (Jiri Olsa) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Ekaterina Tumanova (2): > perf symbols: Refactor vmlinux_path__init() to ease path additions > perf symbols: Add the path to vmlinux.debug > > He Kuang (1): > bpf tools: Add helper function for updating bpf maps elements > > Jiri Olsa (6): > perf script: Remove default_scripting_ops > perf build: Fix traceevent plugins build race > perf script: Pass perf_script into process_event > tools build: Use fixdep with OUTPUT path prefix > perf stat: Clear sample_(type|period) for counting > perf evlist: Display WEIGHT sample type bit > > Namhyung Kim (2): > perf callchain: Honor hide_unresolved > perf top: Fix freeze on --call-graph flat/folded > > Wang Nan (1): > perf machine: Adjust dso->long_name for offline module > > Yannick Brosseau (1): > perf tools: Correctly identify anon_hugepage when generating map (v2) > > tools/build/Makefile | 2 +- > tools/build/Makefile.include | 2 +- > tools/lib/bpf/bpf.c | 14 + > tools/lib/bpf/bpf.h | 2 ++ > tools/perf/Makefile.perf | 2 +- > tools/perf/builtin-report.c | 7 ++--- > tools/perf/builtin-script.c | 67 > +--- > tools/perf/builtin-stat.c| 7 + > tools/perf/util/callchain.c | 1 + > tools/perf/util/evsel.c | 1 + > tools/perf/util/machine.c| 32 - > tools/perf/util/map.c| 4 +-- > tools/perf/util/symbol.c | 65 ++ > tools/perf/util/symbol.h | 3 +- > 14 files changed, 120 insertions(+), 89 deletions(-) Pulled, thanks a lot Arnaldo! 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] driver:dma bug_fix : access freed memory
On Fri, Nov 27, 2015 at 05:44:53AM +, 김정배 wrote: > From 8f6aeb362d9e44f29d46ae7694cdfee4408406ce Mon Sep 17 00:00:00 2001 > From: "KIM JUGNBAE" > Date: Thu, 26 Nov 2015 16:28:47 +0900 > Subject: [PATCH] bug_fix : access freed memory This part should not be present in the patch. > > sync_fenc_free & fence_check_cb_func would be executed at > other cpu. fence_check_cb_func access freed fence memory after > kfree(fence) at sync_fence_free. > To escaped this issue, atomic_read(>status) need to be > protected by child_list_lock. > > Signed-off-by: "kimjungbae\" " " The From name and the Signed-off-by name shouls be same. Mayvbe you can consider having Kim Jugnbae (or Jungbae) as both. > --- > drivers/dma-buf/fence.c | 13 + > drivers/staging/android/sync.c | 10 +++--- > drivers/staging/android/sync_debug.c |2 ++ > include/linux/fence.h|1 + > 4 files changed, 23 insertions(+), 3 deletions(-) Usually staging patches can not touch anything outside staging. regards sudip -- 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 3/5] clk: sunxi: Add sun9i A80 cpus (cpu special) clock support
On Thu, Nov 26, 2015 at 1:32 AM, Maxime Ripard wrote: > Hi, > > On Tue, Nov 24, 2015 at 05:32:14PM +0800, Chen-Yu Tsai wrote: >> The "cpus" clock is the clock for the embedded processor in the A80. >> It is also part of the PRCM clock tree. This clock includes a pre- >> divider on one of its inputs. For now we are using a custom clock >> driver for it. In the future we may want to develop a generalized >> driver for these types of clocks, which also includes the AHB clock >> driver on sun[5678]i. >> >> Signed-off-by: Chen-Yu Tsai >> --- >> >> Hi Maxime, >> >> I'll do the factors clock refactoring mentioned during the discussion >> around v2 later on. > > I have no idea what you are talking about :) Then I guess I have more time to figure something out. :) >> >> --- >> Documentation/devicetree/bindings/clock/sunxi.txt | 1 + >> drivers/clk/sunxi/Makefile| 1 + >> drivers/clk/sunxi/clk-sun9i-cpus.c| 240 >> ++ >> 3 files changed, 242 insertions(+) >> create mode 100644 drivers/clk/sunxi/clk-sun9i-cpus.c >> >> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt >> b/Documentation/devicetree/bindings/clock/sunxi.txt >> index b6859ed6913f..153ac72869e8 100644 >> --- a/Documentation/devicetree/bindings/clock/sunxi.txt >> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt >> @@ -27,6 +27,7 @@ Required properties: >> "allwinner,sun5i-a10s-ahb-gates-clk" - for the AHB gates on A10s >> "allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20 >> "allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31 >> + "allwinner,sun9i-a80-cpus-clk" - for the CPUS on A80 >> "allwinner,sun6i-a31-ahb1-clk" - for the AHB1 clock on A31 >> "allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31 >> "allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23 >> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile >> index 121333ce34ea..07d914c3f6d1 100644 >> --- a/drivers/clk/sunxi/Makefile >> +++ b/drivers/clk/sunxi/Makefile >> @@ -13,6 +13,7 @@ obj-y += clk-simple-gates.o >> obj-y += clk-sun8i-apb0.o >> obj-y += clk-sun8i-mbus.o >> obj-y += clk-sun9i-core.o >> +obj-y += clk-sun9i-cpus.o > > Same thing here, if it's only used in the A80, just compile it when > ARCH_SUN9I is compiled. Sure. Should I add a patch changing the ones already in? sun9i-core and sun9i-mmc that is. Thanks ChenYu -- 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 2/7] ACPI / LPSS: allow to use specific PM domain during ->probe()
On 11/26/2015 06:45 PM, Andy Shevchenko wrote:
On Thu, 2015-11-26 at 18:30 +0200, Jarkko Nikula wrote:
On 11/26/2015 05:19 PM, Andy Shevchenko wrote:
This is an amendment to previously pushed commit 01ac170ba29a (ACPI
/ LPSS:
allow to use specific PM domain during ->probe()). We can't assign
anything to
the platform device on ADD_DEVICE stage since it might be changed
during
unbound / bind cycle.
Signed-off-by: Andy Shevchenko
---
drivers/acpi/acpi_lpss.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index f9e0d09..e840229 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -705,8 +705,14 @@ static int acpi_lpss_platform_notify(struct
notifier_block *nb,
}
switch (action) {
- case BUS_NOTIFY_ADD_DEVICE:
+ case BUS_NOTIFY_BIND_DRIVER:
pdev->dev.pm_domain = _lpss_pm_domain;
+ break;
+ case BUS_NOTIFY_BIND_DRIVER_ERROR:
+ case BUS_NOTIFY_UNBOUND_DRIVER:
+ pdev->dev.pm_domain = NULL;
+ break;
+ case BUS_NOTIFY_ADD_DEVICE:
This won't fix like revert of original commit does. Primary problem
here
is that there is no explicit power on at all during LPSS device probe
because dev->pm_domain is set before probing.
And we can't do this as in very original code of acpi_lpss.c since DMA
has to be sure it's powered on while probing. We could guarantee this
only in case when PM domain is assigned already and we do our quirk for
it.
I'm not sure do I follow here. Is the power on chain different for LPSS
DMA because setting the domain at BIND stage prevents the call to
acpi_dev_pm_full_power() before driver probe? See below.
driver_probe_device
really_probe
driver_sysfs_add -> BUS_NOTIFY_BIND_DRIVER
-> platform_drv_prove
dev_pm_domain_attach
acpi_dev_pm_attach
if (dev->pm_domain) return -EEXIST;
...
if (power_on) { acpi_dev_pm_full_power(adev);... }
-> probe
driver_bound -> BUS_NOTIFY_BOUND_DRIVER
From my point of view we have to fix hang first since it's most painful
case for users and their experience. Though I'm open to any better
solution if you have any in mind.
Sure.
--
Jarkko
--
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] scripts: fix the sys path for gdb scripts
On 2015-11-27 07:41, yalin wang wrote: > we insert __file__'s real path into sys.path, > so that no matter we import the vmlinux-gdb.py from $OUT floder or > from source code folder, we can always find the linux/ lib folder, > and we don't need create link to linux/*.py files, > remove the related make file. NACK again - I tell you why below. > > Signed-off-by: yalin wang > --- > scripts/Makefile | 1 - > scripts/gdb/Makefile | 1 - > scripts/gdb/linux/Makefile | 11 --- > scripts/gdb/vmlinux-gdb.py | 2 +- > 4 files changed, 1 insertion(+), 14 deletions(-) > delete mode 100644 scripts/gdb/Makefile > delete mode 100644 scripts/gdb/linux/Makefile > > diff --git a/scripts/Makefile b/scripts/Makefile > index 2016a64..72902b5 100644 > --- a/scripts/Makefile > +++ b/scripts/Makefile > @@ -36,7 +36,6 @@ subdir-$(CONFIG_MODVERSIONS) += genksyms > subdir-y += mod > subdir-$(CONFIG_SECURITY_SELINUX) += selinux > subdir-$(CONFIG_DTC) += dtc > -subdir-$(CONFIG_GDB_SCRIPTS) += gdb > > # Let clean descend into subdirs > subdir- += basic kconfig package > diff --git a/scripts/gdb/Makefile b/scripts/gdb/Makefile > deleted file mode 100644 > index 62f5f65..000 > --- a/scripts/gdb/Makefile > +++ /dev/null > @@ -1 +0,0 @@ > -subdir-y := linux > diff --git a/scripts/gdb/linux/Makefile b/scripts/gdb/linux/Makefile > deleted file mode 100644 > index 6cf1ecf..000 > --- a/scripts/gdb/linux/Makefile > +++ /dev/null > @@ -1,11 +0,0 @@ > -always := gdb-scripts > - > -SRCTREE := $(shell cd $(srctree) && /bin/pwd) > - > -$(obj)/gdb-scripts: > -ifneq ($(KBUILD_SRC),) > - $(Q)ln -fsn $(SRCTREE)/$(obj)/*.py $(objtree)/$(obj) > -endif > - @: > - > -clean-files := *.pyc *.pyo $(if $(KBUILD_SRC),*.py) This step I don't understand at all. Why do you want to destroy the possibility to automatically load the scripts? Did you read Documentation/gdb-kernel-debugging.txt in this regard? > diff --git a/scripts/gdb/vmlinux-gdb.py b/scripts/gdb/vmlinux-gdb.py > index ce82bf5..a9029f4 100644 > --- a/scripts/gdb/vmlinux-gdb.py > +++ b/scripts/gdb/vmlinux-gdb.py > @@ -13,7 +13,7 @@ > > import os > > -sys.path.insert(0, os.path.dirname(__file__) + "/scripts/gdb") > +sys.path.insert(0, os.path.dirname(os.path.realpath(__file__))) This works only so far as that (if you don't destroy the link) the main script will still find its modules. However, *.pyc files are then generated in the source tree, no longer in the output dirs. The code is designed to prevent this. You still don't explain to us why the existing code doesn't work for you and how you prefer to use it instead. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux -- 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: linux-next: Tree for Nov 27 (mm stuff)
On 11/26/15 21:05, Stephen Rothwell wrote: > Hi all, > > Reminder: there will be no linux-next release next week (Nov 30 - Dec 4). > > Changes since 20151126: > on i386: mm/built-in.o: In function `page_referenced_one': rmap.c:(.text+0x362a2): undefined reference to `pmdp_clear_flush_young' mm/built-in.o: In function `page_idle_clear_pte_refs_one': page_idle.c:(.text+0x4b2b8): undefined reference to `pmdp_test_and_clear_young' Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/i386 4.4.0-rc2 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_BITS_MAX=16 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=2 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set CONFIG_KERNEL_LZO=y # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SYSVIPC is not set CONFIG_POSIX_MQUEUE=y CONFIG_CROSS_MEMORY_ATTACH=y # CONFIG_FHANDLE is not set # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # # CONFIG_TICK_CPU_ACCOUNTING is not set CONFIG_IRQ_TIME_ACCOUNTING=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_PREEMPT_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_TREE_RCU_TRACE=y # CONFIG_RCU_EXPEDITE_BOOT is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_RD_GZIP is not set CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y # CONFIG_RD_LZ4 is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y CONFIG_EXPERT=y # CONFIG_MULTIUSER is not set # CONFIG_SGETMASK_SYSCALL is not set # CONFIG_SYSFS_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_PRINTK is not set # CONFIG_BUG is not set CONFIG_ELF_CORE=y # CONFIG_PCSPKR_PLATFORM is not set # CONFIG_BASE_FULL is not set CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y # CONFIG_BPF_SYSCALL is not set CONFIG_SHMEM=y # CONFIG_AIO is not set CONFIG_ADVISE_SYSCALLS=y CONFIG_USERFAULTFD=y CONFIG_MEMBARRIER=y CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # C
Re: [Patch v7 4/7] PCI/ACPI: Add interface acpi_pci_root_create()
On 20.11.2015 11:18, Lorenzo Pieralisi wrote: Hi Jiang, On Sat, Nov 14, 2015 at 01:49:08AM +0800, Jiang Liu wrote: [...] Not really. My concern is that there might be platforms out there with an offset between the CPU and PCI physical address spaces, and if we remove the offset value in acpi_decode_space we can break them, because in the kernel struct resource data we have to have CPU physical addresses, not PCI ones. If offset == 0, we are home and dry, I do not understand why that's a given, which is what we would assume if Jiang's patch is merged as-is unless I am mistaken. We try to exclude offset from struct resource in generic ACPI code, and it's the arch's responsibility to decide how to manipulate struct resource object if offset is not zero. Currently offset is always zero for x86, and IA64 has arch specific code to handle non-zero offset. So we should be safe without breaking existing code. For ARM64, it's a little different from IA64 so it's hard to share code between IA64 and ARM64. Can you drop the patch on the mailing lists please, we actually need it to get ACPI ARM64 PCIe support in the kernel, please let me know how you want to handle this and if you need any help. Kindly reminder. Regards, Tomasz -- 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 v5 4/9] mfd: axp20x: Split the driver into core and i2c bits
The axp20x driver assumes the device is i2c based. This is not the
case with later chips, which use a proprietary 2 wire serial bus
by Allwinner called "Reduced Serial Bus".
This patch follows the example of mfd/wm831x and splits it into
an interface independent core, and an i2c specific glue layer.
MFD_AXP20X and the new MFD_AXP20X_I2C are changed to tristate
symbols, allowing the driver to be built as modules.
Whitespace and other style errors in the moved i2c specific code
have been fixed. Included but unused header files are removed as
well.
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/Kconfig| 14 ---
drivers/mfd/Makefile | 1 +
drivers/mfd/axp20x-i2c.c | 102 +
drivers/mfd/axp20x.c | 88 +++---
include/linux/mfd/axp20x.h | 33 ++-
5 files changed, 158 insertions(+), 80 deletions(-)
create mode 100644 drivers/mfd/axp20x-i2c.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 4d92df6ef9fe..804cd3dcce32 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -91,14 +91,18 @@ config MFD_BCM590XX
Support for the BCM590xx PMUs from Broadcom
config MFD_AXP20X
- bool "X-Powers AXP20X"
+ tristate
select MFD_CORE
- select REGMAP_I2C
select REGMAP_IRQ
- depends on I2C=y
+
+config MFD_AXP20X_I2C
+ tristate "X-Powers AXP series PMICs with I2C"
+ select MFD_AXP20X
+ select REGMAP_I2C
+ depends on I2C
help
- If you say Y here you get support for the X-Powers AXP202, AXP209 and
- AXP288 power management IC (PMIC).
+ If you say Y here you get support for the X-Powers AXP series power
+ management ICs (PMICs) controlled with I2C.
This driver include only the core APIs. You have to select individual
components like regulators or the PEK (Power Enable Key) under the
corresponding menus.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a8b76b81b467..a6913007d667 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_PMIC_DA9052) += da9052-core.o
obj-$(CONFIG_MFD_DA9052_SPI) += da9052-spi.o
obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
obj-$(CONFIG_MFD_AXP20X) += axp20x.o
+obj-$(CONFIG_MFD_AXP20X_I2C) += axp20x-i2c.o
obj-$(CONFIG_MFD_LP3943) += lp3943.o
obj-$(CONFIG_MFD_LP8788) += lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x-i2c.c b/drivers/mfd/axp20x-i2c.c
new file mode 100644
index ..b54205677bb2
--- /dev/null
+++ b/drivers/mfd/axp20x-i2c.c
@@ -0,0 +1,102 @@
+/*
+ * axp20x-i2c.c - I2C driver for the X-Powers' Power Management ICs
+ *
+ * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK
DC-DC
+ * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
+ * as well as configurable GPIOs.
+ *
+ * This driver supports the I2C variants.
+ *
+ * Author: Carlo Caione
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int axp20x_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+ struct axp20x_dev *axp20x;
+ int ret;
+
+ axp20x = devm_kzalloc(>dev, sizeof(*axp20x), GFP_KERNEL);
+ if (!axp20x)
+ return -ENOMEM;
+
+ axp20x->dev = >dev;
+ axp20x->irq = i2c->irq;
+ dev_set_drvdata(axp20x->dev, axp20x);
+
+ ret = axp20x_match_device(axp20x);
+ if (ret)
+ return ret;
+
+ axp20x->regmap = devm_regmap_init_i2c(i2c, axp20x->regmap_cfg);
+ if (IS_ERR(axp20x->regmap)) {
+ ret = PTR_ERR(axp20x->regmap);
+ dev_err(>dev, "regmap init failed: %d\n", ret);
+ return ret;
+ }
+
+ return axp20x_device_probe(axp20x);
+}
+
+static int axp20x_i2c_remove(struct i2c_client *i2c)
+{
+ struct axp20x_dev *axp20x = i2c_get_clientdata(i2c);
+
+ return axp20x_device_remove(axp20x);
+}
+
+static const struct of_device_id axp20x_i2c_of_match[] = {
+ { .compatible = "x-powers,axp152", .data = (void *)AXP152_ID },
+ { .compatible = "x-powers,axp202", .data = (void *)AXP202_ID },
+ { .compatible = "x-powers,axp209", .data = (void *)AXP209_ID },
+ { .compatible = "x-powers,axp221", .data = (void *)AXP221_ID },
+ { },
+};
+MODULE_DEVICE_TABLE(of, axp20x_i2c_of_match);
+
+/*
+ * This is useless for OF-enabled devices, but it is needed by I2C subsystem
+ */
+static const struct i2c_device_id axp20x_i2c_id[] = {
+ { },
+};
+MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
+
+static const struct acpi_device_id axp20x_i2c_acpi_match[] = {
+ {
+
[PATCH v5 0/9] mfd: axp20x: Add support for RSB based AXP223
Hi everyone, This is v5 of the AXP223 PMIC series. v5 cleans up the code before and after the axp20x split, as suggested by Andy. Changes since v4: - Get rid of second parameter of axp20x_match_device() (new patch 2) - Match against dev->driver->of_match_table, so the entirety of axp20x_match_device() can be kept in the core. (new patch 3) - Move *_device_id tables to bottom of the driver, right above driver declaration. (patch 4 & 6) - Remove extra whitespaces while moving i2c specific code (patch 4) - Remove leftover whitespace and code style issues in axp20x core (new patch 5) - Remove extra whitespaces in rsb specific code (patch 6) Changes since v3: - Removed settings for axp223 reg_rtc_ldo from board dts files that are already in axp22x.dtsi. The name is kept. - Dropped simplefb label and defconfig patches, as they are merged. Changes since v2: - s/It's/Its/ for the commit messages of patches 5 and 7 - Add Rob's Acked-by for patch 1 Changes since v1: - Dropped NMI interrupt controller dts patch (Merged) - Change MFD_AXP20X to represent the axp20x core, and drop MFD_AXP20X_CORE - Keep the axp20x core bits named axp20x.c - Add patch 7 to add AXP223 to sun8i-q8-common.dtsi - Add patch 8 & 9 to update defconfigs - Make axp20x drivers tristate and buildable as modules - Drop "_sunxi" substring from identifiers in axp20x-rsb driver This series adds support for the Reduced Serial Bus based AXP223 PMIC. The AXP223 is functionally identical to the AXP221, which we already support. Only some default values for the regulators are different. The defaults fit their recommended application, paired with different SoCs. Patch 1 adds AXP223 to the list of supported chips in the DT binding. Patch 2 splits the axp20x mfd driver into 2 parts, a core library, and an I2C driver. Patch 3 adds an RSB based driver for the AXP223. Patch 4 adds support for the AXP223 regulators Patch 5 enables the AXP223 PMIC and its regulators for the Sinlinx SinA33. Patch 6 enables the AXP223 PMIC and its regulators for A23/A33 based Q8 devices. Regards ChenYu Chen-Yu Tsai (9): mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings mfd: axp20x: Remove second struct device * parameter for axp20x_match_device() mfd: axp20x: use dev->driver->of_match_table in axp20x_match_device() mfd: axp20x: Split the driver into core and i2c bits mfd: axp20x: Whitespace, open parenthesis alignment code style fixes mfd: axp20x: Add support for RSB based AXP223 PMIC regulator: axp20x: Support new AXP223 PMIC ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator nodes ARM: dts: sun8i: q8-common: Add AXP223 PMIC device and regulator nodes Documentation/devicetree/bindings/mfd/axp20x.txt | 7 +- arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 76 - arch/arm/boot/dts/sun8i-q8-common.dtsi | 83 +- drivers/mfd/Kconfig | 25 -- drivers/mfd/Makefile | 2 + drivers/mfd/axp20x-i2c.c | 102 +++ drivers/mfd/axp20x-rsb.c | 78 + drivers/mfd/axp20x.c | 101 +- drivers/regulator/axp20x-regulator.c | 3 + include/linux/mfd/axp20x.h | 34 +++- 10 files changed, 418 insertions(+), 93 deletions(-) create mode 100644 drivers/mfd/axp20x-i2c.c create mode 100644 drivers/mfd/axp20x-rsb.c -- 2.6.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 v5 6/9] mfd: axp20x: Add support for RSB based AXP223 PMIC
The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/Kconfig| 11 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/axp20x-rsb.c | 78 ++
drivers/mfd/axp20x.c | 2 ++
include/linux/mfd/axp20x.h | 1 +
5 files changed, 93 insertions(+)
create mode 100644 drivers/mfd/axp20x-rsb.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 804cd3dcce32..13c565103e96 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -107,6 +107,17 @@ config MFD_AXP20X_I2C
components like regulators or the PEK (Power Enable Key) under the
corresponding menus.
+config MFD_AXP20X_RSB
+ tristate "X-Powers AXP series PMICs with RSB"
+ select MFD_AXP20X
+ depends on SUNXI_RSB
+ help
+ If you say Y here you get support for the X-Powers AXP series power
+ management ICs (PMICs) controlled with RSB.
+ This driver include only the core APIs. You have to select individual
+ components like regulators or the PEK (Power Enable Key) under the
+ corresponding menus.
+
config MFD_CROS_EC
tristate "ChromeOS Embedded Controller"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a6913007d667..caea6637d5e8 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_MFD_DA9052_SPI)+= da9052-spi.o
obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
obj-$(CONFIG_MFD_AXP20X) += axp20x.o
obj-$(CONFIG_MFD_AXP20X_I2C) += axp20x-i2c.o
+obj-$(CONFIG_MFD_AXP20X_RSB) += axp20x-rsb.o
obj-$(CONFIG_MFD_LP3943) += lp3943.o
obj-$(CONFIG_MFD_LP8788) += lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
new file mode 100644
index ..76ff02b96df0
--- /dev/null
+++ b/drivers/mfd/axp20x-rsb.c
@@ -0,0 +1,78 @@
+/*
+ * axp20x-rsb.c - RSB driver for the X-Powers' Power Management ICs
+ *
+ * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK
DC-DC
+ * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
+ * as well as configurable GPIOs.
+ *
+ * This driver supports the RSB variants.
+ *
+ * Author: Chen-Yu Tsai
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int axp20x_rsb_probe(struct sunxi_rsb_device *rdev)
+{
+ struct axp20x_dev *axp20x;
+ int ret;
+
+ axp20x = devm_kzalloc(>dev, sizeof(*axp20x), GFP_KERNEL);
+ if (!axp20x)
+ return -ENOMEM;
+
+ axp20x->dev = >dev;
+ axp20x->irq = rdev->irq;
+ sunxi_rsb_device_set_drvdata(rdev, axp20x);
+
+ ret = axp20x_match_device(axp20x);
+ if (ret)
+ return ret;
+
+ axp20x->regmap = devm_regmap_init_sunxi_rsb(rdev, axp20x->regmap_cfg);
+ if (IS_ERR(axp20x->regmap)) {
+ ret = PTR_ERR(axp20x->regmap);
+ dev_err(>dev, "regmap init failed: %d\n", ret);
+ return ret;
+ }
+
+ return axp20x_device_probe(axp20x);
+}
+
+static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
+{
+ struct axp20x_dev *axp20x = sunxi_rsb_device_get_drvdata(rdev);
+
+ return axp20x_device_remove(axp20x);
+}
+
+static const struct of_device_id axp20x_rsb_of_match[] = {
+ { .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
+ { },
+};
+MODULE_DEVICE_TABLE(of, axp20x_rsb_of_match);
+
+static struct sunxi_rsb_driver axp20x_rsb_driver = {
+ .driver = {
+ .name = "axp20x-rsb",
+ .of_match_table = of_match_ptr(axp20x_rsb_of_match),
+ },
+ .probe = axp20x_rsb_probe,
+ .remove = axp20x_rsb_remove,
+};
+module_sunxi_rsb_driver(axp20x_rsb_driver);
+
+MODULE_DESCRIPTION("PMIC MFD sunXi RSB driver for AXP20X");
+MODULE_AUTHOR("Chen-Yu Tsai ");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 54a00168da26..968d77fb95d8 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -33,6 +33,7 @@ static const char * const axp20x_model_names[] = {
"AXP202",
"AXP209",
"AXP221",
+ "AXP223",
"AXP288",
};
@@ -616,6 +617,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_irq_chip = _regmap_irq_chip;
break;
case AXP221_ID:
+ case AXP223_ID:
axp20x->nr_cells = ARRAY_SIZE(axp22x_cells);
axp20x->cells = axp22x_cells;
axp20x->regmap_cfg =
[PATCH v5 7/9] regulator: axp20x: Support new AXP223 PMIC
The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs. It is functionally identical to AXP221; only the regulator default voltage/status and the external host interface are different. Signed-off-by: Chen-Yu Tsai Reviewed-by: Mark Brown --- drivers/regulator/axp20x-regulator.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c index 35de22fdb7a0..55cce8125716 100644 --- a/drivers/regulator/axp20x-regulator.c +++ b/drivers/regulator/axp20x-regulator.c @@ -244,6 +244,7 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq) step = 75; break; case AXP221_ID: + case AXP223_ID: min = 1800; max = 4050; def = 3000; @@ -322,6 +323,7 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev *rdev, int id, u32 work break; case AXP221_ID: + case AXP223_ID: if (id < AXP22X_DCDC1 || id > AXP22X_DCDC5) return -EINVAL; @@ -360,6 +362,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev) nregulators = AXP20X_REG_ID_MAX; break; case AXP221_ID: + case AXP223_ID: regulators = axp22x_regulators; nregulators = AXP22X_REG_ID_MAX; break; -- 2.6.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 v5 9/9] ARM: dts: sun8i: q8-common: Add AXP223 PMIC device and regulator nodes
A23/A33 Q8 tablets have an X-Powers AXP223 PMIC connected via RSB. Its
regulators provide power to various parts of the SoC and the board.
Also add lcd regulator supply for simplefb and update the existing
vmmc-supply for mmc0.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-q8-common.dtsi | 83 +-
1 file changed, 81 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi
b/arch/arm/boot/dts/sun8i-q8-common.dtsi
index 1a69231d2da5..1db0e8f77767 100644
--- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
+++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
@@ -56,7 +56,6 @@
brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
default-brightness-level = <8>;
enable-gpios = < 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
- /* backlight is powered by AXP223 DC1SW */
};
chosen {
@@ -67,7 +66,7 @@
{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin_q8>;
- vmmc-supply = <_vcc3v0>;
+ vmmc-supply = <_dcdc1>;
bus-width = <4>;
cd-gpios = < 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
cd-inverted;
@@ -92,6 +91,82 @@
_rsb {
status = "okay";
+
+ axp22x: pmic@3e3 {
+ compatible = "x-powers,axp223";
+ reg = <0x3e3>;
+ interrupt-parent = <_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ eldoin-supply = <_dcdc1>;
+ };
+};
+
+#include "axp22x.dtsi"
+
+_aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-io";
+};
+
+_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <235>;
+ regulator-max-microvolt = <265>;
+ regulator-name = "vdd-dll";
+};
+
+_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <270>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-pll-avcc";
+};
+
+_dc1sw {
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-lcd";
+};
+
+_dc5ldo {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpus";
+};
+
+_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-3v0";
+};
+
+_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-sys";
+};
+
+_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpu";
+};
+
+_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <150>;
+ regulator-name = "vcc-dram";
+};
+
+_rtc_ldo {
+ regulator-name = "vcc-rtc";
};
_uart {
@@ -99,3 +174,7 @@
pinctrl-0 = <_uart_pins_a>;
status = "okay";
};
+
+_lcd {
+ vcc-lcd-supply = <_dc1sw>;
+};
--
2.6.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 v5 8/9] ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator nodes
This board has a X-Powers AXP223 PMIC connected via RSB. Its regulators
provide power to various parts of the SoC and the board.
Also update the regulator supply phandles.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 76 +-
1 file changed, 73 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index 13ce68f06dd6..2809e079902e 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -68,7 +68,7 @@
};
{
- vref-supply = <_vcc3v0>;
+ vref-supply = <_dcdc1>;
status = "okay";
button@200 {
@@ -96,7 +96,7 @@
{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin_sina33>;
- vmmc-supply = <_vcc3v0>;
+ vmmc-supply = <_dcdc1>;
bus-width = <4>;
cd-gpios = < 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
cd-inverted;
@@ -106,7 +106,7 @@
{
pinctrl-names = "default";
pinctrl-0 = <_8bit_pins>;
- vmmc-supply = <_vcc3v0>;
+ vmmc-supply = <_dcdc1>;
bus-width = <8>;
non-removable;
status = "okay";
@@ -132,6 +132,76 @@
_rsb {
status = "okay";
+
+ axp22x: pmic@3e3 {
+ compatible = "x-powers,axp223";
+ reg = <0x3e3>;
+ interrupt-parent = <_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ eldoin-supply = <_dcdc1>;
+ };
+};
+
+#include "axp22x.dtsi"
+
+_aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-io";
+};
+
+_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <235>;
+ regulator-max-microvolt = <265>;
+ regulator-name = "vdd-dll";
+};
+
+_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <270>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-pll-avcc";
+};
+
+_dc5ldo {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpus";
+};
+
+_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-3v0";
+};
+
+_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-sys";
+};
+
+_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpu";
+};
+
+_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <150>;
+ regulator-name = "vcc-dram";
+};
+
+_rtc_ldo {
+ regulator-name = "vcc-rtc";
};
{
--
2.6.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 v5 3/9] mfd: axp20x: use dev->driver->of_match_table in axp20x_match_device()
In axp20x_match_device(), match the of_device_id table bound to the
device driver instead of pointing to axp20x_of_match directly. This
will allow us to keep axp20x_match_device() unmodified when we expand
the axp20x driver into multiple ones covering different interface
types.
of_device_get_match_data() cannot be used here as we need to know if
it failed to get a match, or if the match data value just happened to
be 0, as it is for the AXP152.
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/axp20x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 685a78614f83..3e186f2dcac3 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -613,7 +613,7 @@ static int axp20x_match_device(struct axp20x_dev *axp20x)
const struct of_device_id *of_id;
if (dev->of_node) {
- of_id = of_match_device(axp20x_of_match, dev);
+ of_id = of_match_device(dev->driver->of_match_table, dev);
if (!of_id) {
dev_err(dev, "Unable to match OF ID\n");
return -ENODEV;
--
2.6.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 v5 2/9] mfd: axp20x: Remove second struct device * parameter for axp20x_match_device()
The first argument passed to axp20x_match_device(), struct axp20x_dev *,
already contains a pointer to the device. By rearranging some code,
moving the assignment of the pointer before axp20x_match_device() is
called, we can eliminate the second parameter.
Suggested-by: Andy Shevchenko
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/axp20x.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 9842199e2e6c..685a78614f83 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -606,8 +606,9 @@ static void axp20x_power_off(void)
AXP20X_OFF);
}
-static int axp20x_match_device(struct axp20x_dev *axp20x, struct device *dev)
+static int axp20x_match_device(struct axp20x_dev *axp20x)
{
+ struct device *dev = axp20x->dev;
const struct acpi_device_id *acpi_id;
const struct of_device_id *of_id;
@@ -673,14 +674,14 @@ static int axp20x_i2c_probe(struct i2c_client *i2c,
if (!axp20x)
return -ENOMEM;
- ret = axp20x_match_device(axp20x, >dev);
- if (ret)
- return ret;
-
axp20x->i2c_client = i2c;
axp20x->dev = >dev;
dev_set_drvdata(axp20x->dev, axp20x);
+ ret = axp20x_match_device(axp20x);
+ if (ret)
+ return ret;
+
axp20x->regmap = devm_regmap_init_i2c(i2c, axp20x->regmap_cfg);
if (IS_ERR(axp20x->regmap)) {
ret = PTR_ERR(axp20x->regmap);
--
2.6.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 v5 1/9] mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings
The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs. It is functionally identical to AXP221; only the regulator default voltage/status and the external host interface are different. Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Acked-by: Rob Herring Acked-by: Lee Jones --- Documentation/devicetree/bindings/mfd/axp20x.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt index a474359dd206..fd39fa54571b 100644 --- a/Documentation/devicetree/bindings/mfd/axp20x.txt +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt @@ -5,11 +5,12 @@ axp152 (X-Powers) axp202 (X-Powers) axp209 (X-Powers) axp221 (X-Powers) +axp223 (X-Powers) Required properties: - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209", - "x-powers,axp221" -- reg: The I2C slave address for the AXP chip + "x-powers,axp221", "x-powers,axp223" +- reg: The I2C slave address or RSB hardware address for the AXP chip - interrupt-parent: The parent interrupt controller - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin - interrupt-controller: The PMIC has its own internal IRQs @@ -51,7 +52,7 @@ LDO3 : LDO : ldo3in-supply LDO4 : LDO : ldo24in-supply: shared supply LDO5 : LDO : ldo5in-supply -AXP221 regulators, type, and corresponding input supply names: +AXP221/AXP223 regulators, type, and corresponding input supply names: RegulatorTypeSupply Name Notes ---- - -- 2.6.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 v5 5/9] mfd: axp20x: Whitespace, open parenthesis alignment code style fixes
This fixes some leftover code style issues in the axp20x core.
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/axp20x.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 631ad64ddf69..54a00168da26 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -591,14 +591,14 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
dev_err(dev, "Unable to match OF ID\n");
return -ENODEV;
}
- axp20x->variant = (long) of_id->data;
+ axp20x->variant = (long)of_id->data;
} else {
acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
if (!acpi_id || !acpi_id->driver_data) {
dev_err(dev, "Unable to match ACPI ID and data\n");
return -ENODEV;
}
- axp20x->variant = (long) acpi_id->driver_data;
+ axp20x->variant = (long)acpi_id->driver_data;
}
switch (axp20x->variant) {
@@ -632,7 +632,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
return -EINVAL;
}
dev_info(dev, "AXP20x variant %s found\n",
- axp20x_model_names[axp20x->variant]);
+axp20x_model_names[axp20x->variant]);
return 0;
}
@@ -652,7 +652,7 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
}
ret = mfd_add_devices(axp20x->dev, -1, axp20x->cells,
- axp20x->nr_cells, NULL, 0, NULL);
+ axp20x->nr_cells, NULL, 0, NULL);
if (ret) {
dev_err(axp20x->dev, "failed to add MFD devices: %d\n", ret);
--
2.6.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: [PATCHv2] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
hi Krzysztof,
On 22 October 2015 at 18:34, Anand Moon wrote:
> hi Krzysztof,
>
> On 22 October 2015 at 06:31, Krzysztof Kozlowski
> wrote:
>> On 20.10.2015 21:56, Anand Moon wrote:
>>> Changes need for host controller to detect UHS-I highspeed cards.
>>> Changes in VDDQ_MMC2 voltage range help scale
>>> the required voltage to detect and load the microSD cards.
>>
>> Thanks for updating description of commit.
>>
>>>
>>> Signed-off-by: Anand Moon
>>> ---
>>> Changes based on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>> v4.4-next/dt-samsung branch
>>>
>>> Changes:
>>> Drop the ranp_delay for LDO9.
>>>
>>> Thanks to : Krzysztof, Doug Anderson, Jaehoon Chung for helping
>>> me out figure out the mmc core requirement.
>>>
>>> Also drop the previous changes:
>>> use cd-gpio method to detect sd-card.
>>> Added UHS-I bus speed support.
>>>
>>> [4.713553] random: nonblocking pool is initialized
>>> [4.718423] 1453.hdmi supply hdmi-en not found, using dummy regulator
>>> [4.726206] exynos-drm exynos-drm: bound 1440.fimd (ops
>>> fimd_component_ops)
>>> [4.732555] exynos-drm exynos-drm: bound 1445.mixer (ops
>>> mixer_component_ops)
>>> [4.740180] exynos-drm exynos-drm: bound 1453.hdmi (ops
>>> hdmi_component_ops)
>>> [4.746936] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>> [4.753428] [drm] No driver support for vblank timestamp query.
>>> [4.940794] Console: switching to colour frame buffer device 274x77
>>> [4.995344] exynos-drm exynos-drm: fb0: frame buffer device
>>> [5.024573] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>> [5.031164] exynos-dwc3 usb@1200: no suspend clk specified
>>> [5.054571] usb 2-1: new full-speed USB device number 2 using exynos-ohci
>>> [5.159527] dwmmc_exynos 1222.mmc: Busy; trying anyway
>>> [5.163705] mmc_host mmc1: Timeout sending command (cmd 0x202000 arg 0x0
>>> status 0x0)
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> index 1af5bdc..a4be3e0 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> @@ -182,9 +182,10 @@
>>>
>>> ldo13_reg: LDO13 {
>>> regulator-name = "vdd_ldo13";
>>> - regulator-min-microvolt = <280>;
>>> + regulator-min-microvolt = <180>;
>>
>> You did not convinced me in previous discussion about the change to
>> 1.8V. I said that:
>>> On the same diagram few lines below:
>>> VDDQ_MMC2: 2.8V 250mA
>>
>> You responded:
>>> You are correct.
>>
>> So I am confused. Are you sure that this SD card block can/should
>> operate on 1.8V? Have you actually tried this?
>>
>
> Look like I missed this point. Here is the link I would like to share.
>
> http://www.hjreggel.net/cardspeed/cs_sdxc.html
> Section: Summary of SD modes
>
> https://en.wikipedia.org/wiki/Secure_Digital
> Section: Power consumption
>
> Their different requirement for voltage requirement for UHS-I, the max
> value is around 3.3V
Do you have any comment on this voltage selection for UHS-I card (1.8V).
>
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> + regulator-ramp-delay = <12000>;
>>
>> NAK
>>
>> We've been talking about this. Sooo mn times.
>>
>> If you are going to send v3 please come up with detailed reasoning,
>> which will convince my stubborn mind.
>>
>
> Look like I missed this point. my typo. Will drop this in next version.
> No matter I try hard, it turn out I make silly and annoying mistake.
>
> -Anand Moon
>
Well I will drop this.
>> Best regards,
>> Krzysztof
>>
>>> };
>>>
>>> ldo15_reg: LDO15 {
>>> @@ -213,6 +214,7 @@
>>> regulator-min-microvolt = <280>;
>>> regulator-max-microvolt = <280>;
>>> regulator-always-on;
>>> + regulator-ramp-delay = <12000>;
>>> };
>>>
>>> ldo24_reg: LDO24 {
>>> @@ -338,6 +340,7 @@
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> samsung,dw-mshc-hs400-timing = <0 2>;
>>> samsung,read-strobe-delay = <90>;
>>> + vmmc-supply = <_reg>;
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_clk _cmd _bus1 _bus4 _bus8 _cd
>>> _rclk>;
>>> bus-width = <8>;
>>> @@ -355,6 +358,8 @@
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_clk _cmd _cd _bus1 _bus4>;
>>> bus-width = <4>;
>>> + vmmc-supply = <_reg>;
>>> + vqmmc-supply = <_reg>;
>>>
[PATCH V2] scripts: fix the sys path for gdb scripts
we insert __file__'s real path into sys.path,
so that no matter we import the vmlinux-gdb.py from $OUT floder or
from source code folder, we can always find the linux/ lib folder,
and we don't need create link to linux/*.py files,
remove the related make file.
Signed-off-by: yalin wang
---
scripts/Makefile | 1 -
scripts/gdb/Makefile | 1 -
scripts/gdb/linux/Makefile | 11 ---
scripts/gdb/vmlinux-gdb.py | 2 +-
4 files changed, 1 insertion(+), 14 deletions(-)
delete mode 100644 scripts/gdb/Makefile
delete mode 100644 scripts/gdb/linux/Makefile
diff --git a/scripts/Makefile b/scripts/Makefile
index 2016a64..72902b5 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -36,7 +36,6 @@ subdir-$(CONFIG_MODVERSIONS) += genksyms
subdir-y += mod
subdir-$(CONFIG_SECURITY_SELINUX) += selinux
subdir-$(CONFIG_DTC) += dtc
-subdir-$(CONFIG_GDB_SCRIPTS) += gdb
# Let clean descend into subdirs
subdir-+= basic kconfig package
diff --git a/scripts/gdb/Makefile b/scripts/gdb/Makefile
deleted file mode 100644
index 62f5f65..000
--- a/scripts/gdb/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-subdir-y := linux
diff --git a/scripts/gdb/linux/Makefile b/scripts/gdb/linux/Makefile
deleted file mode 100644
index 6cf1ecf..000
--- a/scripts/gdb/linux/Makefile
+++ /dev/null
@@ -1,11 +0,0 @@
-always := gdb-scripts
-
-SRCTREE := $(shell cd $(srctree) && /bin/pwd)
-
-$(obj)/gdb-scripts:
-ifneq ($(KBUILD_SRC),)
- $(Q)ln -fsn $(SRCTREE)/$(obj)/*.py $(objtree)/$(obj)
-endif
- @:
-
-clean-files := *.pyc *.pyo $(if $(KBUILD_SRC),*.py)
diff --git a/scripts/gdb/vmlinux-gdb.py b/scripts/gdb/vmlinux-gdb.py
index ce82bf5..a9029f4 100644
--- a/scripts/gdb/vmlinux-gdb.py
+++ b/scripts/gdb/vmlinux-gdb.py
@@ -13,7 +13,7 @@
import os
-sys.path.insert(0, os.path.dirname(__file__) + "/scripts/gdb")
+sys.path.insert(0, os.path.dirname(os.path.realpath(__file__)))
try:
gdb.parse_and_eval("0")
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts: fix the sys path for gdb scripts
> On Nov 25, 2015, at 15:38, Jan Kiszka wrote:
>
> On 2015-11-19 11:54, yalin wang wrote:
>> The sys.path should be scripts/gdb,
>> so that we can import linux lib correctly.
>>
>> Signed-off-by: yalin wang
>> ---
>> scripts/gdb/vmlinux-gdb.py | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/scripts/gdb/vmlinux-gdb.py b/scripts/gdb/vmlinux-gdb.py
>> index ce82bf5..5a45d1a 100644
>> --- a/scripts/gdb/vmlinux-gdb.py
>> +++ b/scripts/gdb/vmlinux-gdb.py
>> @@ -13,7 +13,7 @@
>>
>> import os
>>
>> -sys.path.insert(0, os.path.dirname(__file__) + "/scripts/gdb")
>> +sys.path.insert(0, os.path.dirname(__file__))
>>
>> try:
>> gdb.parse_and_eval("0")
>>
>
> NACK. This patch is assuming that vmlinux-gdb.py is (only) started from
> the scripts/gdb folder. But CONFIG_GDB_SCRIPTS places a link to
> vmlinux-gdb.py aside the vmlinux binary in the top-level folder. That
> way, the script is auto-loaded by gdb.
>
> If you have a compelling use case for loading the script manually from
> its original folder, we can discuss augmenting the path. But removing
> the existing one is wrong.
>
> Andrew, please drop the patch from your queue.
>
ok, i will send a V2 patch for this .
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/16] bpf tools: Collect map definition in bpf_object
On 2015/11/27 14:16, Wangnan (F) wrote:
On 2015/11/27 4:56, Arnaldo Carvalho de Melo wrote:
Em Tue, Nov 24, 2015 at 01:36:09PM +, Wang Nan escreveu:
[SNIP]
[SNIP]
+
+if ((prev < s) || (prev >= e)) {
+pr_warning("error: map handler doesn't belong to object\n");
I wonder if this shouldn't be made pr_debug, and as well have a function
prefix, otherwise we may think this is related to some other kind of
map, so I suggest:
pr_debug("%s: error: map handler doesn't belong to object\n",
__func__);
Or at least:
pr_debug("BPF error: map handler doesn't belong to object\n");
We always have a libbpf prefix before debug info from libbpf. Please see
static __printf(1, 2) libbpf_print_fn_t __pr_warning = __base_pr;
static __printf(1, 2) libbpf_print_fn_t __pr_info = __base_pr;
static __printf(1, 2) libbpf_print_fn_t __pr_debug;
#define __pr(func, fmt, ...)\
do {\
if ((func)) \
(func)("libbpf: " fmt, ##__VA_ARGS__); \
} while (0)
#define pr_warning(fmt, ...)__pr(__pr_warning, fmt, ##__VA_ARGS__)
#define pr_info(fmt, ...) __pr(__pr_info, fmt, ##__VA_ARGS__)
#define pr_debug(fmt, ...) __pr(__pr_debug, fmt, ##__VA_ARGS__)
We allow __pr_{warning,info,debug} be overwritten but the 'libbpf:'
prefix is
always there.
Also, don't forget in perf's context libbpf is muted.
Sorry, Shoule be "muted in most case"...
Here's an example:
$ sudo ./perf record -v -e ./test_bpf_base.c ls
...
ude/uapi -Iinclude/generated/uapi -include
/home/w00229757/linux-hydrogen/include/linux/kconfig.h
set env: WORKING_DIR=/lib/modules/4.3.0-rc4+/build
set env: CLANG_SOURCE=/home/w00229757/./test_bpf_base.c
llvm compiling command template: $CLANG_EXEC -D__KERNEL__
-D__NR_CPUS__=$NR_CPUS -DLINUX_VERSION_CODE=$LINUX_VERSION_CODE
$CLANG_OPTIONS $KERNEL_INC_OPTIONS -Wno-unused-value -Wno-pointer-sign
-working-directory $WORKING_DIR -c "$CLANG_SOURCE" -target bpf -O2 -o -
libbpf: loading object './test_bpf_base.c' from buffer
libbpf: section .strtab, size 112, link 0, flags 0, type=3
libbpf: section .text, size 0, link 0, flags 6, type=1
libbpf: section .data, size 0, link 0, flags 3, type=1
...
libbpf: kernel version of ./test_bpf_base.c is 40300
libbpf: section .symtab, size 96, link 1, flags 0, type=2
bpf: config program 'func_write=vfs_write file->f_mode'
symbol:vfs_write file:(null) line:0 offset:0 return:0 lazy:(null)
parsing arg: file->f_mode into file, f_mode(1)
bpf: config 'func_write=vfs_write file->f_mode' is ok
If the error you pointed out is triggered, it should be:
libbpf: error: map handler doesn't belong to object ...
So we can always find which error message is belone to libbpf
and which is belone to 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/
Re: [PATCH 04/16] bpf tools: Collect map definition in bpf_object
On 2015/11/27 4:56, Arnaldo Carvalho de Melo wrote:
Em Tue, Nov 24, 2015 at 01:36:09PM +, Wang Nan escreveu:
[SNIP]
+ }
return 0;
}
@@ -688,37 +707,15 @@ static int
bpf_object__create_maps(struct bpf_object *obj)
{
unsigned int i;
- size_t nr_maps;
- int *pfd;
-
- nr_maps = obj->maps_buf_sz / sizeof(struct bpf_map_def);
- if (!obj->maps_buf || !nr_maps) {
- pr_debug("don't need create maps for %s\n",
-obj->path);
- return 0;
- }
-
- obj->map_fds = malloc(sizeof(int) * nr_maps);
perhaps calloc?
This line is being removed, so you'll still see this in my next version...
- if (!obj->map_fds) {
- pr_warning("realloc perf_bpf_map_fds failed\n");
- return -ENOMEM;
- }
- obj->nr_map_fds = nr_maps;
- /* fill all fd with -1 */
- memset(obj->map_fds, -1, sizeof(int) * nr_maps);
+ for (i = 0; i < obj->nr_maps; i++) {
+ struct bpf_map_def *def = >maps[i].def;
+ int *pfd = >maps[i].fd;
- pfd = obj->map_fds;
- for (i = 0; i < nr_maps; i++) {
- struct bpf_map_def def;
-
- def = *(struct bpf_map_def *)(obj->maps_buf +
- i * sizeof(struct bpf_map_def));
-
- *pfd = bpf_create_map(def.type,
- def.key_size,
- def.value_size,
- def.max_entries);
+ *pfd = bpf_create_map(def->type,
+ def->key_size,
+ def->value_size,
+ def->max_entries);
if (*pfd < 0) {
size_t j;
int err = *pfd;
@@ -726,22 +723,17 @@ bpf_object__create_maps(struct bpf_object *obj)
pr_warning("failed to create map: %s\n",
strerror(errno));
for (j = 0; j < i; j++)
- zclose(obj->map_fds[j]);
- obj->nr_map_fds = 0;
- zfree(>map_fds);
+ zclose(obj->maps[j].fd);
return err;
}
pr_debug("create map: fd=%d\n", *pfd);
- pfd++;
}
- zfree(>maps_buf);
- obj->maps_buf_sz = 0;
return 0;
}
static int
-bpf_program__relocate(struct bpf_program *prog, int *map_fds)
+bpf_program__relocate(struct bpf_program *prog, struct bpf_object *obj)
{
int i;
@@ -761,7 +753,7 @@ bpf_program__relocate(struct bpf_program *prog, int *map_fds)
return -LIBBPF_ERRNO__RELOC;
}
insns[insn_idx].src_reg = BPF_PSEUDO_MAP_FD;
- insns[insn_idx].imm = map_fds[map_idx];
+ insns[insn_idx].imm = obj->maps[map_idx].fd;
}
zfree(>reloc_desc);
@@ -780,7 +772,7 @@ bpf_object__relocate(struct bpf_object *obj)
for (i = 0; i < obj->nr_programs; i++) {
prog = >programs[i];
- err = bpf_program__relocate(prog, obj->map_fds);
+ err = bpf_program__relocate(prog, obj);
if (err) {
pr_warning("failed to relocate '%s'\n",
prog->section_name);
@@ -804,8 +796,7 @@ static int bpf_object__collect_reloc(struct bpf_object *obj)
Elf_Data *data = obj->efile.reloc[i].data;
int idx = shdr->sh_info;
struct bpf_program *prog;
- size_t nr_maps = obj->maps_buf_sz /
-sizeof(struct bpf_map_def);
+ size_t nr_maps = obj->nr_maps;
if (shdr->sh_type != SHT_REL) {
pr_warning("internal error at %d\n", __LINE__);
@@ -1050,10 +1041,8 @@ int bpf_object__unload(struct bpf_object *obj)
if (!obj)
return -EINVAL;
- for (i = 0; i < obj->nr_map_fds; i++)
- zclose(obj->map_fds[i]);
- zfree(>map_fds);
- obj->nr_map_fds = 0;
+ for (i = 0; i < obj->nr_maps; i++)
+ zclose(obj->maps[i].fd);
for (i = 0; i < obj->nr_programs; i++)
bpf_program__unload(>programs[i]);
@@ -1096,7 +1085,15 @@ void bpf_object__close(struct bpf_object *obj)
bpf_object__elf_finish(obj);
bpf_object__unload(obj);
- zfree(>maps_buf);
+ for (i = 0; i < obj->nr_maps; i++) {
+ if (obj->maps[i].clear_priv)
+ obj->maps[i].clear_priv(>maps[i],
+ obj->maps[i].priv);
+ obj->maps[i].priv = NULL;
+ obj->maps[i].clear_priv = NULL;
+ }
+ zfree(>maps);
+ obj->nr_maps = 0;
if (obj->programs && obj->nr_programs) {
[PATCH v2 0/2] mm: Introduce kernelcore=reliable option
Xeon E7 v3 based systems supports Address Range Mirroring and UEFI BIOS complied with UEFI spec 2.5 can notify which ranges are reliable (mirrored) via EFI memory map. Now Linux kernel utilize its information and allocates boot time memory from reliable region. My requirement is: - allocate kernel memory from reliable region - allocate user memory from non-reliable region In order to meet my requirement, ZONE_MOVABLE is useful. By arranging non-reliable range into ZONE_MOVABLE, reliable memory is only used for kernel allocations. My idea is to extend existing "kernelcore" option and introduces kernelcore=reliable option. By specifying "reliable" instead of specifying the amount of memory, non-reliable region will be arranged into ZONE_MOVABLE. Earlier discussions are at: https://lkml.org/lkml/2015/10/9/24 https://lkml.org/lkml/2015/10/15/9 For example, suppose 2-nodes system with the following memory range: node 0 [mem 0x1000-0x00109fff] node 1 [mem 0x0010a000-0x00209fff] and the following ranges are marked as reliable: [0x-0x0001] [0x0001-0x00018000] [0x0008-0x00088000] [0x0010a000-0x00112000] [0x0017a000-0x00182000] If you specify kernelcore=reliable, ZONE_NORMAL and ZONE_MOVABLE are arranged like bellow: - node 0: ZONE_NORMAL : [0x0001-0x0010a000] ZONE_MOVABLE: [0x00018000-0x0010a000] - node 1: ZONE_NORMAL : [0x0010a000-0x0020a000] ZONE_MOVABLE: [0x00112000-0x0020a000] In overlapped range, pages to be ZONE_MOVABLE in ZONE_NORMAL are treated as absent pages, and vice versa. v1 -> v2: Refine so that the above example case also can be handled properly: Taku Izumi (2): mm: Calculate zone_start_pfn at zone_spanned_pages_in_node() mm: Introduce kernelcore=reliable option Documentation/kernel-parameters.txt | 9 ++- mm/page_alloc.c | 140 +++- 2 files changed, 131 insertions(+), 18 deletions(-) -- 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 v2 1/2] mm: Calculate zone_start_pfn at zone_spanned_pages_in_node()
Currently each zone's zone_start_pfn is calculated at
free_area_init_core(). However zone's range is fixed at
the time when invoking zone_spanned_pages_in_node().
This patch changes each zone->zone_start_pfn is
calculated at zone_spanned_pages_in_node().
Signed-off-by: Taku Izumi
---
mm/page_alloc.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 17a3c66..acb0b4e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4928,31 +4928,31 @@ static unsigned long __meminit
zone_spanned_pages_in_node(int nid,
unsigned long zone_type,
unsigned long node_start_pfn,
unsigned long node_end_pfn,
+ unsigned long *zone_start_pfn,
+ unsigned long *zone_end_pfn,
unsigned long *ignored)
{
- unsigned long zone_start_pfn, zone_end_pfn;
-
/* When hotadd a new node from cpu_up(), the node should be empty */
if (!node_start_pfn && !node_end_pfn)
return 0;
/* Get the start and end of the zone */
- zone_start_pfn = arch_zone_lowest_possible_pfn[zone_type];
- zone_end_pfn = arch_zone_highest_possible_pfn[zone_type];
+ *zone_start_pfn = arch_zone_lowest_possible_pfn[zone_type];
+ *zone_end_pfn = arch_zone_highest_possible_pfn[zone_type];
adjust_zone_range_for_zone_movable(nid, zone_type,
node_start_pfn, node_end_pfn,
- _start_pfn, _end_pfn);
+ zone_start_pfn, zone_end_pfn);
/* Check that this node has pages within the zone's required range */
- if (zone_end_pfn < node_start_pfn || zone_start_pfn > node_end_pfn)
+ if (*zone_end_pfn < node_start_pfn || *zone_start_pfn > node_end_pfn)
return 0;
/* Move the zone boundaries inside the node if necessary */
- zone_end_pfn = min(zone_end_pfn, node_end_pfn);
- zone_start_pfn = max(zone_start_pfn, node_start_pfn);
+ *zone_end_pfn = min(*zone_end_pfn, node_end_pfn);
+ *zone_start_pfn = max(*zone_start_pfn, node_start_pfn);
/* Return the spanned pages */
- return zone_end_pfn - zone_start_pfn;
+ return *zone_end_pfn - *zone_start_pfn;
}
/*
@@ -5017,6 +5017,8 @@ static inline unsigned long __meminit
zone_spanned_pages_in_node(int nid,
unsigned long zone_type,
unsigned long node_start_pfn,
unsigned long node_end_pfn,
+ unsigned long *zone_start_pfn,
+ unsigned long *zone_end_pfn,
unsigned long *zones_size)
{
return zones_size[zone_type];
@@ -5047,15 +5049,22 @@ static void __meminit calculate_node_totalpages(struct
pglist_data *pgdat,
for (i = 0; i < MAX_NR_ZONES; i++) {
struct zone *zone = pgdat->node_zones + i;
+ unsigned long zone_start_pfn, zone_end_pfn;
unsigned long size, real_size;
size = zone_spanned_pages_in_node(pgdat->node_id, i,
node_start_pfn,
node_end_pfn,
+ _start_pfn,
+ _end_pfn,
zones_size);
real_size = size - zone_absent_pages_in_node(pgdat->node_id, i,
node_start_pfn, node_end_pfn,
zholes_size);
+ if (size)
+ zone->zone_start_pfn = zone_start_pfn;
+ else
+ zone->zone_start_pfn = 0;
zone->spanned_pages = size;
zone->present_pages = real_size;
@@ -5176,7 +5185,6 @@ static void __paginginit free_area_init_core(struct
pglist_data *pgdat)
{
enum zone_type j;
int nid = pgdat->node_id;
- unsigned long zone_start_pfn = pgdat->node_start_pfn;
int ret;
pgdat_resize_init(pgdat);
@@ -5192,6 +5200,7 @@ static void __paginginit free_area_init_core(struct
pglist_data *pgdat)
for (j = 0; j < MAX_NR_ZONES; j++) {
struct zone *zone = pgdat->node_zones + j;
unsigned long size, realsize, freesize, memmap_pages;
+ unsigned long zone_start_pfn = zone->zone_start_pfn;
size = zone->spanned_pages;
realsize = freesize = zone->present_pages;
@@ -5260,7 +5269,6 @@ static void __paginginit
[PATCH v2 2/2] mm: Introduce kernelcore=reliable option
This patch extends existing "kernelcore" option and
introduces kernelcore=reliable option. By specifying
"reliable" instead of specifying the amount of memory,
non-reliable region will be arranged into ZONE_MOVABLE.
v1 -> v2:
- Refine so that the following case also can be
handled properly:
Node X: |MM--MM|
(legend) M: mirrored -: not mirrrored
In this case, ZONE_NORMAL and ZONE_MOVABLE are
arranged like bellow:
Node X: |--|
|ooxxoo| ZONE_NORMAL
|ooxx| ZONE_MOVABLE
(legend) o: present x: absent
Signed-off-by: Taku Izumi
---
Documentation/kernel-parameters.txt | 9 ++-
mm/page_alloc.c | 110 ++--
2 files changed, 112 insertions(+), 7 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index f8aae63..ed44c2c8 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1695,7 +1695,8 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
keepinitrd [HW,ARM]
- kernelcore=nn[KMG] [KNL,X86,IA-64,PPC] This parameter
+ kernelcore= Format: nn[KMG] | "reliable"
+ [KNL,X86,IA-64,PPC] This parameter
specifies the amount of memory usable by the kernel
for non-movable allocations. The requested amount is
spread evenly throughout all nodes in the system. The
@@ -1711,6 +1712,12 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
use the HighMem zone if it exists, and the Normal
zone if it does not.
+ Instead of specifying the amount of memory (nn[KMS]),
+ you can specify "reliable" option. In case "reliable"
+ option is specified, reliable memory is used for
+ non-movable allocations and remaining memory is used
+ for Movable pages.
+
kgdbdbgp= [KGDB,HW] kgdb over EHCI usb debug port.
Format: [,poll interval]
The controller # is the number of the ehci usb debug
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index acb0b4e..006a3d8 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -251,6 +251,7 @@ static unsigned long __meminitdata
arch_zone_highest_possible_pfn[MAX_NR_ZONES];
static unsigned long __initdata required_kernelcore;
static unsigned long __initdata required_movablecore;
static unsigned long __meminitdata zone_movable_pfn[MAX_NUMNODES];
+static bool reliable_kernelcore;
/* movable_zone is the "real" zone pages in ZONE_MOVABLE are taken from */
int movable_zone;
@@ -4472,6 +4473,7 @@ void __meminit memmap_init_zone(unsigned long size, int
nid, unsigned long zone,
unsigned long pfn;
struct zone *z;
unsigned long nr_initialised = 0;
+ struct memblock_region *r = NULL, *tmp;
if (highest_memmap_pfn < end_pfn - 1)
highest_memmap_pfn = end_pfn - 1;
@@ -4491,6 +4493,38 @@ void __meminit memmap_init_zone(unsigned long size, int
nid, unsigned long zone,
if (!update_defer_init(pgdat, pfn, end_pfn,
_initialised))
break;
+
+ /*
+* if not reliable_kernelcore and ZONE_MOVABLE exists,
+* range from zone_movable_pfn[nid] to end of each node
+* should be ZONE_MOVABLE not ZONE_NORMAL. skip it.
+*/
+ if (!reliable_kernelcore && zone_movable_pfn[nid])
+ if (zone == ZONE_NORMAL &&
+ pfn >= zone_movable_pfn[nid])
+ continue;
+
+ /*
+* check given memblock attribute by firmware which
+* can affect kernel memory layout.
+* if zone==ZONE_MOVABLE but memory is mirrored,
+* it's an overlapped memmap init. skip it.
+*/
+ if (reliable_kernelcore && zone == ZONE_MOVABLE) {
+ if (!r ||
+ pfn >= memblock_region_memory_end_pfn(r)) {
+ for_each_memblock(memory, tmp)
+ if (pfn <
memblock_region_memory_end_pfn(tmp))
+ break;
+ r = tmp;
+ }
+ if (pfn >= memblock_region_memory_base_pfn(r) &&
+
Re: [PATCH] [v4] x86, suspend: Save/restore extra MSR registers for suspend
Hi, On 11/27/2015 11:28 AM, Doug Smythies wrote: On 2015.11.21 08:45 Doug Smythies wrote: On 2015.11.12 01:42 Chen, Yu C wrote: On 2015.11.06 11:34 Doug Smythies wrote: [cut] rdmsr_safe might be better, I'll look into it, thanks. you can refer to acpi_throttling_rdmsr I don't understand. and I'm OK with this code, are you planning to send a formal patch? The delay here is because I have always thought that some actual load content needs to be brought back to the intel_pstate driver, which would (or at least should) eliminate the need for this patch. Anyway, and at least for the interim, I'll try to make and submit a formal version. I made a mistake in my initial testing. I put a 100% load on CPU 7 and then cycled through all the clock modulation values to show that my test version of a possible patch compensated / normalized the Clock Modulation. Indeed, if the system is already asking for the maximum pstate, it will stay there. However, whenever the load drops, the target pstate will drop to minimum and it will never kick back up again, regardless of load. Do you mean even with your patch applied, the cpufreq policy would choose a smaller target? I looked up the SDM, it says in 14.7.3: on Hyper-Threading Technology enabled processors, the clock modulation might behave differently: "if the programmed duty cycle is not identical for all logical processors in the same core, the processor core will modulate at the lowest programmed duty cycle " I dont know if this is related to the problem. I am returning to my initial assertion copied below: The current version of the intel_pstate driver is incompatible with any use of Clock Modulation, always resulting in driving the target pstate to the minimum, regardless of load. The result is the apparent CPU frequency stuck at minimum * modulation percent. The acpi-cpufreq driver works fine with Clock Modulation, resulting in desired frequency * modulation percent. Chen, Thanks though for the suggestion to try normalizing. I'll try to reproduce your problem, and let's discuss this offline. ... Doug thanks, Yu -- 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 1/4] phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver
Hi,
Thank you for the review!
> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
> Sent: Friday, November 27, 2015 2:21 PM
>
> Hi,
>
> On Tuesday 20 October 2015 02:27 PM, Yoshihiro Shimoda wrote:
> > This patch adds support for R-Car generation 3 USB2 PHY driver.
> > This SoC has 3 EHCI/OHCI channels, and the channel 0 is shared
> > with the HSUSB (USB2.0 peripheral) device. And each channel has
> > independent registers about the PHYs.
> >
> > So, the purpose of this driver is:
> > 1) initializes some registers of SoC specific to use the
> > {ehci,ohci}-platform driver.
> >
> > 2) detects id pin to select host or peripheral on the channel 0.
> >
> > For now, this driver only supports 1) above.
>
> When you do 2), make sure to use the extcon framework.
Thank you for your proposal! I will use the extcon framework for it.
> One minor comment below and then I can queue it for 4.5.
Thank you!
< snip >
> > + provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> > + if (IS_ERR(provider)) {
> > + dev_err(dev, "Failed to register PHY provider\n");
> > + return PTR_ERR(provider);
> > + }
> > +
> > + return 0;
>
> This can simply be replaced with return PTR_ERR_OR_ZERO(provider);
Yes, I tested that this could simply be replaced with "return
PTR_ERR_OR_ZERO(provider);".
So, should I send v6 patch?
Best regards,
Yoshihiro Shimoda
> Thanks
> Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/5] ARM: dts: sun9i: Add A80 PRCM clocks and reset control nodes
Dear Maxime,
On Thu, 26 Nov 2015 21:09:42 +0100
Maxime Ripard wrote:
> On Tue, Nov 24, 2015 at 06:27:09PM +0800, Jisheng Zhang wrote:
> > + Sebastian
> >
> > On Tue, 24 Nov 2015 17:32:15 +0800
> > Chen-Yu Tsai wrote:
> >
> > > This adds the supported PRCM clocks and reset controls to the A80 dtsi.
> > > The DAUDIO module clocks are not supported yet.
> > >
> > > Also update clock and reset phandles for r_uart.
> > >
> > > Signed-off-by: Chen-Yu Tsai
> > > ---
> > > arch/arm/boot/dts/sun9i-a80.dtsi | 79
> > > +++-
> > > 1 file changed, 78 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi
> > > b/arch/arm/boot/dts/sun9i-a80.dtsi
> > > index 1118bf5cc4fb..a4ce348c0831 100644
> > > --- a/arch/arm/boot/dts/sun9i-a80.dtsi
> > > +++ b/arch/arm/boot/dts/sun9i-a80.dtsi
> > > @@ -164,6 +164,14 @@
> > >"usb_phy2", "usb_hsic_12M";
> > > };
> > >
> > > + pll3: clk@0608 {
> > > + /* placeholder until implemented */
> > > + #clock-cells = <0>;
> > > + compatible = "fixed-clock";
> > > + clock-rate = <0>;
> > > + clock-output-names = "pll3";
> > > + };
> > > +
> > > pll4: clk@060c {
> > > #clock-cells = <0>;
> > > compatible = "allwinner,sun9i-a80-pll4-clk";
> > > @@ -350,6 +358,68 @@
> > > "apb1_uart2", "apb1_uart3",
> > > "apb1_uart4", "apb1_uart5";
> > > };
> > > +
> > > + cpus_clk: clk@08001410 {
> > > + compatible = "allwinner,sun9i-a80-cpus-clk";
> > > + reg = <0x08001410 0x4>;
> > > + #clock-cells = <0>;
> > > + clocks = <>, <>, <>, <>;
> > > + clock-output-names = "cpus";
> > > + };
> > > +
> > > + ahbs: ahbs_clk {
> > > + compatible = "fixed-factor-clock";
> > > + #clock-cells = <0>;
> > > + clock-div = <1>;
> > > + clock-mult = <1>;
> > > + clocks = <_clk>;
> > > + clock-output-names = "ahbs";
> > > + };
> >
> > Dear Sebastian and all,
> >
> > I just want to take the sunxi clk support in mainline for example.
> >
> > I'm not sure I understand correctly, it seems to me that some maintainers
> > draw a
> > line: "having a node for every clock" is a no, no[1]. But here we saw one
> > node for
> > cpus_clk and apbs below. And <0x08001410 0x4>; <0x0800141c 0x4>; shows they
> > are close each other, so should we merge them into a single clock complex
> > node
> > then use mfd, regmap in clk driver?
> >
> > But IMHO, sunxi dts nodes really represent real HW, so I still can't
> > understand
> > why we could not have each node for cpus_clk and apbs. Can you please kindly
> > teach me?
>
> I'm totally lacking any context, but I'll reply. My view on this is
> that they both represent the hardware, simply with a different model.
>
> This preference of the clk maintainers and active clk developers
> regarding the model to choose has evolved over time. When we started
> the sunxi support, having one node per clock was the preferred way to
> do things.
>
> Berlin came much later, and the preference at that time was to have
> the entire clock controller represented as single opaque block to the
> consumers.
>
> Both have pros and cons. The approach we took allows for an easier mix
> and match, especially if the clocks you have in one SoC are reused in
> others, without modifying the source code (or barely). AFAIK, this is
> also the approach took by mvebu, except that their clock tree is much
> much much simpler.
>
> The approach Berlin took allows to have an easier maintainance and
> more flexibility, for example to deal with clock registration
> ordering, or clocks that share registers.
>
> Our approach works just fine in our case, and I feel no incentive to
> move to the new model (quite the opposite actually), but I guess it
> also depends on how your clock controller is built, how many SoCs you
> have to support, and how much clocks they are sharing.
Great! Thank you a lot for the detailed explanation. Now I can understand
why the clk drivers follow different models, I think I get Sebastian and
Stephen's view points. Although the BG4CT clock/pll IP are shared in all
newer than BG2Q SoCs (the only difference is how many clocks, how many plls,
and their register address), I'll follow Sebastian's suggestions -- one
entire clock controller node for all clocks/plls block
>
> I hope it clears things up.
Yes, it's clear now. I knew the history and the reason why there are different
models in clk drivers.
Will cook a newer BG4CT clk series for review.
Thank you,
Jisheng
--
To unsubscribe from this list: send the line "unsubscribe
[PATCH] driver:dma bug_fix : access freed memory
From 8f6aeb362d9e44f29d46ae7694cdfee4408406ce Mon Sep 17 00:00:00 2001
From: "KIM JUGNBAE"
Date: Thu, 26 Nov 2015 16:28:47 +0900
Subject: [PATCH] bug_fix : access freed memory
sync_fenc_free & fence_check_cb_func would be executed at
other cpu. fence_check_cb_func access freed fence memory after
kfree(fence) at sync_fence_free.
To escaped this issue, atomic_read(>status) need to be
protected by child_list_lock.
Signed-off-by: "kimjungbae\" " "
---
drivers/dma-buf/fence.c | 13 +
drivers/staging/android/sync.c | 10 +++---
drivers/staging/android/sync_debug.c |2 ++
include/linux/fence.h|1 +
4 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index 7bb9d65..d40211e 100644
--- a/drivers/dma-buf/fence.c
+++ b/drivers/dma-buf/fence.c
@@ -310,6 +310,19 @@ fence_remove_callback(struct fence *fence, struct fence_cb
*cb)
}
EXPORT_SYMBOL(fence_remove_callback);
+bool
+fence_remove_callback_locked(struct fence *fence, struct fence_cb *cb)
+{
+ bool ret;
+
+ ret = !list_empty(>node);
+ if (ret)
+ list_del_init(>node);
+
+ return ret;
+}
+EXPORT_SYMBOL(fence_remove_callback_locked);
+
struct default_wait_cb {
struct fence_cb base;
struct task_struct *task;
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 83f640f..9b60542 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -518,12 +518,16 @@ static const struct fence_ops android_fence_ops = {
static void sync_fence_free(struct kref *kref)
{
struct sync_fence *fence = container_of(kref, struct sync_fence, kref);
- int i, status = atomic_read(>status);
+ int i;
+ unsigned long flags;
for (i = 0; i < fence->num_fences; ++i) {
- if (status)
- fence_remove_callback(fence->cbs[i].sync_pt,
+ spin_lock_irqsave(fence->cbs[i].sync_pt->lock, flags);
+ if (atomic_read(>status))
+ fence_remove_callback_locked(fence->cbs[i].sync_pt,
>cbs[i].cb);
+ spin_unlock_irqrestore(fence->cbs[i].sync_pt->lock, flags);
+
fence_put(fence->cbs[i].sync_pt);
}
diff --git a/drivers/staging/android/sync_debug.c
b/drivers/staging/android/sync_debug.c
index 0153cd2..e854f35 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -155,7 +155,9 @@ static void sync_print_fence(struct seq_file *s, struct
sync_fence *fence)
container_of(fence->cbs[i].sync_pt,
struct sync_pt, base);
+ spin_lock_irqsave(pt->base.lock, flags);
sync_print_pt(s, pt, true);
+ spin_unlock_irqrestore(pt->base.lock, flags);
}
spin_lock_irqsave(>wq.lock, flags);
diff --git a/include/linux/fence.h b/include/linux/fence.h
index d174585..a5a3fd1 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -224,6 +224,7 @@ signed long fence_default_wait(struct fence *fence, bool
intr, signed long timeo
int fence_add_callback(struct fence *fence, struct fence_cb *cb,
fence_func_t func);
bool fence_remove_callback(struct fence *fence, struct fence_cb *cb);
+bool fence_remove_callback_locked(struct fence *fence, struct fence_cb *cb);
void fence_enable_sw_signaling(struct fence *fence);
/**
--
1.7.9.5
N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{콗喩zX㎍썳變}찠꼿쟺�:+v돣�쳭喩zZ+�+zf＂톒쉱�~넮녬i鎬z� 췿ⅱ�?솳鈺�&�)刪f뷌^j푹y쬶끷@A첺뛴
0띠h��뭝
[PATCH v3 1/2] perf tools: Always give options even it not compiled
This patch keeps options of perf builtins same in all conditions. If
one option is disabled because of compiling options, users should be
notified.
Masami suggested another implementation in [1] that, by adding a
OPTION_NEXT_DEPENDS option before those options in the 'struct option'
array, options parser knows an option is disabled. However, in some
cases this array is reordered (options__order()). In addition, in
parse-option.c that array is const, so we can't simply merge
information in decorator option into the affacted option.
This patch chooses a simpler implementation that, introducing a
set_option_nobuild() function and two option parsing flags. Builtins
with such options should call set_option_nobuild() before option
parsing. The complexity of this patch is because we want some of options
can be skipped safely. In this case their arguments should also be
consumed.
Options in 'perf record' and 'perf probe' are fixed in this patch.
[1]
http://lkml.kernel.org/g/50399556c9727b4d88a595c8584aab3752627...@gsjptkydcembx32.service.hitachi.net
Test result:
Normal case:
# ./perf probe --vmlinux /tmp/vmlinux sys_write
Added new event:
probe:sys_write (on sys_write)
You can now use it in all perf tools, such as:
perf record -e probe:sys_write -aR sleep 1
Build with NO_DWARF=1:
# ./perf probe -L sys_write
Error: switch `L' is not built because NO_DWARF=1
Usage: perf probe [] 'PROBEDEF' ['PROBEDEF' ...]
or: perf probe [] --add 'PROBEDEF' [--add 'PROBEDEF' ...]
or: perf probe [] --del '[GROUP:]EVENT' ...
or: perf probe --list [GROUP:]EVENT ...
or: perf probe [] --funcs
-L, --line
Show source code lines.
(not build because NO_DWARF=1)
# ./perf probe -k /tmp/vmlinux sys_write
Warning: switch `k' is not built because NO_DWARF=1
Added new event:
probe:sys_write (on sys_write)
You can now use it in all perf tools, such as:
perf record -e probe:sys_write -aR sleep 1
# ./perf probe --vmlinux /tmp/vmlinux sys_write
Warning: option `vmlinux' is not built because NO_DWARF=1
Added new event:
[SNIP]
# ./perf probe -l
Usage: perf probe [] 'PROBEDEF' ['PROBEDEF' ...]
or: perf probe [] --add 'PROBEDEF' [--add 'PROBEDEF' ...]
...
-k, --vmlinux vmlinux pathname
(not build because NO_DWARF=1)
-L, --line
Show source code lines.
(not build because NO_DWARF=1)
...
-V, --vars
Show accessible variables on PROBEDEF
(not build because NO_DWARF=1)
--externs Show external variables too (with --vars only)
(not build because NO_DWARF=1)
--no-inlines Don't search inlined functions
(not build because NO_DWARF=1)
--range Show variables location range in scope (with --vars
only)
(not build because NO_DWARF=1)
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Arnaldo Carvalho de Melo
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: pi3or...@163.com
---
tools/perf/builtin-probe.c | 15 +-
tools/perf/builtin-record.c | 9 +++-
tools/perf/util/parse-options.c | 113
tools/perf/util/parse-options.h | 5 ++
4 files changed, 129 insertions(+), 13 deletions(-)
diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 132afc9..dbe2ea5 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -249,6 +249,9 @@ static int opt_show_vars(const struct option *opt,
return ret;
}
+#else
+# define opt_show_lines NULL
+# define opt_show_vars NULL
#endif
static int opt_add_probe_event(const struct option *opt,
const char *str, int unset __maybe_unused)
@@ -473,7 +476,6 @@ __cmd_probe(int argc, const char **argv, const char *prefix
__maybe_unused)
opt_add_probe_event),
OPT_BOOLEAN('f', "force", _conf.force_add, "forcibly add events"
" with existing name"),
-#ifdef HAVE_DWARF_SUPPORT
OPT_CALLBACK('L', "line", NULL,
"FUNC[:RLN[+NUM|-RLN2]]|SRC:ALN[+NUM|-ALN2]",
"Show source code lines.", opt_show_lines),
@@ -490,7 +492,6 @@ __cmd_probe(int argc, const char **argv, const char *prefix
__maybe_unused)
"directory", "path to kernel source"),
OPT_BOOLEAN('\0', "no-inlines", _conf.no_inlines,
"Don't search inlined functions"),
-#endif
OPT__DRY_RUN(_event_dry_run),
OPT_INTEGER('\0', "max-probes", _conf.max_probes,
"Set how many probe points can be found for a probe."),
@@ -521,6 +522,16 @@ __cmd_probe(int argc, const char **argv, const char
*prefix __maybe_unused)
#ifdef HAVE_DWARF_SUPPORT
set_option_flag(options, 'L', "line", PARSE_OPT_EXCLUSIVE);
[PATCH v3 2/2] perf record: Support custom vmlinux path
From: He Kuang
Make perf-record command support --vmlinux option if BPF_PROLOGUE is on.
'perf record' needs vmlinux as the source of DWARF info to generate
prologue for BPF programs, so path of vmlinux should be specified.
Short name 'k' has been taken by 'clockid'. This patch skips the short
option name and use '--vmlinux' for vmlinux path.
Documentation is also updated.
Test result:
In a production (or broken) environment:
(built by
# rm -rf ~/.debug/
# mv /lib/modules/`uname -r`/build/vmlinux /tmp/
)
# ./perf record -e ./test_bpf_base.c ls
Failed to find the path for kernel: No such file or directory
event syntax error: './test_bpf_base.c'
\___ You need to check probing points in BPF file
...
# ./perf record --vmlinux /tmp/vmlinux -e ./test_bpf_base.c ls
...
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.011 MB perf.data ]
Help messages when build with NO_LIBBPF:
# ./perf record -h
--transaction sample transaction flags (special events only)
--vmlinux vmlinux pathname
(not build because NO_LIBBPF=1)
# ./perf record --vmlinux /tmp/vmlinux ls /
Warning: option `vmlinux' is not built because NO_LIBBPF=1
...
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.011 MB perf.data (11 samples) ]
Help messages when build with NO_DWARF:
# ./perf record -h
--transaction sample transaction flags (special events only)
--vmlinux vmlinux pathname
(not build because NO_DWARF=1)
Signed-off-by: He Kuang
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Arnaldo Carvalho de Melo
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: pi3or...@163.com
---
tools/perf/Documentation/perf-record.txt | 10 --
tools/perf/builtin-record.c | 16
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index e630a7d..8d032f4 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -314,11 +314,17 @@ This option sets the time out limit. The default value is
500 ms.
Record context switch events i.e. events of type PERF_RECORD_SWITCH or
PERF_RECORD_SWITCH_CPU_WIDE.
---clang-path::
+--clang-path=PATH::
Path to clang binary to use for compiling BPF scriptlets.
+(enabled when BPF support is on)
---clang-opt::
+--clang-opt=OPTIONS::
Options passed to clang when compiling BPF scriptlets.
+(enabled when BPF support is on)
+
+--vmlinux=PATH::
+Specify vmlinux path which has debuginfo.
+(enabled when BPF prologue is on)
SEE ALSO
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 11bf32d..2230b85 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1128,6 +1128,8 @@ struct option __record_options[] = {
"clang binary to use for compiling BPF scriptlets"),
OPT_STRING(0, "clang-opt", _param.clang_opt, "clang options",
"options passed to clang when compiling BPF scriptlets"),
+ OPT_STRING(0, "vmlinux", _conf.vmlinux_name,
+ "file", "vmlinux pathname"),
OPT_END()
};
@@ -1146,6 +1148,20 @@ int cmd_record(int argc, const char **argv, const char
*prefix __maybe_unused)
# undef set_nobuild
#endif
+#ifndef HAVE_BPF_PROLOGUE
+# if !defined (HAVE_DWARF_SUPPORT)
+# define REASON "NO_DWARF=1"
+# elif !defined (HAVE_LIBBPF_SUPPORT)
+# define REASON "NO_LIBBPF=1"
+# else
+# define REASON "this architecture doesn't support BPF prologue"
+# endif
+# define set_nobuild(s, l, c) set_option_nobuild(record_options, s, l, REASON,
c)
+ set_nobuild('\0', "vmlinux", true);
+# undef set_nobuild
+# undef REASON
+#endif
+
rec->evlist = perf_evlist__new();
if (rec->evlist == NULL)
return -ENOMEM;
--
1.8.3.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 v3 0/2] perf tools: Builtin options related improvements
According to Arnaldo's suggestion, patch 1/2 ensures options always there even if they are not build. When user tries to use a not build option, error or warning messages would tell them the reason. Patch 2/2 adds vmlinux option to perf record to support BPF argument fetching better. Without this patch vmlinux must be reside in standard path for BPF loader finding it. He Kuang (1): perf record: Support custom vmlinux path Wang Nan (1): perf tools: Always give options even it not compiled tools/perf/Documentation/perf-record.txt | 10 ++- tools/perf/builtin-probe.c | 15 +++- tools/perf/builtin-record.c | 25 ++- tools/perf/util/parse-options.c | 113 --- tools/perf/util/parse-options.h | 5 ++ 5 files changed, 153 insertions(+), 15 deletions(-) -- 1.8.3.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] mm/mmap.c: remove incorrect MAP_FIXED flag comparison from mmap_region
On Mon, Nov 23, 2015 at 06:36:42PM +0100, Piotr Kwapulinski wrote: > The following flag comparison in mmap_region makes no sense: > > if (!(vm_flags & MAP_FIXED)) > return -ENOMEM; > > The condition is always false and thus the above "return -ENOMEM" is never > executed. The vm_flags must not be compared with MAP_FIXED flag. > The vm_flags may only be compared with VM_* flags. > MAP_FIXED has the same value as VM_MAYREAD. > Hitting the rlimit is a slow path and find_vma_intersection should realize > that there is no overlapping VMA for !MAP_FIXED case pretty quickly. > > Remove the code that makes no sense. > > Signed-off-by: Piotr Kwapulinski Looks good to me. Thank you. Reviewed-by: Naoya Horiguchi > --- > mm/mmap.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/mm/mmap.c b/mm/mmap.c > index 2ce04a6..42a8259 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -1551,9 +1551,6 @@ unsigned long mmap_region(struct file *file, unsigned > long addr, >* MAP_FIXED may remove pages of mappings that intersects with >* requested mapping. Account for the pages it would unmap. >*/ > - if (!(vm_flags & MAP_FIXED)) > - return -ENOMEM; > - > nr_pages = count_vma_pages_range(mm, addr, addr + len); > > if (!may_expand_vm(mm, (len >> PAGE_SHIFT) - nr_pages)) > -- > 2.6.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 1/8] kernfs: Add API to generate relative kernfs path
On Tue, Nov 24, 2015 at 11:16:30AM -0500, Tejun Heo wrote:
> Hello,
>
> On Mon, Nov 16, 2015 at 01:51:38PM -0600, se...@hallyn.com wrote:
> > +static char * __must_check kernfs_path_from_node_locked(
(Note I've rewritten this to find a common ancestor and walk back to
and from that, as you suggested later in this email)
> > + /* Short-circuit the easy case - kn_to is the root node. */
> > + if ((kn_from == kn_to) || (!kn_from && !kn_to->parent)) {
> > + *p = '/';
> > + *(p + 1) = '\0';
>
> Hmm... so if kn_from == kn_to, the output is "/"?
Yes, that's what seems to make the most sense for cgroup namespaces. I
could see a case for '.' being used instead in general, but for cgroup
namespaces I think we'd have to convert those back to '/'. Otherwise
we'll fail in being able to run legacy software, which would get
confused.
-serge
--
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.2 16/52] ext4, jbd2: ensure entering into panic after recording an error in superblock
It looks good. Thank you. :-)
--- Original Message ---
Sender : Ben Hutchings
Date : 2015-11-25 07:33 (GMT+09:00)
Title : [PATCH 3.2 16/52] ext4, jbd2: ensure entering into panic after
recording an error in superblock
3.2.74-rc1 review patch. If anyone has any objections, please let me know.
--
From: Daeho Jeong
commit 4327ba52afd03fc4b5afa0ee1d774c9c5b0e85c5 upstream.
If a EXT4 filesystem utilizes JBD2 journaling and an error occurs, the
journaling will be aborted first and the error number will be recorded
into JBD2 superblock and, finally, the system will enter into the
panic state in "errors=panic" option. But, in the rare case, this
sequence is little twisted like the below figure and it will happen
that the system enters into panic state, which means the system reset
in mobile environment, before completion of recording an error in the
journal superblock. In this case, e2fsck cannot recognize that the
filesystem failure occurred in the previous run and the corruption
wouldn't be fixed.
Task ATask B
ext4_handle_error()
-> jbd2_journal_abort()
-> __journal_abort_soft()
-> __jbd2_journal_abort_hard()
| -> journal->j_flags |= JBD2_ABORT;
|
| __ext4_abort()
| -> jbd2_journal_abort()
| | -> __journal_abort_soft()
| | -> if (journal->j_flags & JBD2_ABORT)
| | return;
| -> panic()
|
-> jbd2_journal_update_sb_errno()
Tested-by: Hobin Woo
Signed-off-by: Daeho Jeong
Signed-off-by: Theodore Ts'o
Signed-off-by: Ben Hutchings
---
fs/ext4/super.c | 12 ++--
fs/jbd2/journal.c| 6 +-
include/linux/jbd2.h | 1 +
3 files changed, 16 insertions(+), 3 deletions(-)
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -463,9 +463,13 @@ static void ext4_handle_error(struct sup
ext4_msg(sb, KERN_CRIT, "Remounting filesystem read-only");
sb->s_flags |= MS_RDONLY;
}
- if (test_opt(sb, ERRORS_PANIC))
+ if (test_opt(sb, ERRORS_PANIC)) {
+ if (EXT4_SB(sb)->s_journal &&
+ !(EXT4_SB(sb)->s_journal->j_flags & JBD2_REC_ERR))
+ return;
panic("EXT4-fs (device %s): panic forced after error\n",
sb->s_id);
+ }
}
void __ext4_error(struct super_block *sb, const char *function,
@@ -628,8 +632,12 @@ void __ext4_abort(struct super_block *sb
jbd2_journal_abort(EXT4_SB(sb)->s_journal, -EIO);
save_error_info(sb, function, line);
}
- if (test_opt(sb, ERRORS_PANIC))
+ if (test_opt(sb, ERRORS_PANIC)) {
+ if (EXT4_SB(sb)->s_journal &&
+ !(EXT4_SB(sb)->s_journal->j_flags & JBD2_REC_ERR))
+ return;
panic("EXT4-fs panic from previous error\n");
+ }
}
void ext4_msg(struct super_block *sb, const char *prefix, const char *fmt, ...)
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -1956,8 +1956,12 @@ static void __journal_abort_soft (journa
__jbd2_journal_abort_hard(journal);
- if (errno)
+ if (errno) {
jbd2_journal_update_sb_errno(journal);
+ write_lock(>j_state_lock);
+ journal->j_flags |= JBD2_REC_ERR;
+ write_unlock(>j_state_lock);
+ }
}
/**
--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -954,6 +954,7 @@ struct journal_s
#define JBD2_ABORT_ON_SYNCDATA_ERR 0x040 /* Abort the journal on file
* data write error in ordered
* mode */
+#define JBD2_REC_ERR 0x080 /* The errno in the sb has been recorded */
/*
* Function declarations for the journaling transaction and buffer
Re: [PATCH v5 1/4] phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver
Hi,
On Tuesday 20 October 2015 02:27 PM, Yoshihiro Shimoda wrote:
> This patch adds support for R-Car generation 3 USB2 PHY driver.
> This SoC has 3 EHCI/OHCI channels, and the channel 0 is shared
> with the HSUSB (USB2.0 peripheral) device. And each channel has
> independent registers about the PHYs.
>
> So, the purpose of this driver is:
> 1) initializes some registers of SoC specific to use the
> {ehci,ohci}-platform driver.
>
> 2) detects id pin to select host or peripheral on the channel 0.
>
> For now, this driver only supports 1) above.
When you do 2), make sure to use the extcon framework.
One minor comment below and then I can queue it for 4.5.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 37
> drivers/phy/Kconfig| 7 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-rcar-gen3-usb2.c | 219
> +
> 4 files changed, 264 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> create mode 100644 drivers/phy/phy-rcar-gen3-usb2.c
>
> diff --git a/drivers/phy/phy-rcar-gen3-usb2.c
> b/drivers/phy/phy-rcar-gen3-usb2.c
> new file mode 100644
> index 000..9d9cf26
> --- /dev/null
> +++ b/drivers/phy/phy-rcar-gen3-usb2.c
> @@ -0,0 +1,219 @@
> +/*
> + * Renesas R-Car Gen3 for USB2.0 PHY driver
> + *
> + * Copyright (C) 2015 Renesas Electronics Corporation
> + *
> + * This is based on the phy-rcar-gen2 driver:
> + * Copyright (C) 2014 Renesas Solutions Corp.
> + * Copyright (C) 2014 Cogent Embedded, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*** USB2.0 Host registers (original offset is +0x200) ***/
> +#define USB2_INT_ENABLE 0x000
> +#define USB2_USBCTR 0x00c
> +#define USB2_SPD_RSM_TIMSET 0x10c
> +#define USB2_OC_TIMSET 0x110
> +
> +/* INT_ENABLE */
> +#define USB2_INT_ENABLE_USBH_INTB_EN BIT(2)
> +#define USB2_INT_ENABLE_USBH_INTA_EN BIT(1)
> +#define USB2_INT_ENABLE_INIT (USB2_INT_ENABLE_USBH_INTB_EN | \
> + USB2_INT_ENABLE_USBH_INTA_EN)
> +
> +/* USBCTR */
> +#define USB2_USBCTR_DIRPDBIT(2)
> +#define USB2_USBCTR_PLL_RST BIT(1)
> +
> +/* SPD_RSM_TIMSET */
> +#define USB2_SPD_RSM_TIMSET_INIT 0x014e029b
> +
> +/* OC_TIMSET */
> +#define USB2_OC_TIMSET_INIT 0x000209ab
> +
> +/*** HSUSB registers (original offset is +0x100) ***/
> +#define HSUSB_LPSTS 0x02
> +#define HSUSB_UGCTRL20x84
> +
> +/* Low Power Status register (LPSTS) */
> +#define HSUSB_LPSTS_SUSPM0x4000
> +
> +/* USB General control register 2 (UGCTRL2) */
> +#define HSUSB_UGCTRL2_MASK 0x0031 /* bit[31:6] should be 0 */
> +#define HSUSB_UGCTRL2_USB0SEL0x0030
> +#define HSUSB_UGCTRL2_USB0SEL_HOST 0x0010
> +#define HSUSB_UGCTRL2_USB0SEL_HS_USB 0x0020
> +#define HSUSB_UGCTRL2_USB0SEL_OTG0x0030
> +
> +struct rcar_gen3_data {
> + void __iomem *base;
> + struct clk *clk;
> +};
> +
> +struct rcar_gen3_chan {
> + struct rcar_gen3_data usb2;
> + struct rcar_gen3_data hsusb;
> + struct phy *phy;
> +};
> +
> +static int rcar_gen3_phy_usb2_init(struct phy *p)
> +{
> + struct rcar_gen3_chan *channel = phy_get_drvdata(p);
> + void __iomem *usb2_base = channel->usb2.base;
> + void __iomem *hsusb_base = channel->hsusb.base;
> + u32 val;
> +
> + /* Initialize USB2 part */
> + writel(USB2_INT_ENABLE_INIT, usb2_base + USB2_INT_ENABLE);
> + writel(USB2_SPD_RSM_TIMSET_INIT, usb2_base + USB2_SPD_RSM_TIMSET);
> + writel(USB2_OC_TIMSET_INIT, usb2_base + USB2_OC_TIMSET);
> +
> + /* Initialize HSUSB part */
> + if (hsusb_base) {
> + /* TODO: support "OTG" mode */
> + val = readl(hsusb_base + HSUSB_UGCTRL2);
> + val = (val & ~HSUSB_UGCTRL2_USB0SEL) |
> + HSUSB_UGCTRL2_USB0SEL_HOST;
> + writel(val & HSUSB_UGCTRL2_MASK, hsusb_base + HSUSB_UGCTRL2);
> + }
> +
> + return 0;
> +}
> +
> +static int rcar_gen3_phy_usb2_exit(struct phy *p)
> +{
> + struct rcar_gen3_chan *channel = phy_get_drvdata(p);
> +
> + writel(0, channel->usb2.base + USB2_INT_ENABLE);
> +
> + return 0;
> +}
> +
> +static int rcar_gen3_phy_usb2_power_on(struct phy *p)
> +{
> + struct rcar_gen3_chan *channel = phy_get_drvdata(p);
> + void __iomem *usb2_base = channel->usb2.base;
> + void __iomem *hsusb_base = channel->hsusb.base;
> + u32 val;
> +
> + val = readl(usb2_base + USB2_USBCTR);
> + val |= USB2_USBCTR_PLL_RST;
> + writel(val,
Re: [PATCH 7/8] cgroup: mount cgroupns-root when inside non-init cgroupns
On Tue, Nov 24, 2015 at 12:16:10PM -0500, Tejun Heo wrote:
> Hello,
>
> On Mon, Nov 16, 2015 at 01:51:44PM -0600, se...@hallyn.com wrote:
> > +struct dentry *kernfs_obtain_root(struct super_block *sb,
> > + struct kernfs_node *kn)
> > +{
> > + struct dentry *dentry;
> > + struct inode *inode;
> > +
> > + BUG_ON(sb->s_op != _sops);
> > +
> > + /* inode for the given kernfs_node should already exist. */
> > + inode = ilookup(sb, kn->ino);
> > + if (!inode) {
> > + pr_debug("kernfs: could not get inode for '");
> > + pr_cont_kernfs_path(kn);
> > + pr_cont("'.\n");
> > + return ERR_PTR(-EINVAL);
> > + }
>
> Hmmm... but inode might not have been instantiated yet. Why not use
> kernfs_get_inode()?
>
> > + /* instantiate and link root dentry */
> > + dentry = d_obtain_root(inode);
> > + if (!dentry) {
> > + pr_debug("kernfs: could not get dentry for '");
> > + pr_cont_kernfs_path(kn);
> > + pr_cont("'.\n");
> > + return ERR_PTR(-ENOMEM);
> > + }
> > +
> > + /* If this is a new dentry, set it up. We need kernfs_mutex because this
> > +* may be called by callers other than kernfs_fill_super. */
>
> Formatting.
>
> > + mutex_lock(_mutex);
> > + if (!dentry->d_fsdata) {
> > + kernfs_get(kn);
> > + dentry->d_fsdata = kn;
> > + } else {
> > + WARN_ON(dentry->d_fsdata != kn);
> > + }
> > + mutex_unlock(_mutex);
> > +
> > + return dentry;
> > +}
>
> Wouldn't it be simpler to walk dentry from kernfs root than
> duplicating dentry instantiation?
Sorry I don't think I'm following. Are you suggesting walking the
kn->parent chain backward and doing d_lookup() at each point starting
with sb->s_root?
--
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/
linux-next: Tree for Nov 27
Hi all, Reminder: there will be no linux-next release next week (Nov 30 - Dec 4). Changes since 20151126: The modules tree gained a build failure so I used the version from next-20151126. Non-merge commits (relative to Linus' tree): 2942 3585 files changed, 110232 insertions(+), 42648 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 231 trees (counting Linus' and 36 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (78c4a49a69e9 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs) Merging fixes/master (25cb62b76430 Linux 4.3-rc5) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (2e22502c080f ARC: dw2 unwind: Remove falllback linear search thru FDE entries) Merging arm-current/fixes (28fa99b7645a ARM: wire up mlock2 syscall) Merging m68k-current/for-linus (21d380e54c30 m68k: Wire up mlock2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (7f821fc9c77a powerpc/tm: Check for already reclaimed tasks) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (2c302e7e4105 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging net/master (c9da161c6517 bpf: fix clearing on persistent program array maps) Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops) Merging ipvs/master (086f332167d6 netfilter: nf_tables: add clone interface to expression operations) Merging wireless-drivers/master (eeec5d0ef7ee rtlwifi: rtl8821ae: Fix lockups on boot) Merging mac80211/master (b47d8f272d3b mac80211: do not actively scan DFS channels) Merging sound-current/for-linus (0c25ad80408e ALSA: hda - Fix noise on Gigabyte Z170X mobo) Merging pci-current/for-linus (7c7a0e945349 ARM/PCI: Move align_resource function pointer to pci_host_bridge structure) Merging driver-core.current/driver-core-linus (8005c49d9aea Linux 4.4-rc1) Merging tty.current/tty-linus (1ec218373b8e Linux 4.4-rc2) Merging usb.current/usb-linus (1ec218373b8e Linux 4.4-rc2) Merging usb-gadget-fixes/fixes (f74875dc3613 usb: dwc2: fix kernel oops during driver probe) Merging usb-serial-fixes/usb-linus (a0e80fbd56b4 USB: serial: Another Infineon flash loader USB ID) Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: fix a possible NULL dereference) Merging staging.current/staging-linus (1ec218373b8e Linux 4.4-rc2) Merging char-misc.current/char-misc-linus (e8c77bda05e5 fpga manager: Fix firmware resource leak on error) Merging input-current/for-linus (0c6da0733bff Input: parkbd - clear unused function pointers) Merging crypto-current/master (79960943fdc1 crypto: talitos - Fix timing leak in ESP ICV verification) Merging ide/master (1b1050cdc5cd Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr()) Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue) Merging kselftest-fixes/fixes (2ce47b44b25d selftests/seccomp: Get page size from sysconf) Merging backlight-fixes/for-backlight-fixes (68feaca
Re: [PATCH] ARM: dts: dra72-evm: Mark uart1 rxd as wakeup capable
On 11/26/2015 02:31 AM, Vignesh R wrote:
> Uart1 rxd is wakeup capable on DRA72 EVM. Hence, mark rxd line as
> wakeup capable. This is similar to commit 66b0436977e2c ("ARM: dts:
> dra7-evm: Mark uart1 rxd as wakeup capable") for DRA74 EVM.
>
> Signed-off-by: Vignesh R
> ---
> arch/arm/boot/dts/dra72-evm.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
> index d6104d5f0c01..8bf36b0b3c33 100644
> --- a/arch/arm/boot/dts/dra72-evm.dts
> +++ b/arch/arm/boot/dts/dra72-evm.dts
> @@ -478,6 +478,8 @@
>
> {
> status = "okay";
> + interrupts-extended = <_mpu GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
> + <_pmx_core 0x3e0>;
> };
>
> {
>
Acked-by: Nishanth Menon
--
Regards,
Nishanth Menon
--
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/
->poll() instances shouldn't be indefinitely blocking
Take a look at this:
static unsigned int gsc_m2m_poll(struct file *file,
struct poll_table_struct *wait)
{
struct gsc_ctx *ctx = fh_to_ctx(file->private_data);
struct gsc_dev *gsc = ctx->gsc_dev;
int ret;
if (mutex_lock_interruptible(>lock))
return -ERESTARTSYS;
ret = v4l2_m2m_poll(file, ctx->m2m_ctx, wait);
mutex_unlock(>lock);
return ret;
}
a) ->poll() should not return -E...; callers expect just a bitmap of
POLL... values.
b) sure, it's nice that if this thing hangs, we'll be able to kill it.
However, if one's ->poll() can hang indefinitely, it means bad things
for poll(2), select(2), etc. semantics. What the hell had been intended
there?
c) a bunch of v4l2_m2m_poll() callers are also taking some kind of
mutex; AFAICS, all of those appear bogus (the rest of them do not
play wiht ERESTARTSYS, just plain mutex_lock() for those).
What's going on there?
--
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 2/3] PM / OPP: Parse 'opp-supported-hw' binding
On 25-11-15, 12:51, Stephen Boyd wrote:
> > +int dev_pm_opp_set_supported_hw(struct device *dev, const u32 *versions,
> > + unsigned int count)
> > +{
> > + struct device_opp *dev_opp;
> > + int ret = 0;
> > +
> > + /* Hold our list modification lock here */
> > + mutex_lock(_opp_list_lock);
> > +
> > + dev_opp = _add_device_opp(dev);
>
> So this function will publish an opp to the list...
Not an opp but opp-dev.
> > + if (!dev_opp) {
> > + ret = -ENOMEM;
> > + goto unlock;
> > + }
> > +
> > + /* Do we already have a version hierarchy associated with dev_opp? */
> > + if (dev_opp->supported_hw) {
> > + dev_err(dev, "%s: Already have supported hardware list\n",
> > + __func__);
> > + ret = -EBUSY;
> > + goto err;
> > + }
> > +
> > + dev_opp->supported_hw = kmemdup(versions, count * sizeof(*versions),
> > + GFP_KERNEL);
>
> And then we're going to modify said opp here under the mutex
> lock.
opp-dev ..
> > + if (!dev_opp->supported_hw) {
> > + ret = -ENOMEM;
> > + goto err;
> > + }
> > +
> > + dev_opp->supported_hw_count = count;
>
> So we've properly handled the concurrent writer case (which is
> probably not even real), but we have improperly handled the case
> where a reader is running in parallel to the writer. We should
> only list_add_rcu the pointer once we're done modifying the
> pointer we created. Otherwise a reader can come along and see the
> half initialized structure, which is not good.
This function will be called, from some platform code, before the OPP
table is initialized. It isn't useful to call it after the OPPs are
added for the device. So there wouldn't be any concurrent reader.
> I'm worried that the RCU locking is messed up in other places in
> this file now too. Hopefully not, but it's going to require an
> audit.
I do share your concern.. But this stuff should be okay. Even the
other patch as well.
--
viresh
--
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/
Freeing active kobject in pps_device_destruct
Hi, Fuzzing with syzkaller on the latest -next kernel produced this error: [ 1167.390182] WARNING: CPU: 14 PID: 607 at lib/debugobjects.c:263 debug_print_object+0x1c4/0x1e0() (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x90 [ 1167.392644] Modules linked in: [ 1167.393120] CPU: 14 PID: 607 Comm: kworker/14:1 Tainted: GW 4.4.0-rc2-next-20151126 sasha-5-g00d303e-dirty #2651 [ 1167.394563] Workqueue: events kobject_delayed_cleanup [ 1167.395226] 000e 6f32b107 8806b83478b8 ace6b5bb [ 1167.396254] 8806b8347928 8806b7b8 b515c7a0 8806b83478f8 [ 1167.397403] ab3531d3 aced0194 ed00d7068f21 b515c7a0 [ 1167.398499] Call Trace: [ 1167.398891] [] dump_stack+0x72/0xb7 [ 1167.399516] [] warn_slowpath_common+0x113/0x140 [ 1167.401705] [] warn_slowpath_fmt+0xcb/0x100 [ 1167.404799] [] debug_print_object+0x1c4/0x1e0 [ 1167.406723] [] __debug_check_no_obj_freed+0x215/0x7a0 [ 1167.409634] [] debug_check_no_obj_freed+0x2c/0x40 [ 1167.410301] [] kfree+0x1fc/0x2f0 [ 1167.410734] [] pps_device_destruct+0x107/0x110 [ 1167.413495] [] kobject_delayed_cleanup+0x34d/0x3b0 [ 1167.414049] [] process_one_work+0xab7/0x13b0 [ 1167.417188] [] worker_thread+0x93d/0xd20 [ 1167.418782] [] kthread+0x290/0x2b0 [ 1167.422467] [] ret_from_fork+0x3f/0x70 Thanks, Sasha -- 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] staging: lustre: remove IOC_LIBCFS_PING_TEST ioctl
On 2015/11/08, 09:34, "James Simmons" wrote:
>The ioctl IOC_LIBCFS_PING_TEST has not been used in
>ages. The recent nidstring changes which moved all
>the nidstring operations from libcfs to the LNet
>layer but this ioctl code was still using an
>nidstring operation that was causing an circular
>dependency loop between libcfs and LNet:
Hi Greg,
are you planning on pushing this patch to Linus for 4.4? It was resent
on 11/08 per your request on 11/07 but I don't see it in staging or
staging-next yet. Since it fixes the depmod dependency cycle for
allmodconfig builds on mainline it seems worthwhile to include into
4.4-rc3 rather than waiting for 4.5.
Cheers, Andreas
>Signed-off-by: James Simmons
>---
> .../lustre/include/linux/libcfs/libcfs_ioctl.h |1 -
> drivers/staging/lustre/lustre/libcfs/module.c | 17
>-
> 2 files changed, 0 insertions(+), 18 deletions(-)
>
>diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
>b/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
>index f5d741f..485ab26 100644
>--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
>+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
>@@ -110,7 +110,6 @@ struct libcfs_ioctl_handler {
> #define IOC_LIBCFS_CLEAR_DEBUG _IOWR('e', 31, long)
> #define IOC_LIBCFS_MARK_DEBUG _IOWR('e', 32, long)
> #define IOC_LIBCFS_MEMHOG _IOWR('e', 36, long)
>-#define IOC_LIBCFS_PING_TEST _IOWR('e', 37, long)
> /* lnet ioctls */
> #define IOC_LIBCFS_GET_NI _IOWR('e', 50, long)
> #define IOC_LIBCFS_FAIL_NID _IOWR('e', 51, long)
>diff --git a/drivers/staging/lustre/lustre/libcfs/module.c
>b/drivers/staging/lustre/lustre/libcfs/module.c
>index 570f05c..89038ed 100644
>--- a/drivers/staging/lustre/lustre/libcfs/module.c
>+++ b/drivers/staging/lustre/lustre/libcfs/module.c
>@@ -274,23 +274,6 @@ static int libcfs_ioctl_int(struct cfs_psdev_file
> }
> break;
>
>- case IOC_LIBCFS_PING_TEST: {
>- extern void (kping_client)(struct libcfs_ioctl_data *);
>- void (*ping)(struct libcfs_ioctl_data *);
>-
>- CDEBUG(D_IOCTL, "doing %d pings to nid %s (%s)\n",
>- data->ioc_count, libcfs_nid2str(data->ioc_nid),
>- libcfs_nid2str(data->ioc_nid));
>- ping = symbol_get(kping_client);
>- if (!ping)
>- CERROR("symbol_get failed\n");
>- else {
>- ping(data);
>- symbol_put(kping_client);
>- }
>- return 0;
>- }
>-
> default: {
> struct libcfs_ioctl_handler *hand;
>
>
>--
>1.7.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: tty,net: use-after-free in x25_asy_open_tty
On 11/20/2015 02:59 PM, Peter Hurley wrote: > Thanks for the report, Sasha. > Would you please test the patch below? Fixes it for me, thanks! Thanks, Sasha -- 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: [PATCHv12 32/37] thp: reintroduce split_huge_page()
On 11/18/2015 02:05 PM, Kirill A. Shutemov wrote: > Hm. This looks like THP leak. I fixed one with this patch: > > http://lkml.kernel.org/g/1447236567-68751-1-git-send-email-kirill.shute...@linux.intel.com > > It's in -mm tree, but there wasn't any releases since it's applied. It's > not in -next for this reason. > > There's one more patch with the same status: > > http://lkml.kernel.org/g/1447236557-68682-1-git-send-email-kirill.shute...@linux.intel.com I still see it in -next, with these two patches in. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] zram: pass gfp from zcomp frontend to backend
From: Minchan Kim
Each zcomp backend uses own gfp flag but it's pointless
because the context they could be called is driven by upper
layer(ie, zcomp frontend). As well, zcomp frondend could
call them in different context. One context(ie, zram init part)
is it should be better to make sure successful allocation
other context(ie, further stream allocation part for accelarating
I/O speed) is just optional so let's pass gfp down from driver
(ie, zcomp frontend) like normal MM convention.
[sergey: add missing __vmalloc zero and highmem gfps]
Signed-off-by: Minchan Kim
Acked-by: Sergey Senozhatsky
---
drivers/block/zram/zcomp.c | 24
drivers/block/zram/zcomp.h | 2 +-
drivers/block/zram/zcomp_lz4.c | 16 +++-
drivers/block/zram/zcomp_lzo.c | 16 +++-
4 files changed, 23 insertions(+), 35 deletions(-)
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index c536177..2bc4aea 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -74,18 +74,18 @@ static void zcomp_strm_free(struct zcomp *comp, struct
zcomp_strm *zstrm)
* allocate new zcomp_strm structure with ->private initialized by
* backend, return NULL on error
*/
-static struct zcomp_strm *zcomp_strm_alloc(struct zcomp *comp)
+static struct zcomp_strm *zcomp_strm_alloc(struct zcomp *comp, gfp_t flags)
{
- struct zcomp_strm *zstrm = kmalloc(sizeof(*zstrm), GFP_NOIO);
+ struct zcomp_strm *zstrm = kmalloc(sizeof(*zstrm), flags);
if (!zstrm)
return NULL;
- zstrm->private = comp->backend->create();
+ zstrm->private = comp->backend->create(flags);
/*
* allocate 2 pages. 1 for compressed data, plus 1 extra for the
* case when compressed size is larger than the original one
*/
- zstrm->buffer = (void *)__get_free_pages(GFP_NOIO | __GFP_ZERO, 1);
+ zstrm->buffer = (void *)__get_free_pages(flags | __GFP_ZERO, 1);
if (!zstrm->private || !zstrm->buffer) {
zcomp_strm_free(comp, zstrm);
zstrm = NULL;
@@ -120,8 +120,16 @@ static struct zcomp_strm *zcomp_strm_multi_find(struct
zcomp *comp)
/* allocate new zstrm stream */
zs->avail_strm++;
spin_unlock(>strm_lock);
-
- zstrm = zcomp_strm_alloc(comp);
+ /*
+* This function can be called in swapout/fs write path
+* so we can't use GFP_FS|IO. And it assumes we already
+* have at least one stream in zram initialization so we
+* don't do best effort to allocate more stream in here.
+* A default stream will work well without further multiple
+* streams. That's why we use NORETRY | NOWARN | NOMEMALLOC.
+*/
+ zstrm = zcomp_strm_alloc(comp, GFP_NOIO | __GFP_NORETRY |
+ __GFP_NOWARN | __GFP_NOMEMALLOC);
if (!zstrm) {
spin_lock(>strm_lock);
zs->avail_strm--;
@@ -209,7 +217,7 @@ static int zcomp_strm_multi_create(struct zcomp *comp, int
max_strm)
zs->max_strm = max_strm;
zs->avail_strm = 1;
- zstrm = zcomp_strm_alloc(comp);
+ zstrm = zcomp_strm_alloc(comp, GFP_KERNEL);
if (!zstrm) {
kfree(zs);
return -ENOMEM;
@@ -259,7 +267,7 @@ static int zcomp_strm_single_create(struct zcomp *comp)
comp->stream = zs;
mutex_init(>strm_lock);
- zs->zstrm = zcomp_strm_alloc(comp);
+ zs->zstrm = zcomp_strm_alloc(comp, GFP_KERNEL);
if (!zs->zstrm) {
kfree(zs);
return -ENOMEM;
diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
index 46e2b9f..b7d2a4b 100644
--- a/drivers/block/zram/zcomp.h
+++ b/drivers/block/zram/zcomp.h
@@ -33,7 +33,7 @@ struct zcomp_backend {
int (*decompress)(const unsigned char *src, size_t src_len,
unsigned char *dst);
- void *(*create)(void);
+ void *(*create)(gfp_t flags);
void (*destroy)(void *private);
const char *name;
diff --git a/drivers/block/zram/zcomp_lz4.c b/drivers/block/zram/zcomp_lz4.c
index f2bfced..dc2338d 100644
--- a/drivers/block/zram/zcomp_lz4.c
+++ b/drivers/block/zram/zcomp_lz4.c
@@ -15,24 +15,14 @@
#include "zcomp_lz4.h"
-static void *zcomp_lz4_create(void)
+static void *zcomp_lz4_create(gfp_t flags)
{
void *ret;
- /*
-* This function can be called in swapout/fs write path
-* so we can't use GFP_FS|IO. And it assumes we already
-* have at least one stream in zram initialization so we
-* don't do best effort to allocate more stream in here.
-* A default stream will work well without further multiple
-* streams. That's why we use NORETRY | NOWARN | NOMEMALLOC.
-*/
- ret =
[PATCH 2/2] zram/zcomp: do not zero out zcomp private pages
Do not __GFP_ZERO allocated zcomp ->private pages. We keep
allocated streams around and use them for read/write requests,
so we supply a zeroed out ->private to compression algorithm
as a scratch buffer only once -- the first time we use that
stream. For the rest of IO requests served by this stream
->private usually contains some temporarily data from the
previous requests.
Signed-off-by: Sergey Senozhatsky
---
drivers/block/zram/zcomp_lz4.c | 4 ++--
drivers/block/zram/zcomp_lzo.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/block/zram/zcomp_lz4.c b/drivers/block/zram/zcomp_lz4.c
index dc2338d..0110086 100644
--- a/drivers/block/zram/zcomp_lz4.c
+++ b/drivers/block/zram/zcomp_lz4.c
@@ -19,10 +19,10 @@ static void *zcomp_lz4_create(gfp_t flags)
{
void *ret;
- ret = kzalloc(LZ4_MEM_COMPRESS, flags);
+ ret = kmalloc(LZ4_MEM_COMPRESS, flags);
if (!ret)
ret = __vmalloc(LZ4_MEM_COMPRESS,
- flags | __GFP_ZERO | __GFP_HIGHMEM,
+ flags | __GFP_HIGHMEM,
PAGE_KERNEL);
return ret;
}
diff --git a/drivers/block/zram/zcomp_lzo.c b/drivers/block/zram/zcomp_lzo.c
index 0ab6fce..ed7a1f0 100644
--- a/drivers/block/zram/zcomp_lzo.c
+++ b/drivers/block/zram/zcomp_lzo.c
@@ -19,10 +19,10 @@ static void *lzo_create(gfp_t flags)
{
void *ret;
- ret = kzalloc(LZO1X_MEM_COMPRESS, flags);
+ ret = kmalloc(LZO1X_MEM_COMPRESS, flags);
if (!ret)
ret = __vmalloc(LZO1X_MEM_COMPRESS,
- flags | __GFP_ZERO | __GFP_HIGHMEM,
+ flags | __GFP_HIGHMEM,
PAGE_KERNEL);
return ret;
}
--
2.6.3.368.gf34be46
--
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/
[bug] mei_fasync() bogosity
in "mei: implement fasync for event notification" a ->fasync() instance is
added as
static int mei_fasync(int fd, struct file *file, int band)
{
struct mei_cl *cl = file->private_data;
if (!mei_cl_is_connected(cl))
return POLLERR;
return fasync_helper(fd, file, band, >ev_async);
}
Valid return values for ->fasync() are 0, 1 and -E...; 8 (aka POLLERR) is not.
What had been intended there? -ENODEV? Some other error? As it is, the
thing is broken.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] zram: cleanup stream's ->private allocation code
Hello, Two patches that 'cleanup' compression streams allocation. Patch #1 consolidates GFP flags used for stream's ->private allocation in underlying compression backends. Patch #2 drops GFP_ZERO flag from ->private allocation. This patch set depends on the patch set published here http://marc.info/?l=linux-kernel=144859748015849 Minchan Kim (1): zram: pass gfp from zcomp frontend to backend Sergey Senozhatsky (1): zram/zcomp: do not zero out zcomp private pages drivers/block/zram/zcomp.c | 24 drivers/block/zram/zcomp.h | 2 +- drivers/block/zram/zcomp_lz4.c | 16 +++- drivers/block/zram/zcomp_lzo.c | 16 +++- 4 files changed, 23 insertions(+), 35 deletions(-) -- 2.6.3.368.gf34be46 -- 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 v2 0/3] fixes for LightNVM
Hi Matias A couple of fixes based on 4.4rc2 Patch 1: the locking issue move codes 'register with device with a supported manager' into a funtion. But I think iterate over a list to register nvm device with a manger is not a good idea, since we can blocked in manager's register_mgr function while holding nvm_lock. Patch 2: handle targerts when underlying devices were removed free dev when exited call target type's exit function when target creation was aborted due to nvm device exit. Patch 3: change the interface between nvme and lightnvm remove the unnecessary nvme_ns->type set to zero Wenwei Tao (3): lightnvm: missing nvm_lock acquire lightnvm: handle targets when corresponding nvm device exit nvme: change the interface between nvme and lightnvm drivers/lightnvm/core.c | 197 ++- drivers/nvme/host/lightnvm.c | 17 +++- drivers/nvme/host/nvme.h | 1 + drivers/nvme/host/pci.c | 7 +- include/linux/lightnvm.h | 3 + 5 files changed, 143 insertions(+), 82 deletions(-) -- 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 v2 2/3] lightnvm: handle targets when corresponding nvm device exit
block creations of new targets, remove exiting targets when
underlying device was gone.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 128 +++
include/linux/lightnvm.h | 3 ++
2 files changed, 87 insertions(+), 44 deletions(-)
diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 071a3e4..984db2f 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -33,6 +33,17 @@ static LIST_HEAD(nvm_targets);
static LIST_HEAD(nvm_mgrs);
static LIST_HEAD(nvm_devices);
static DECLARE_RWSEM(nvm_lock);
+#define NVM_EXITING1
+
+static inline int NvmExiting(struct nvm_dev *dev)
+{
+ return ((unsigned long)dev->ppalist_pool & NVM_EXITING) != 0;
+}
+
+static inline void *ppalist_pool(struct nvm_dev *dev)
+{
+ return (void *)((unsigned long)dev->ppalist_pool & ~NVM_EXITING);
+}
static struct nvm_tgt_type *nvm_find_target_type(const char *name)
{
@@ -74,7 +85,7 @@ EXPORT_SYMBOL(nvm_unregister_target);
void *nvm_dev_dma_alloc(struct nvm_dev *dev, gfp_t mem_flags,
dma_addr_t *dma_handler)
{
- return dev->ops->dev_dma_alloc(dev->q, dev->ppalist_pool, mem_flags,
+ return dev->ops->dev_dma_alloc(dev->q, ppalist_pool(dev), mem_flags,
dma_handler);
}
EXPORT_SYMBOL(nvm_dev_dma_alloc);
@@ -82,7 +93,7 @@ EXPORT_SYMBOL(nvm_dev_dma_alloc);
void nvm_dev_dma_free(struct nvm_dev *dev, void *ppa_list,
dma_addr_t dma_handler)
{
- dev->ops->dev_dma_free(dev->ppalist_pool, ppa_list, dma_handler);
+ dev->ops->dev_dma_free(ppalist_pool(dev), ppa_list, dma_handler);
}
EXPORT_SYMBOL(nvm_dev_dma_free);
@@ -228,15 +239,6 @@ static int nvm_core_init(struct nvm_dev *dev)
return 0;
}
-static void nvm_free(struct nvm_dev *dev)
-{
- if (!dev)
- return;
-
- if (dev->mt)
- dev->mt->unregister_mgr(dev);
-}
-
static int nvm_init(struct nvm_dev *dev)
{
int ret = -EINVAL;
@@ -273,6 +275,7 @@ static int nvm_init(struct nvm_dev *dev)
up_write(_lock);
if (ret < 0)
goto err;
+ kref_init(>kref);
if (!ret)
return 0;
@@ -286,12 +289,48 @@ err:
return ret;
}
-static void nvm_exit(struct nvm_dev *dev)
+static void nvm_remove_target(struct nvm_target *t)
{
- if (dev->ppalist_pool)
- dev->ops->destroy_dma_pool(dev->ppalist_pool);
- nvm_free(dev);
+ struct nvm_tgt_type *tt = t->type;
+ struct gendisk *tdisk = t->disk;
+ struct request_queue *q = tdisk->queue;
+ lockdep_assert_held(_lock);
+
+ del_gendisk(tdisk);
+ if (tt->exit)
+ tt->exit(tdisk->private_data);
+
+ blk_cleanup_queue(q);
+
+ put_disk(tdisk);
+
+ list_del(>list);
+ kfree(t);
+}
+
+static inline void nvm_remove_targets(struct nvm_dev *dev)
+{
+ struct nvm_target *t, *n;
+
+ list_for_each_entry_safe(t, n, >online_targets, list)
+ nvm_remove_target(t);
+}
+
+static void nvm_exit(struct kref *kref)
+{
+ struct nvm_dev *dev;
+
+ dev = container_of(kref, struct nvm_dev, kref);
+ if (ppalist_pool(dev))
+ dev->ops->destroy_dma_pool(ppalist_pool(dev));
+
+ if (dev->mt)
+ dev->mt->unregister_mgr(dev);
+
+ if (dev->ops->dev_remove)
+ dev->ops->dev_remove(dev->q);
+ kfree(dev);
pr_info("nvm: successfully unloaded\n");
}
@@ -354,9 +393,10 @@ void nvm_unregister(char *disk_name)
}
list_del(>devices);
+ nvm_remove_targets(dev);
+ dev->ppalist_pool += NVM_EXITING;
up_write(_lock);
- nvm_exit(dev);
- kfree(dev);
+ kref_put(>kref, nvm_exit);
}
EXPORT_SYMBOL(nvm_unregister);
@@ -376,6 +416,10 @@ static int nvm_create_target(struct nvm_dev *dev,
int ret = 0;
down_write(_lock);
+ if (NvmExiting(dev)) {
+ up_write(_lock);
+ return -ENODEV;
+ }
if (!dev->mt) {
ret = register_mgr(dev);
if (!ret)
@@ -438,10 +482,18 @@ static int nvm_create_target(struct nvm_dev *dev,
t->disk = tdisk;
down_write(_lock);
+ if (NvmExiting(dev)) {
+ up_write(_lock);
+ goto err_nvm_exiting;
+ }
list_add_tail(>list, >online_targets);
up_write(_lock);
return 0;
+err_nvm_exiting:
+ del_gendisk(tdisk);
+ if (tt->exit)
+ tt->exit(tdisk->private_data);
err_init:
put_disk(tdisk);
err_queue:
@@ -451,62 +503,50 @@ err_t:
return -ENOMEM;
}
-static void nvm_remove_target(struct nvm_target *t)
-{
- struct nvm_tgt_type *tt = t->type;
- struct gendisk *tdisk = t->disk;
- struct request_queue *q =
[PATCH v2 1/3] lightnvm: missing nvm_lock acquire
To avoid race conditions, traverse dev, media manager,
and targeet lists and also register, unregister entries
to/from them, should be always under the nvm_lock control.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/core.c | 73 +
1 file changed, 38 insertions(+), 35 deletions(-)
diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
index 5178645..071a3e4 100644
--- a/drivers/lightnvm/core.c
+++ b/drivers/lightnvm/core.c
@@ -123,6 +123,24 @@ void nvm_unregister_mgr(struct nvmm_type *mt)
}
EXPORT_SYMBOL(nvm_unregister_mgr);
+/* register with device with a supported manager */
+static int register_mgr(struct nvm_dev *dev)
+{
+ struct nvmm_type *mt;
+ int ret = 0;
+
+ list_for_each_entry(mt, _mgrs, list) {
+ ret = mt->register_mgr(dev);
+ if (ret > 0) {
+ dev->mt = mt;
+ break; /* successfully initialized */
+ }
+ }
+ if (!ret)
+ pr_info("nvm: no compatible nvm manager found.\n");
+ return ret;
+}
+
static struct nvm_dev *nvm_find_nvm_dev(const char *name)
{
struct nvm_dev *dev;
@@ -221,7 +239,6 @@ static void nvm_free(struct nvm_dev *dev)
static int nvm_init(struct nvm_dev *dev)
{
- struct nvmm_type *mt;
int ret = -EINVAL;
if (!dev->q || !dev->ops)
@@ -251,22 +268,13 @@ static int nvm_init(struct nvm_dev *dev)
pr_err("nvm: could not initialize core structures.\n");
goto err;
}
-
- /* register with device with a supported manager */
- list_for_each_entry(mt, _mgrs, list) {
- ret = mt->register_mgr(dev);
- if (ret < 0)
- goto err; /* initialization failed */
- if (ret > 0) {
- dev->mt = mt;
- break; /* successfully initialized */
- }
- }
-
- if (!ret) {
- pr_info("nvm: no compatible manager found.\n");
+ down_write(_lock);
+ ret = register_mgr(dev);
+ up_write(_lock);
+ if (ret < 0)
+ goto err;
+ if (!ret)
return 0;
- }
pr_info("nvm: registered %s [%u/%u/%u/%u/%u/%u]\n",
dev->name, dev->sec_per_pg, dev->nr_planes,
@@ -335,18 +343,18 @@ EXPORT_SYMBOL(nvm_register);
void nvm_unregister(char *disk_name)
{
+ down_write(_lock);
struct nvm_dev *dev = nvm_find_nvm_dev(disk_name);
if (!dev) {
pr_err("nvm: could not find device %s to unregister\n",
disk_name);
+ up_write(_lock);
return;
}
- down_write(_lock);
list_del(>devices);
up_write(_lock);
-
nvm_exit(dev);
kfree(dev);
}
@@ -361,38 +369,30 @@ static int nvm_create_target(struct nvm_dev *dev,
{
struct nvm_ioctl_create_simple *s = >conf.s;
struct request_queue *tqueue;
- struct nvmm_type *mt;
struct gendisk *tdisk;
struct nvm_tgt_type *tt;
struct nvm_target *t;
void *targetdata;
int ret = 0;
+ down_write(_lock);
if (!dev->mt) {
- /* register with device with a supported NVM manager */
- list_for_each_entry(mt, _mgrs, list) {
- ret = mt->register_mgr(dev);
- if (ret < 0)
- return ret; /* initialization failed */
- if (ret > 0) {
- dev->mt = mt;
- break; /* successfully initialized */
- }
- }
-
- if (!ret) {
- pr_info("nvm: no compatible nvm manager found.\n");
- return -ENODEV;
+ ret = register_mgr(dev);
+ if (!ret)
+ ret = -ENODEV;
+ if (ret < 0) {
+ up_write(_lock);
+ return ret;
}
}
tt = nvm_find_target_type(create->tgttype);
if (!tt) {
pr_err("nvm: target type %s not found\n", create->tgttype);
+ up_write(_lock);
return -EINVAL;
}
- down_write(_lock);
list_for_each_entry(t, >online_targets, list) {
if (!strcmp(create->tgtname, t->disk->disk_name)) {
pr_err("nvm: target name already exists.\n");
@@ -475,8 +475,9 @@ static int __nvm_configure_create(struct nvm_ioctl_create
*create)
{
struct nvm_dev *dev;
struct nvm_ioctl_create_simple *s;
-
+ down_write(_lock);
dev = nvm_find_nvm_dev(create->dev);
+ up_write(_lock);
if (!dev) {
pr_err("nvm: device not found\n");
return
[PATCH v3 0/2] zram/zcomp: stream allocation fixes and tweaks
Hello, Two patches that address possible issues with compression stream allocations under low memory or heavy fragmentation conditions. These patches are considered to be a -stable material, however there is no Cc -stable on "zram: try vmalloc() after kmalloc()" as of now. We'd like to ask Kyeongdon to re-test and re-confirm (the patch has been modified). I split the patch set into separate threads. Two more patches - zram: pass gfp from zcomp frontend to backend (Minchan Kim) - zram/zcomp: do not zero out zcomp private pages (Sergey Senozhatsky) (not a -stable material) will be posted separately. Kyeongdon Kim (1): zram: try vmalloc() after kmalloc() Sergey Senozhatsky (1): zram/zcomp: use GFP_NOIO to allocate streams drivers/block/zram/zcomp.c | 4 ++-- drivers/block/zram/zcomp_lz4.c | 23 +-- drivers/block/zram/zcomp_lzo.c | 23 +-- 3 files changed, 44 insertions(+), 6 deletions(-) -- 2.6.3.368.gf34be46 -- 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] zram/zcomp: use GFP_NOIO to allocate streams
From: Sergey Senozhatsky
We can end up allocating a new compression stream with GFP_KERNEL
from within the IO path, which may result is nested (recursive) IO
operations. That can introduce problems if the IO path in question
is a reclaimer, holding some locks that will deadlock nested IOs.
Allocate streams and working memory using GFP_NOIO flag, forbidding
recursive IO and FS operations.
An example:
[ 747.233722] inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
[ 747.233724] git/20158 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 747.233725] (jbd2_handle){+.+.?.}, at: []
start_this_handle+0x4ca/0x555
[ 747.233733] {IN-RECLAIM_FS-W} state was registered at:
[ 747.233735] [] __lock_acquire+0x8da/0x117b
[ 747.233738] [] lock_acquire+0x10c/0x1a7
[ 747.233740] [] start_this_handle+0x52d/0x555
[ 747.233742] [] jbd2__journal_start+0xb4/0x237
[ 747.233744] [] __ext4_journal_start_sb+0x108/0x17e
[ 747.233748] [] ext4_dirty_inode+0x32/0x61
[ 747.233750] [] __mark_inode_dirty+0x16b/0x60c
[ 747.233754] [] iput+0x11e/0x274
[ 747.233757] [] __dentry_kill+0x148/0x1b8
[ 747.233759] [] shrink_dentry_list+0x274/0x44a
[ 747.233761] [] prune_dcache_sb+0x4a/0x55
[ 747.233763] [] super_cache_scan+0xfc/0x176
[ 747.233767] []
shrink_slab.part.14.constprop.25+0x2a2/0x4d3
[ 747.233770] [] shrink_zone+0x74/0x140
[ 747.233772] [] kswapd+0x6b7/0x930
[ 747.233774] [] kthread+0x107/0x10f
[ 747.233778] [] ret_from_fork+0x3f/0x70
[ 747.233783] irq event stamp: 138297
[ 747.233784] hardirqs last enabled at (138297): []
debug_check_no_locks_freed+0x113/0x12f
[ 747.233786] hardirqs last disabled at (138296): []
debug_check_no_locks_freed+0x33/0x12f
[ 747.233788] softirqs last enabled at (137818): []
__do_softirq+0x2d3/0x3e9
[ 747.233792] softirqs last disabled at (137813): []
irq_exit+0x41/0x95
[ 747.233794]
other info that might help us debug this:
[ 747.233796] Possible unsafe locking scenario:
[ 747.233797]CPU0
[ 747.233798]
[ 747.233799] lock(jbd2_handle);
[ 747.233801]
[ 747.233801] lock(jbd2_handle);
[ 747.233803]
*** DEADLOCK ***
[ 747.233805] 5 locks held by git/20158:
[ 747.233806] #0: (sb_writers#7){.+.+.+}, at: []
mnt_want_write+0x24/0x4b
[ 747.233811] #1: (>i_mutex_dir_key#2/1){+.+.+.}, at:
[] lock_rename+0xd9/0xe3
[ 747.233817] #2: (>s_type->i_mutex_key#11){+.+.+.}, at:
[] lock_two_nondirectories+0x3f/0x6b
[ 747.233822] #3: (>s_type->i_mutex_key#11/4){+.+.+.}, at:
[] lock_two_nondirectories+0x66/0x6b
[ 747.233827] #4: (jbd2_handle){+.+.?.}, at: []
start_this_handle+0x4ca/0x555
[ 747.233831]
stack backtrace:
[ 747.233834] CPU: 2 PID: 20158 Comm: git Not tainted
4.1.0-rc7-next-20150615-dbg-00016-g8bdf555-dirty #211
[ 747.233837] 8800a56cea40 88010d0a75f8 814f446d
81077036
[ 747.233840] 823a84b0 88010d0a7638 814f3849
0001
[ 747.233843] 000a 8800a56cf6f8 8800a56cea40
810795dd
[ 747.233846] Call Trace:
[ 747.233849] [] dump_stack+0x4c/0x6e
[ 747.233852] [] ? up+0x39/0x3e
[ 747.233854] [] print_usage_bug.part.23+0x25b/0x26a
[ 747.233857] [] ?
print_shortest_lock_dependencies+0x182/0x182
[ 747.233859] [] mark_lock+0x384/0x56d
[ 747.233862] [] mark_held_locks+0x5f/0x76
[ 747.233865] [] ? zcomp_strm_alloc+0x25/0x73 [zram]
[ 747.233867] [] lockdep_trace_alloc+0xb2/0xb5
[ 747.233870] [] kmem_cache_alloc_trace+0x32/0x1e2
[ 747.233873] [] zcomp_strm_alloc+0x25/0x73 [zram]
[ 747.233876] [] zcomp_strm_multi_find+0xe7/0x173 [zram]
[ 747.233879] [] zcomp_strm_find+0xc/0xe [zram]
[ 747.233881] [] zram_bvec_rw+0x2ca/0x7e0 [zram]
[ 747.233885] [] zram_make_request+0x1fa/0x301 [zram]
[ 747.233889] [] generic_make_request+0x9c/0xdb
[ 747.233891] [] submit_bio+0xf7/0x120
[ 747.233895] [] ? __test_set_page_writeback+0x1a0/0x1b8
[ 747.233897] [] ext4_io_submit+0x2e/0x43
[ 747.233899] [] ext4_bio_write_page+0x1b7/0x300
[ 747.233902] [] mpage_submit_page+0x60/0x77
[ 747.233905] [] mpage_map_and_submit_buffers+0x10f/0x21d
[ 747.233907] [] ext4_writepages+0xc8c/0xe1b
[ 747.233910] [] do_writepages+0x23/0x2c
[ 747.233913] [] __filemap_fdatawrite_range+0x84/0x8b
[ 747.233915] [] filemap_flush+0x1c/0x1e
[ 747.233917] [] ext4_alloc_da_blocks+0xb8/0x117
[ 747.233919] [] ext4_rename+0x132/0x6dc
[ 747.233921] [] ? mark_held_locks+0x5f/0x76
[ 747.233924] [] ext4_rename2+0x29/0x2b
[ 747.233926] [] vfs_rename+0x540/0x636
[ 747.233928] [] SyS_renameat2+0x359/0x44d
[ 747.233931] [] SyS_rename+0x1e/0x20
[ 747.233933] [] entry_SYSCALL_64_fastpath+0x12/0x6f
[minchan: add stable mark]
Cc: sta...@vger.kernel.org
Signed-off-by: Sergey Senozhatsky
---
drivers/block/zram/zcomp.c | 4 ++--
drivers/block/zram/zcomp_lz4.c | 2 +-
drivers/block/zram/zcomp_lzo.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git
[PATCH v3 2/2] zram: try vmalloc() after kmalloc()
From: Kyeongdon Kim
When we're using LZ4 multi compression streams for zram swap,
we found out page allocation failure message in system running test.
That was not only once, but a few(2 - 5 times per test).
Also, some failure cases were continually occurring to try allocation
order 3.
In order to make parallel compression private data, we should call
kzalloc() with order 2/3 in runtime(lzo/lz4). But if there is no order
2/3 size memory to allocate in that time, page allocation fails.
This patch makes to use vmalloc() as fallback of kmalloc(), this
prevents page alloc failure warning.
After using this, we never found warning message in running test, also
It could reduce process startup latency about 60-120ms in each case.
For reference a call trace :
Binder_1: page allocation failure: order:3, mode:0x10c0d0
CPU: 0 PID: 424 Comm: Binder_1 Tainted: GW 3.10.49-perf-g991d02b-dirty #20
Call trace:
[] dump_backtrace+0x0/0x270
[] show_stack+0x10/0x1c
[] dump_stack+0x1c/0x28
[] warn_alloc_failed+0xfc/0x11c
[] __alloc_pages_nodemask+0x724/0x7f0
[] __get_free_pages+0x14/0x5c
[] kmalloc_order_trace+0x38/0xd8
[] zcomp_lz4_create+0x2c/0x38
[] zcomp_strm_alloc+0x34/0x78
[] zcomp_strm_multi_find+0x124/0x1ec
[] zcomp_strm_find+0xc/0x18
[] zram_bvec_rw+0x2fc/0x780
[] zram_make_request+0x25c/0x2d4
[] generic_make_request+0x80/0xbc
[] submit_bio+0xa4/0x15c
[] __swap_writepage+0x218/0x230
[] swap_writepage+0x3c/0x4c
[] shrink_page_list+0x51c/0x8d0
[] shrink_inactive_list+0x3f8/0x60c
[] shrink_lruvec+0x33c/0x4cc
[] shrink_zone+0x3c/0x100
[] try_to_free_pages+0x2b8/0x54c
[] __alloc_pages_nodemask+0x514/0x7f0
[] __get_free_pages+0x14/0x5c
[] proc_info_read+0x50/0xe4
[] vfs_read+0xa0/0x12c
[] SyS_read+0x44/0x74
DMA: 3397*4kB (MC) 26*8kB (RC) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB
0*512kB 0*1024kB 0*2048kB 0*4096kB = 13796kB
[minchan: change vmalloc gfp and adding comment about gfp]
[sergey: tweak comments and styles]
Signed-off-by: Kyeongdon Kim
Signed-off-by: Minchan Kim
Acked-by: Sergey Senozhatsky
---
drivers/block/zram/zcomp_lz4.c | 23 +--
drivers/block/zram/zcomp_lzo.c | 23 +--
2 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/drivers/block/zram/zcomp_lz4.c b/drivers/block/zram/zcomp_lz4.c
index ee44b51..f2bfced 100644
--- a/drivers/block/zram/zcomp_lz4.c
+++ b/drivers/block/zram/zcomp_lz4.c
@@ -10,17 +10,36 @@
#include
#include
#include
+#include
+#include
#include "zcomp_lz4.h"
static void *zcomp_lz4_create(void)
{
- return kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO);
+ void *ret;
+
+ /*
+* This function can be called in swapout/fs write path
+* so we can't use GFP_FS|IO. And it assumes we already
+* have at least one stream in zram initialization so we
+* don't do best effort to allocate more stream in here.
+* A default stream will work well without further multiple
+* streams. That's why we use NORETRY | NOWARN | NOMEMALLOC.
+*/
+ ret = kzalloc(LZ4_MEM_COMPRESS, GFP_NOIO | __GFP_NORETRY |
+ __GFP_NOWARN | __GFP_NOMEMALLOC);
+ if (!ret)
+ ret = __vmalloc(LZ4_MEM_COMPRESS,
+ GFP_NOIO | __GFP_NORETRY | __GFP_NOWARN |
+ __GFP_NOMEMALLOC | __GFP_ZERO | __GFP_HIGHMEM,
+ PAGE_KERNEL);
+ return ret;
}
static void zcomp_lz4_destroy(void *private)
{
- kfree(private);
+ kvfree(private);
}
static int zcomp_lz4_compress(const unsigned char *src, unsigned char *dst,
diff --git a/drivers/block/zram/zcomp_lzo.c b/drivers/block/zram/zcomp_lzo.c
index 683ce04..7fbb4a3 100644
--- a/drivers/block/zram/zcomp_lzo.c
+++ b/drivers/block/zram/zcomp_lzo.c
@@ -10,17 +10,36 @@
#include
#include
#include
+#include
+#include
#include "zcomp_lzo.h"
static void *lzo_create(void)
{
- return kzalloc(LZO1X_MEM_COMPRESS, GFP_NOIO);
+ void *ret;
+
+ /*
+* This function can be called in swapout/fs write path
+* so we can't use GFP_FS|IO. And it assumes we already
+* have at least one stream in zram initialization so we
+* don't do best effort to allocate more stream in here.
+* A default stream will work well without further multiple
+* streams. That's why we use NORETRY | NOWARN | NOMEMALLOC.
+*/
+ ret = kzalloc(LZO1X_MEM_COMPRESS, GFP_NOIO | __GFP_NORETRY |
+ __GFP_NOWARN | __GFP_NOMEMALLOC);
+ if (!ret)
+ ret = __vmalloc(LZO1X_MEM_COMPRESS,
+ GFP_NOIO | __GFP_NORETRY | __GFP_NOWARN |
+ __GFP_NOMEMALLOC | __GFP_ZERO | __GFP_HIGHMEM,
+ PAGE_KERNEL);
+ return ret;
}
static void lzo_destroy(void *private)
{
- kfree(private);
+ kvfree(private);
}
static int
[PATCH v2 3/3] nvme: change the interface between nvme and lightnvm
When nvme devices were removed, we need to handle the targets
build upon them properly: remove the existing targets, block
creations of new ones. To do this clean up job well, we
need to change the interface between nvme and lightnvm.
Signed-off-by: Wenwei Tao
---
drivers/nvme/host/lightnvm.c | 17 -
drivers/nvme/host/nvme.h | 1 +
drivers/nvme/host/pci.c | 7 +++
3 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index 9202d1a..742875e 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -542,6 +542,14 @@ static void nvme_nvm_dev_dma_free(void *pool, void
*ppa_list,
dma_pool_free(pool, ppa_list, dma_handler);
}
+static void nvme_nvm_dev_remove(struct request_queue *q)
+{
+ struct nvme_ns *ns = q->queuedata;
+
+ kref_put(>kref, nvme_free_ns);
+
+}
+
static struct nvm_dev_ops nvme_nvm_dev_ops = {
.identity = nvme_nvm_identity,
@@ -557,13 +565,20 @@ static struct nvm_dev_ops nvme_nvm_dev_ops = {
.destroy_dma_pool = nvme_nvm_destroy_dma_pool,
.dev_dma_alloc = nvme_nvm_dev_dma_alloc,
.dev_dma_free = nvme_nvm_dev_dma_free,
+ .dev_remove = nvme_nvm_dev_remove,
.max_phys_sect = 64,
};
int nvme_nvm_register(struct request_queue *q, char *disk_name)
{
- return nvm_register(q, disk_name, _nvm_dev_ops);
+ int ret;
+ struct nvme_ns *ns = q->queuedata;
+
+ ret = nvm_register(q, disk_name, _nvm_dev_ops);
+ if (!ret)
+ kref_get(>kref);
+ return ret;
}
void nvme_nvm_unregister(struct request_queue *q, char *disk_name)
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index fdb4e5b..251ec9d 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -116,6 +116,7 @@ static inline u64 nvme_block_nr(struct nvme_ns *ns,
sector_t sector)
return (sector >> (ns->lba_shift - 9));
}
+void nvme_free_ns(struct kref *kref);
int nvme_submit_sync_cmd(struct request_queue *q, struct nvme_command *cmd,
void *buf, unsigned bufflen);
int __nvme_submit_sync_cmd(struct request_queue *q, struct nvme_command *cmd,
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index f3b53af..5f0f934 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1967,13 +1967,10 @@ static int nvme_compat_ioctl(struct block_device *bdev,
fmode_t mode,
#endif
static void nvme_free_dev(struct kref *kref);
-static void nvme_free_ns(struct kref *kref)
+void nvme_free_ns(struct kref *kref)
{
struct nvme_ns *ns = container_of(kref, struct nvme_ns, kref);
- if (ns->type == NVME_NS_LIGHTNVM)
- nvme_nvm_unregister(ns->queue, ns->disk->disk_name);
-
spin_lock(_list_lock);
ns->disk->private_data = NULL;
spin_unlock(_list_lock);
@@ -2540,6 +2537,8 @@ static void nvme_ns_remove(struct nvme_ns *ns)
{
bool kill = nvme_io_incapable(ns->dev) && !blk_queue_dying(ns->queue);
+ if (ns->type == NVME_NS_LIGHTNVM)
+ nvme_nvm_unregister(ns->queue, ns->disk->disk_name);
if (kill)
blk_set_queue_dying(ns->queue);
if (ns->disk->flags & GENHD_FL_UP)
--
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] sched: change nr_uninterruptible to be signed
nr_uninterruptible will be negative during running,
this happened when dequeue a TASK_UNINTERRUPTIBLE task
from rq1 and then wake up the task and queue it to rq2,
then rq2->nr_uninterruptible-- will reuslt in negative value
sometimes.
Signed-off-by: yalin wang
---
kernel/sched/loadavg.c | 2 +-
kernel/sched/sched.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/loadavg.c b/kernel/sched/loadavg.c
index ef71590..39504c6 100644
--- a/kernel/sched/loadavg.c
+++ b/kernel/sched/loadavg.c
@@ -83,7 +83,7 @@ long calc_load_fold_active(struct rq *this_rq)
long nr_active, delta = 0;
nr_active = this_rq->nr_running;
- nr_active += (long)this_rq->nr_uninterruptible;
+ nr_active += this_rq->nr_uninterruptible;
if (nr_active != this_rq->calc_load_active) {
delta = nr_active - this_rq->calc_load_active;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 84d4879..7b5f67b 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -605,7 +605,7 @@ struct rq {
* one CPU and if it got migrated afterwards it may decrease
* it on another CPU. Always updated under the runqueue lock:
*/
- unsigned long nr_uninterruptible;
+ long nr_uninterruptible;
struct task_struct *curr, *idle, *stop;
unsigned long next_balance;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the modules tree
Stephen Rothwell writes: > Hi Rusty, > > After merging the modules tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > In file included from include/linux/kexec.h:26:0, > from include/linux/crash_dump.h:5, > from arch/powerpc/platforms/powernv/pci-ioda.c:16: > include/linux/module.h:770:15: error: return type defaults to 'int' > [-Werror=return-type] Thanks, this typo hit all archs which don't do RO module protection by default. Maybe PPC should do that? I've fixed it (and some others found by 0-day) and rebased. Thanks, 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/
[PATCH] tty/n_gsm.c: use gsm->num to remove mux itself from gsm_mux[]
There is one filed gsm->num to store mux's index of gsm_mux[]. So use
gsm->num to remove itself from gsm_mux[] instead of the for-loop
traverse in gsm_cleanup_mux().
Signed-off-by: Pan Xinhui
---
drivers/tty/n_gsm.c | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 9aff371..cf28054 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2037,18 +2037,14 @@ static void gsm_cleanup_mux(struct gsm_mux *gsm)
gsm->dead = 1;
- spin_lock(_mux_lock);
- for (i = 0; i < MAX_MUX; i++) {
- if (gsm_mux[i] == gsm) {
- gsm_mux[i] = NULL;
- break;
- }
- }
- spin_unlock(_mux_lock);
/* open failed before registering => nothing to do */
- if (i == MAX_MUX)
+ if (gsm_mux[gsm->num] != gsm)
return;
+ spin_lock(_mux_lock);
+ gsm_mux[gsm->num] = NULL;
+ spin_unlock(_mux_lock);
+
/* In theory disconnecting DLCI 0 is sufficient but for some
modems this is apparently not the case. */
if (dlci) {
--
1.7.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 v2 6/9] mm, debug: introduce dump_gfpflag_names() for symbolic printing of gfp_flags
> On Nov 25, 2015, at 18:28, Vlastimil Babka wrote:
>
> On 11/25/2015 09:16 AM, Joonsoo Kim wrote:
>> On Tue, Nov 24, 2015 at 01:36:18PM +0100, Vlastimil Babka wrote:
>>> --- a/include/trace/events/gfpflags.h
>>> +++ b/include/trace/events/gfpflags.h
>>> @@ -8,8 +8,8 @@
>>> *
>>> * Thus most bits set go first.
>>> */
>>> -#define show_gfp_flags(flags)
>>> \
>>> - (flags) ? __print_flags(flags, "|", \
>>> +
>>> +#define __def_gfpflag_names
>>> \
>>> {(unsigned long)GFP_TRANSHUGE, "GFP_TRANSHUGE"}, \
>>> {(unsigned long)GFP_HIGHUSER_MOVABLE, "GFP_HIGHUSER_MOVABLE"}, \
>>> {(unsigned long)GFP_HIGHUSER, "GFP_HIGHUSER"},\
>>> @@ -19,9 +19,13 @@
>>> {(unsigned long)GFP_NOFS, "GFP_NOFS"},\
>>> {(unsigned long)GFP_ATOMIC, "GFP_ATOMIC"}, \
>>> {(unsigned long)GFP_NOIO, "GFP_NOIO"},\
>>> + {(unsigned long)GFP_NOWAIT, "GFP_NOWAIT"}, \
>>> + {(unsigned long)__GFP_DMA, "GFP_DMA"}, \
>>> + {(unsigned long)__GFP_DMA32,"GFP_DMA32"}, \
>>> {(unsigned long)__GFP_HIGH, "GFP_HIGH"},\
>>> {(unsigned long)__GFP_ATOMIC, "GFP_ATOMIC"}, \
>>> {(unsigned long)__GFP_IO, "GFP_IO"}, \
>>> + {(unsigned long)__GFP_FS, "GFP_FS"}, \
>>> {(unsigned long)__GFP_COLD, "GFP_COLD"},\
>>> {(unsigned long)__GFP_NOWARN, "GFP_NOWARN"}, \
>>> {(unsigned long)__GFP_REPEAT, "GFP_REPEAT"}, \
>>> @@ -36,8 +40,12 @@
>>> {(unsigned long)__GFP_RECLAIMABLE, "GFP_RECLAIMABLE"}, \
>>> {(unsigned long)__GFP_MOVABLE, "GFP_MOVABLE"}, \
>>> {(unsigned long)__GFP_NOTRACK, "GFP_NOTRACK"}, \
>>> + {(unsigned long)__GFP_WRITE,"GFP_WRITE"}, \
>>> {(unsigned long)__GFP_DIRECT_RECLAIM, "GFP_DIRECT_RECLAIM"}, \
>>> {(unsigned long)__GFP_KSWAPD_RECLAIM, "GFP_KSWAPD_RECLAIM"}, \
>>> {(unsigned long)__GFP_OTHER_NODE, "GFP_OTHER_NODE"} \
>>> - ) : "GFP_NOWAIT"
>>>
>>> +#define show_gfp_flags(flags)
>>> \
>>> + (flags) ? __print_flags(flags, "|", \
>>> + __def_gfpflag_names \
>>> + ) : "none"
>>
>> How about moving this to gfp.h or something?
>> Now, we use it in out of tracepoints so there is no need to keep it
>> in include/trace/events/xxx.
>
> Hm I didn't want to pollute such widely included header with such defines. And
> show_gfp_flags shouldn't be there definitely as it depends on __print_flags.
> What do others think?
how about add this into standard printk() format ?
like cpu mask print in printk use %*pb[l] ,
it define a macro cpumask_pr_args to print cpumask .
we can also define a new format like %pG means print flag ,
then it will be useful for other code to use , like dump vma / mm flags ..
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] zram: pass gfp from zcomp frontend to backend
On (11/27/15 11:22), Minchan Kim wrote: [..] >> I have a patchset with my nitpicks addressed and fix-ups for missing >> gfps. >> Do you mind me to send it out? >Hey Sergey >I am on vacation and outside now. so if you resend with things you pointed Oh, lovely, have a good one! >out I am very happy. >Pz ask Kyeongdon to test new patch set again because we changed his patch >a bit and suppose to mark as stable. ok, will do. thanks. -ss -- 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] [v4] x86, suspend: Save/restore extra MSR registers for suspend
On 2015.11.21 08:45 Doug Smythies wrote: >On 2015.11.12 01:42 Chen, Yu C wrote: >> On 2015.11.06 11:34 Doug Smythies wrote: [cut] >> rdmsr_safe might be better, > I'll look into it, thanks. >> you can refer to acpi_throttling_rdmsr > I don't understand. >> and I'm OK with this code, are you planning to send a formal patch? > The delay here is because I have always thought that some actual load > content needs to be brought back to the intel_pstate driver, which would > (or at least should) eliminate the need for this patch. > Anyway, and at least for the interim, I'll try to make and submit a formal > version. I made a mistake in my initial testing. I put a 100% load on CPU 7 and then cycled through all the clock modulation values to show that my test version of a possible patch compensated / normalized the Clock Modulation. Indeed, if the system is already asking for the maximum pstate, it will stay there. However, whenever the load drops, the target pstate will drop to minimum and it will never kick back up again, regardless of load. I am returning to my initial assertion copied below: >>> The current version of the intel_pstate driver is incompatible >>> with any use of Clock Modulation, always resulting in driving the >>> target pstate to the minimum, regardless of load. The result is >>> the apparent CPU frequency stuck at minimum * modulation percent. >> >>> The acpi-cpufreq driver works fine with Clock Modulation, >>> resulting in desired frequency * modulation percent. Chen, Thanks though for the suggestion to try normalizing. ... Doug -- 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]Revert "SCSI: Fix NULL pointer dereference in runtime PM"
On 四, 2015-09-10 at 10:23 +0800, Ken Xue wrote:
Can someone help to apply this patch series? Thanks.
http://marc.info/?l=linux-scsi=144185206825609=2
http://marc.info/?l=linux-scsi=144185208525611=2
> Revert "SCSI: Fix NULL pointer dereference in runtime PM"
>
> This reverts commit 49718f0fb8c9 ("SCSI: Fix NULL pointer dereference
> in
> runtime PM")
>
> The old commit may lead to a issue that
> blk_{pre|post}_runtime_suspend and
> blk_{pre|post}_runtime_resume can not be called in pairs.
>
> Take sr device as example, when sr device goes to runtime suspend,
> blk_{pre|post}_runtime_suspend will be called since sr device defined
> pm->runtime_suspend. But blk_{pre|post}_runtime_resume will not be
> called
> since sr device doesn't have pm->runtime_resume. Then sr device can
> not
> resume correctly anymore.
>
> Signed-off-by: Ken Xue
> Acked-by: Alan Stern
> Cc: sta...@vger.kernel.org
>
> ---
> drivers/scsi/scsi_pm.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
> index e4b7998..459abe1 100644
> --- a/drivers/scsi/scsi_pm.c
> +++ b/drivers/scsi/scsi_pm.c
> @@ -219,13 +219,13 @@ static int sdev_runtime_suspend(struct device
> *dev)
> struct scsi_device *sdev = to_scsi_device(dev);
> int err = 0;
>
> - if (pm && pm->runtime_suspend) {
> - err = blk_pre_runtime_suspend(sdev->request_queue);
> - if (err)
> - return err;
> + err = blk_pre_runtime_suspend(sdev->request_queue);
> + if (err)
> + return err;
> + if (pm && pm->runtime_suspend)
> err = pm->runtime_suspend(dev);
> - blk_post_runtime_suspend(sdev->request_queue, err);
> - }
> + blk_post_runtime_suspend(sdev->request_queue, err);
> +
> return err;
> }
>
> @@ -248,11 +248,11 @@ static int sdev_runtime_resume(struct device
> *dev)
> const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm
> : NULL;
> int err = 0;
>
> - if (pm && pm->runtime_resume) {
> - blk_pre_runtime_resume(sdev->request_queue);
> + blk_pre_runtime_resume(sdev->request_queue);
> + if (pm && pm->runtime_resume)
> err = pm->runtime_resume(dev);
> - blk_post_runtime_resume(sdev->request_queue, err);
> - }
> + blk_post_runtime_resume(sdev->request_queue, err);
> +
> return err;
> }
>
> N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
> 0��h���i
Re: [PATCH v2] arm64: dts: uniphier: add PH1-LD10 SoC/board support
I found a bug in the DTSI.
I will send v3.
2015-11-26 11:33 GMT+09:00 Masahiro Yamada :
> This is the first ARMv8 SoC from Socionext Inc.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v2:
> - Split into a single patch
>
> MAINTAINERS| 1 +
> arch/arm64/boot/dts/Makefile | 1 +
> arch/arm64/boot/dts/socionext/Makefile | 4 +
> .../boot/dts/socionext/uniphier-ph1-ld10-ref.dts | 95 +++
> .../boot/dts/socionext/uniphier-ph1-ld10.dtsi | 280
> +
> .../arm64/boot/dts/socionext/uniphier-pinctrl.dtsi | 1 +
> .../boot/dts/socionext/uniphier-support-card.dtsi | 1 +
> 7 files changed, 383 insertions(+)
> create mode 100644 arch/arm64/boot/dts/socionext/Makefile
> create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
> create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
> create mode 12 arch/arm64/boot/dts/socionext/uniphier-pinctrl.dtsi
> create mode 12 arch/arm64/boot/dts/socionext/uniphier-support-card.dtsi
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3f92804..99a1424 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1642,6 +1642,7 @@ F:arch/arm/boot/dts/uniphier*
> F: arch/arm/include/asm/hardware/cache-uniphier.h
> F: arch/arm/mach-uniphier/
> F: arch/arm/mm/cache-uniphier.c
> +F: arch/arm64/boot/dts/socionext/
> F: drivers/i2c/busses/i2c-uniphier*
> F: drivers/pinctrl/uniphier/
> F: drivers/tty/serial/8250/8250_uniphier.c
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index eb3c42d..6672a96 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -11,6 +11,7 @@ dts-dirs += marvell
> dts-dirs += mediatek
> dts-dirs += qcom
> dts-dirs += rockchip
> +dts-dirs += socionext
> dts-dirs += sprd
> dts-dirs += xilinx
>
> diff --git a/arch/arm64/boot/dts/socionext/Makefile
> b/arch/arm64/boot/dts/socionext/Makefile
> new file mode 100644
> index 000..8d72771
> --- /dev/null
> +++ b/arch/arm64/boot/dts/socionext/Makefile
> @@ -0,0 +1,4 @@
> +dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld10-ref.dtb
> +
> +always := $(dtb-y)
> +clean-files:= *.dtb
> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
> b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
> new file mode 100644
> index 000..3e53317
> --- /dev/null
> +++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
> @@ -0,0 +1,95 @@
> +/*
> + * Device Tree Source for UniPhier PH1-LD10 Reference Board
> + *
> + * Copyright (C) 2015 Masahiro Yamada
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +/include/ "uniphier-ph1-ld10.dtsi"
> +/include/ "uniphier-support-card.dtsi"
> +
> +/ {
> + model = "UniPhier PH1-LD10 Reference Board";
> + compatible = "socionext,ph1-ld10-ref", "socionext,ph1-ld10";
> +
> + memory {
> +
[PATCH] x86/PCI: Fix regression caused by commit 4d6b4e69a245
From: Liu Jiang
Commit 4d6b4e69a245 ("x86/PCI/ACPI: Use common interface to support
PCI host bridge") converted x86 to use the common interface
acpi_pci_root_create, but the conversion missed on code piece in
arch/x86/pci/bus_numa.c, which causes regression on some legacy
AMD platforms as reported by Arthur Marsh .
The root causes is that acpi_pci_root_create() fails to insert
host bridge resources into iomem_resource/ioport_resource because
x86_pci_root_bus_resources() has already inserted those resources.
So change x86_pci_root_bus_resources() to not insert resources into
iomem_resource/ioport_resource.
Fixes: 4d6b4e69a245 ("x86/PCI/ACPI: Use common interface to support PCI host
bridge")
Signed-off-by: Jiang Liu
Reported-and-tested-by: Arthur Marsh
Cc: Keith Busch
Cc: Arthur Marsh
Cc: Hans de Bruin
---
arch/x86/pci/bus_numa.c | 13 ++---
drivers/acpi/pci_root.c |7 +++
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/x86/pci/bus_numa.c b/arch/x86/pci/bus_numa.c
index 7bcf06a7cd12..6eb3c8af96e2 100644
--- a/arch/x86/pci/bus_numa.c
+++ b/arch/x86/pci/bus_numa.c
@@ -50,18 +50,9 @@ void x86_pci_root_bus_resources(int bus, struct list_head
*resources)
if (!found)
pci_add_resource(resources, >busn);
- list_for_each_entry(root_res, >resources, list) {
- struct resource *res;
- struct resource *root;
+ list_for_each_entry(root_res, >resources, list)
+ pci_add_resource(resources, _res->res);
- res = _res->res;
- pci_add_resource(resources, res);
- if (res->flags & IORESOURCE_IO)
- root = _resource;
- else
- root = _resource;
- insert_resource(root, res);
- }
return;
default_resources:
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 850d7bf0c873..ae3fe4e64203 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -768,6 +768,13 @@ static void pci_acpi_root_add_resources(struct
acpi_pci_root_info *info)
else
continue;
+ /*
+* Some legacy x86 host bridge drivers use iomem_resource and
+* ioport_resource as default resource pool, skip it.
+*/
+ if (res == root)
+ continue;
+
conflict = insert_resource_conflict(root, res);
if (conflict) {
dev_info(>bridge->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 2/3] arcmsr: Split dma resource allocation to a new function
On Thu, 2015-11-26 at 11:46 -0800, Joe Perches wrote:
> On Thu, 2015-11-26 at 19:41 +0800, Ching Huang wrote:
> > split dma resource allocation and io register assignment from get_config to
> > a new function arcmsr_alloc_io_queue.
>
> trivia:
>
> > diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c
> > b/drivers/scsi/arcmsr/arcmsr_hba.c
> []
> > +static bool arcmsr_alloc_io_queue(struct AdapterControlBlock *acb)
> > +{
> []
> > + dma_coherent = dma_alloc_coherent(>dev,
> > acb->roundup_ccbsize,
> > + _coherent_handle, GFP_KERNEL);
> > + if (!dma_coherent){
> > + pr_notice("arcmsr%d: DMA allocation failed.\n",
> > acb->host->host_no);
> > + return false;
> > + }
> > + memset(dma_coherent, 0, acb->roundup_ccbsize);
> >
>
> There is a dma_zalloc_coherent
>
> (and even more trivially)
>
> Most all of your error messages don't use periods.
Thanks Joe.
Revised as below.
Signed-of-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2015-11-26 15:52:54.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2015-11-27 10:30:09.299131000 +0800
@@ -498,6 +498,90 @@ static void arcmsr_flush_adapter_cache(s
}
}
+static bool arcmsr_alloc_io_queue(struct AdapterControlBlock *acb)
+{
+ bool rtn = true;
+ void *dma_coherent;
+ dma_addr_t dma_coherent_handle;
+ struct pci_dev *pdev = acb->pdev;
+
+ switch (acb->adapter_type) {
+ case ACB_ADAPTER_TYPE_B: {
+ struct MessageUnit_B *reg;
+ acb->roundup_ccbsize = roundup(sizeof(struct MessageUnit_B),
32);
+ dma_coherent = dma_zalloc_coherent(>dev,
acb->roundup_ccbsize,
+ _coherent_handle, GFP_KERNEL);
+ if (!dma_coherent){
+ pr_notice("arcmsr%d: DMA allocation failed\n",
acb->host->host_no);
+ return false;
+ }
+ acb->dma_coherent_handle2 = dma_coherent_handle;
+ acb->dma_coherent2 = dma_coherent;
+ reg = (struct MessageUnit_B *)dma_coherent;
+ acb->pmuB = reg;
+ if (acb->pdev->device == PCI_DEVICE_ID_ARECA_1203) {
+ reg->drv2iop_doorbell =
MEM_BASE0(ARCMSR_DRV2IOP_DOORBELL_1203);
+ reg->drv2iop_doorbell_mask =
MEM_BASE0(ARCMSR_DRV2IOP_DOORBELL_MASK_1203);
+ reg->iop2drv_doorbell =
MEM_BASE0(ARCMSR_IOP2DRV_DOORBELL_1203);
+ reg->iop2drv_doorbell_mask =
MEM_BASE0(ARCMSR_IOP2DRV_DOORBELL_MASK_1203);
+ } else {
+ reg->drv2iop_doorbell=
MEM_BASE0(ARCMSR_DRV2IOP_DOORBELL);
+ reg->drv2iop_doorbell_mask =
MEM_BASE0(ARCMSR_DRV2IOP_DOORBELL_MASK);
+ reg->iop2drv_doorbell =
MEM_BASE0(ARCMSR_IOP2DRV_DOORBELL);
+ reg->iop2drv_doorbell_mask =
MEM_BASE0(ARCMSR_IOP2DRV_DOORBELL_MASK);
+ }
+ reg->message_wbuffer = MEM_BASE1(ARCMSR_MESSAGE_WBUFFER);
+ reg->message_rbuffer = MEM_BASE1(ARCMSR_MESSAGE_RBUFFER);
+ reg->message_rwbuffer = MEM_BASE1(ARCMSR_MESSAGE_RWBUFFER);
+ }
+ break;
+ case ACB_ADAPTER_TYPE_D: {
+ struct MessageUnit_D *reg;
+ acb->roundup_ccbsize = roundup(sizeof(struct MessageUnit_D),
32);
+ dma_coherent = dma_zalloc_coherent(>dev,
acb->roundup_ccbsize,
+ _coherent_handle, GFP_KERNEL);
+ if (!dma_coherent) {
+ pr_notice("arcmsr%d: DMA allocation failed\n",
acb->host->host_no);
+ return false;
+ }
+ acb->dma_coherent_handle2 = dma_coherent_handle;
+ acb->dma_coherent2 = dma_coherent;
+ reg = (struct MessageUnit_D *)dma_coherent;
+ acb->pmuD = reg;
+ reg->chip_id = MEM_BASE0(ARCMSR_ARC1214_CHIP_ID);
+ reg->cpu_mem_config =
MEM_BASE0(ARCMSR_ARC1214_CPU_MEMORY_CONFIGURATION);
+ reg->i2o_host_interrupt_mask =
MEM_BASE0(ARCMSR_ARC1214_I2_HOST_INTERRUPT_MASK);
+ reg->sample_at_reset = MEM_BASE0(ARCMSR_ARC1214_SAMPLE_RESET);
+ reg->reset_request = MEM_BASE0(ARCMSR_ARC1214_RESET_REQUEST);
+ reg->host_int_status =
MEM_BASE0(ARCMSR_ARC1214_MAIN_INTERRUPT_STATUS);
+ reg->pcief0_int_enable =
MEM_BASE0(ARCMSR_ARC1214_PCIE_F0_INTERRUPT_ENABLE);
+ reg->inbound_msgaddr0 =
MEM_BASE0(ARCMSR_ARC1214_INBOUND_MESSAGE0);
+ reg->inbound_msgaddr1 =
MEM_BASE0(ARCMSR_ARC1214_INBOUND_MESSAGE1);
+ reg->outbound_msgaddr0 =
MEM_BASE0(ARCMSR_ARC1214_OUTBOUND_MESSAGE0);
+ reg->outbound_msgaddr1 =
[PATCH v1 2/5] thermal: rockchip: fix a impossible condition caused by the warning
As the Dan report the smatch check the thermal driver warning:
drivers/thermal/rockchip_thermal.c:551 rockchip_configure_from_dt()
warn: impossible condition '(thermal->tshut_temp > ((~0 >> 1))) =>
(s32min-s32max > s32max)'
Since the Temperature is currently represented as int not long in
the thermal driver.
Fixes: commit 437df2172e8d
("thermal: rockchip: consistently use int for temperatures")
Reported-by: Dan Carpenter
Signed-off-by: Caesar Wang
---
Changes in v1: None
drivers/thermal/rockchip_thermal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/rockchip_thermal.c
b/drivers/thermal/rockchip_thermal.c
index 5a8840b..d00765f 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -548,7 +548,7 @@ static int rockchip_configure_from_dt(struct device *dev,
thermal->tshut_temp = shut_temp;
}
- if (thermal->tshut_temp > INT_MAX) {
+ if (!(thermal->tshut_temp < INT_MAX)) {
dev_err(dev, "Invalid tshut temperature specified: %d\n",
thermal->tshut_temp);
return -ERANGE;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 5/5] thermal: rockchip: Support the RK3399 SoCs in thermal driver
The RK3399 SoCs have two Temperature Sensors, channel 0 is for CPU.
channel 1 is for GPU.
Signed-off-by: Caesar Wang
---
Changes in v1:
- fix a irq ack is similar with RK3228 SoCs.
drivers/thermal/rockchip_thermal.c | 66 ++
1 file changed, 66 insertions(+)
diff --git a/drivers/thermal/rockchip_thermal.c
b/drivers/thermal/rockchip_thermal.c
index 37772dd..8e02b86 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -291,6 +291,44 @@ static const struct tsadc_table v3_code_table[] = {
{TSADCV3_DATA_MASK, 125000},
};
+static const struct tsadc_table v4_code_table[] = {
+ {TSADCV3_DATA_MASK, -4},
+ {431, -4},
+ {426, -35000},
+ {421, -3},
+ {415, -25000},
+ {410, -2},
+ {405, -15000},
+ {399, -1},
+ {394, -5000},
+ {389, 0},
+ {383, 5000},
+ {378, 1},
+ {373, 15000},
+ {367, 2},
+ {362, 25000},
+ {357, 3},
+ {351, 35000},
+ {346, 4},
+ {340, 45000},
+ {335, 5},
+ {330, 55000},
+ {324, 6},
+ {319, 65000},
+ {313, 7},
+ {308, 75000},
+ {302, 8},
+ {297, 85000},
+ {291, 9},
+ {286, 95000},
+ {281, 10},
+ {275, 105000},
+ {270, 11},
+ {264, 115000},
+ {259, 12},
+ {253, 125000},
+};
+
static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table,
int temp)
{
@@ -554,6 +592,30 @@ static const struct rockchip_tsadc_chip rk3368_tsadc_data
= {
},
};
+static const struct rockchip_tsadc_chip rk3399_tsadc_data = {
+ .chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
+ .chn_id[SENSOR_GPU] = 1, /* gpu sensor is channel 1 */
+ .chn_num = 2, /* two channels for tsadc */
+
+ .tshut_mode = TSHUT_MODE_GPIO, /* default TSHUT via GPIO give PMIC */
+ .tshut_polarity = TSHUT_LOW_ACTIVE, /* default TSHUT LOW ACTIVE */
+ .tshut_temp = 95000,
+
+ .initialize = rk_tsadcv2_initialize,
+ .irq_ack = rk_tsadcv1_irq_ack,
+ .control = rk_tsadcv2_control,
+ .get_temp = rk_tsadcv2_get_temp,
+ .set_tshut_temp = rk_tsadcv2_tshut_temp,
+ .set_tshut_mode = rk_tsadcv2_tshut_mode,
+
+ .table = {
+ .id = v4_code_table,
+ .length = ARRAY_SIZE(v4_code_table),
+ .data_mask = TSADCV3_DATA_MASK,
+ .mode = ADC_DECREMENT,
+ },
+};
+
static const struct of_device_id of_rockchip_thermal_match[] = {
{
.compatible = "rockchip,rk3228-tsadc",
@@ -567,6 +629,10 @@ static const struct of_device_id
of_rockchip_thermal_match[] = {
.compatible = "rockchip,rk3368-tsadc",
.data = (void *)_tsadc_data,
},
+ {
+ .compatible = "rockchip,rk3399-tsadc",
+ .data = (void *)_tsadc_data,
+ },
{ /* end */ },
};
MODULE_DEVICE_TABLE(of, of_rockchip_thermal_match);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 4/5] thermal: rockchip: Support the RK3228 SoCs in thermal driver
The RK3228 SoCs has one Temperature Sensor, channel 0 is for CPU.
Signed-off-by: Caesar Wang
---
Changes in v1: None
drivers/thermal/rockchip_thermal.c | 81 ++
1 file changed, 81 insertions(+)
diff --git a/drivers/thermal/rockchip_thermal.c
b/drivers/thermal/rockchip_thermal.c
index d00765f..37772dd 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -153,6 +153,7 @@ struct rockchip_thermal_data {
#define TSADCV2_SHUT_2GPIO_SRC_EN(chn) BIT(4 + (chn))
#define TSADCV2_SHUT_2CRU_SRC_EN(chn) BIT(8 + (chn))
+#define TSADCV1_INT_PD_CLEAR_MASK ~BIT(16)
#define TSADCV2_INT_PD_CLEAR_MASK ~BIT(8)
#define TSADCV2_DATA_MASK 0xfff
@@ -168,6 +169,51 @@ struct tsadc_table {
int temp;
};
+/**
+ * Note:
+ * Code to Temperature mapping of the Temperature sensor is a piece wise linear
+ * curve.Any temperature, code faling between to 2 give temperatures can be
+ * linearly interpolated.
+ * Code to Temperature mapping should be updated based on sillcon results.
+ */
+static const struct tsadc_table v1_code_table[] = {
+ {TSADCV3_DATA_MASK, -4},
+ {436, -4},
+ {431, -35000},
+ {426, -3},
+ {421, -25000},
+ {416, -2},
+ {411, -15000},
+ {406, -1},
+ {401, -5000},
+ {395, 0},
+ {390, 5000},
+ {385, 1},
+ {380, 15000},
+ {375, 2},
+ {370, 25000},
+ {364, 3},
+ {359, 35000},
+ {354, 4},
+ {349, 45000},
+ {343, 5},
+ {338, 55000},
+ {333, 6},
+ {328, 65000},
+ {322, 7},
+ {317, 75000},
+ {312, 8},
+ {307, 85000},
+ {301, 9},
+ {296, 95000},
+ {291, 10},
+ {286, 105000},
+ {280, 11},
+ {275, 115000},
+ {270, 12},
+ {264, 125000},
+};
+
static const struct tsadc_table v2_code_table[] = {
{TSADCV2_DATA_MASK, -4},
{3800, -4},
@@ -368,6 +414,14 @@ static void rk_tsadcv2_initialize(void __iomem *regs,
regs + TSADCV2_HIGHT_TSHUT_DEBOUNCE);
}
+static void rk_tsadcv1_irq_ack(void __iomem *regs)
+{
+ u32 val;
+
+ val = readl_relaxed(regs + TSADCV2_INT_PD);
+ writel_relaxed(val & TSADCV1_INT_PD_CLEAR_MASK, regs + TSADCV2_INT_PD);
+}
+
static void rk_tsadcv2_irq_ack(void __iomem *regs)
{
u32 val;
@@ -429,6 +483,29 @@ static void rk_tsadcv2_tshut_mode(int chn, void __iomem
*regs,
writel_relaxed(val, regs + TSADCV2_INT_EN);
}
+static const struct rockchip_tsadc_chip rk3228_tsadc_data = {
+ .chn_id[SENSOR_CPU] = 0, /* cpu sensor is channel 0 */
+ .chn_num = 1, /* one channel for tsadc */
+
+ .tshut_mode = TSHUT_MODE_GPIO, /* default TSHUT via GPIO give PMIC */
+ .tshut_polarity = TSHUT_LOW_ACTIVE, /* default TSHUT LOW ACTIVE */
+ .tshut_temp = 95000,
+
+ .initialize = rk_tsadcv2_initialize,
+ .irq_ack = rk_tsadcv1_irq_ack,
+ .control = rk_tsadcv2_control,
+ .get_temp = rk_tsadcv2_get_temp,
+ .set_tshut_temp = rk_tsadcv2_tshut_temp,
+ .set_tshut_mode = rk_tsadcv2_tshut_mode,
+
+ .table = {
+ .id = v1_code_table,
+ .length = ARRAY_SIZE(v1_code_table),
+ .data_mask = TSADCV3_DATA_MASK,
+ .mode = ADC_DECREMENT,
+ },
+};
+
static const struct rockchip_tsadc_chip rk3288_tsadc_data = {
.chn_id[SENSOR_CPU] = 1, /* cpu sensor is channel 1 */
.chn_id[SENSOR_GPU] = 2, /* gpu sensor is channel 2 */
@@ -479,6 +556,10 @@ static const struct rockchip_tsadc_chip rk3368_tsadc_data
= {
static const struct of_device_id of_rockchip_thermal_match[] = {
{
+ .compatible = "rockchip,rk3228-tsadc",
+ .data = (void *)_tsadc_data,
+ },
+ {
.compatible = "rockchip,rk3288-tsadc",
.data = (void *)_tsadc_data,
},
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 1/5] thermal: rockchip: fix a trivial typo
This patchset trys to dictate unified format for driver.
Signed-off-by: Caesar Wang
---
Changes in v1:
- Search more trivial typo for me.
drivers/thermal/rockchip_thermal.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/thermal/rockchip_thermal.c
b/drivers/thermal/rockchip_thermal.c
index e845841..5a8840b 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -38,7 +38,7 @@ enum tshut_mode {
};
/**
- * the system Temperature Sensors tshut(tshut) polarity
+ * The system Temperature Sensors tshut(tshut) polarity
* the bit 8 is tshut polarity.
* 0: low active, 1: high active
*/
@@ -57,10 +57,10 @@ enum sensor_id {
};
/**
-* The conversion table has the adc value and temperature.
-* ADC_DECREMENT is the adc value decremnet.(e.g. v2_code_table)
-* ADC_INCREMNET is the adc value incremnet.(e.g. v3_code_table)
-*/
+ * The conversion table has the adc value and temperature.
+ * ADC_DECREMENT: the adc value is of diminishing.(e.g. v2_code_table)
+ * ADC_INCREMENT: the adc value is incremental.(e.g. v3_code_table)
+ */
enum adc_sort_mode {
ADC_DECREMENT = 0,
ADC_INCREMENT,
@@ -75,13 +75,13 @@ enum adc_sort_mode {
struct chip_tsadc_table {
const struct tsadc_table *id;
- /* the array table size*/
+ /* The array table size */
unsigned int length;
- /* that analogic mask data */
+ /* That analogic mask data */
u32 data_mask;
- /* the sort mode is adc value that increment or decrement in table */
+ /* The sort mode is adc value that increment or decrement in table */
enum adc_sort_mode mode;
};
@@ -617,7 +617,7 @@ rockchip_thermal_register_sensor(struct platform_device
*pdev,
return 0;
}
-/*
+/**
* Reset TSADC Controller, reset all tsadc registers.
*/
static void rockchip_thermal_reset_controller(struct reset_control *reset)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 3/5] dt-bindings: rockchip-thermal: Support the RK3228/RK3399 SoCs compatible
This patchset attempts to new compatible for thermal founding on RK3228/RK3399 SoCs. Signed-off-by: Caesar Wang Acked-by: Rob Herring --- Changes in v1: - As Heiko comments, fix a copy incorrect name. - Add a Acked from Rob. Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt index 0dfa60d..08efe6b 100644 --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt @@ -2,8 +2,10 @@ Required properties: - compatible : should be "rockchip,-tsadc" + "rockchip,rk3228-tsadc": found on RK3228 SoCs "rockchip,rk3288-tsadc": found on RK3288 SoCs "rockchip,rk3368-tsadc": found on RK3368 SoCs + "rockchip,rk3399-tsadc": found on RK3399 SoCs - reg : physical base address of the controller and length of memory mapped region. - interrupts : The interrupt number to the cpu. The interrupt specifier format -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 0/5] Fix a trivial typo and support rk3228/rk3399 SoCs for thermal driver.
This series pacthes to support the next soc for this thermal driver. I don't add the dts thermal data since these SoCs have *_not_* land in this mainline. I believe these SoCs dts will land in this mainline lately, then I will add the thermal data for Heiko. This series patches can apply into Eduardo branch. https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git Also, this series pacthes have built on github branch. https://github.com/rockchip-linux/kernel/commits/develop4.4 PATCH[1/5]: That's bit ugly typo, sorry for sending again :(. PATCH[2/5]: To fix a build warning came from Dan Carpenter report smatch check, Thanks. :) PATCH[3/5]: Add the rk3228/rk3399 SoCs compatible for dt-bindings. PATCH[4/5]: Add the rk3228 SoCs for thermal driver. PATCH[5/5]: Add the rk3399 SoCs for thermal driver based on PATCH[4/5]. Changes in v1: - Search more trivial typo for me. - As Heiko comments, fix a copy incorrect name. - Add a Acked from Rob. - fix a irq ack is similar with RK3228 SoCs. Caesar Wang (5): thermal: rockchip: fix a trivial typo thermal: rockchip: fix a impossible condition caused by the warning dt-bindings: rockchip-thermal: Support the RK3228/RK3399 SoCs compatible thermal: rockchip: Support the RK3228 SoCs in thermal driver thermal: rockchip: Support the RK3399 SoCs in thermal driver .../bindings/thermal/rockchip-thermal.txt | 2 + drivers/thermal/rockchip_thermal.c | 167 +++-- 2 files changed, 159 insertions(+), 10 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon: rt8973: Add IRQF_ONESHOT to interrupt flags
On 2015년 11월 26일 03:01, Saurabh Sengar wrote:
> Add IRQF_ONESHOT if no primary handler is provided for request threaded
> irq
>
> Signed-off-by: Saurabh Sengar
> ---
> drivers/extcon/extcon-rt8973a.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/extcon/extcon-rt8973a.c b/drivers/extcon/extcon-rt8973a.c
> index 36bf1d6..e1bb8280 100644
> --- a/drivers/extcon/extcon-rt8973a.c
> +++ b/drivers/extcon/extcon-rt8973a.c
> @@ -603,7 +603,7 @@ static int rt8973a_muic_i2c_probe(struct i2c_client *i2c,
>
> ret = devm_request_threaded_irq(info->dev, virq, NULL,
> rt8973a_muic_irq_handler,
> - IRQF_NO_SUSPEND,
> + IRQF_NO_SUSPEND | IRQF_ONESHOT,
> muic_irq->name, info);
> if (ret) {
> dev_err(info->dev,
>
Applied it.
Thanks,
Chanwoo Choi
--
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] x86: mm: clean up probe_memory_block_size()
On Thu, Nov 26, 2015 at 10:12:01AM +0100, Ingo Molnar wrote:
>
> * Seth Jennings wrote:
>
> > The cumulative effect of bdee237c and 982792c7 is some pretty convoluted
> > code. This commit has no (intended) functional change; just seeks to
> > simplify and make the code more understandable.
> >
> > The whole section with the "tail size" doesn't seem to be reachable,
> > since both the >= 64GB and < 64GB case return, so it was removed.
> >
> > This commit also adds code back for the UV case since it seemed to just
> > go away without reason in bdee237c and might lead to unexpected change
> > in behavior.
> >
> > Signed-off-by: Seth Jennings
> > ---
> > arch/x86/mm/init_64.c | 22 ++
> > 1 file changed, 6 insertions(+), 16 deletions(-)
> >
> > diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> > index ec081fe..a83c470 100644
> > --- a/arch/x86/mm/init_64.c
> > +++ b/arch/x86/mm/init_64.c
> > @@ -52,6 +52,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include "mm_internal.h"
> > @@ -1194,26 +1195,15 @@ int kern_addr_valid(unsigned long addr)
> >
> > static unsigned long probe_memory_block_size(void)
> > {
> > + unsigned long bz = MIN_MEMORY_BLOCK_SIZE;
> >
> > + /* if system is UV or has 64GB of RAM or more, use large blocks */
> > + if (is_uv_system() || ((max_pfn << PAGE_SHIFT) >= (64UL << 30))) {
> > pr_info("Using 2GB memory block size for large-memory
> > system\n");
> > + bz = 2UL << 30; /* 2GB */
> > }
> >
> > + pr_debug("memory block size : %ldMB\n", bz >> 20);
> >
> > return bz;
> > }
>
> So why keep 'bz' at all? Just return with the right value and be done with
> it.
> 'bz' is just an unnecessary confusion factor.
Good point. Just send out v2.
Thanks,
Seth
>
> 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/
