Re: [PATCH 2/2] efi: Distinguish between "remaining space" and actually used space
On Wed, 2013-04-03 at 18:12 +0100, Matt Fleming wrote: > The solution you're proposing has the same downsides as 3) - we risk > having to tweak things either way. The difference is that in the case of > 3) the tweaking is adding entries to the whitelist, whereas tweaking > your solution has more chance of introducing further unwanted > regressions because you'd be tweaking an algorithm, an algorithm that > relies on the internal implementation of the variable storage code. We *risk* having to tweak things, and we fail on the side of safety. > > Dealing with firmware is hard. This fixes (1) without leaving us with > > (2), which seems like a net win. > > I'm not convinced that implementing 3) would inevitably lead to 2), > provided that we apply a bit of common sense when adding entries. I'm > not advocating some kind of flag day where we add umpteen machines to > the whitelist. > > For reference, I just pushed two patches to the 'whitelist' branch at, > > git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git > > which should hopefully illustrate the kind of thing that I'm talking about. I don't think that works. People are complaining that we broke some Thinkpads as well, but we also have reports that Thinkpads can be bricked if we use too much space. -- Matthew Garrett | mj...@srcf.ucam.org
Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples
On Tue, 2013-04-02 at 17:19 +0100, John Stultz wrote:
> But if we're going to have to do
> this via a clockid, I'm going to want it to be done via a dynamic posix
> clockid, so its clear its tightly tied with perf and not considered a
> generic interface (and I can clearly point folks having problems to the
> perf maintainers ;).
Ok, so how about the code below?
There are two distinct parts of the "solution":
1. The dynamic posix clock, as you suggested. Then one can get the perf
timestamp by doing:
clock_fd = open("/dev/perf-clock", O_RDONLY);
clock_gettime(FD_TO_CLOCKID(clock_fd), )
2. A sort-of-hack in the get_posix_clock() function making it possible
to do the same using the perf event file descriptor, eg.:
fd = sys_perf_event_open(, -1, 0, -1, 0);
clock_gettime(FD_TO_CLOCKID(fd), )
Any (either strong or not) opinions?
Pawel
8<--
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index e47ee46..b2127e3 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -52,6 +52,7 @@ struct perf_guest_info_callbacks {
#include
#include
#include
+#include
#include
struct perf_callchain_entry {
@@ -845,4 +846,6 @@ _name##_show(struct device *dev,
\
\
static struct device_attribute format_attr_##_name = __ATTR_RO(_name)
+struct posix_clock *perf_get_posix_clock(struct file *fp);
+
#endif /* _LINUX_PERF_EVENT_H */
diff --git a/kernel/events/core.c b/kernel/events/core.c
index b0cd865..534cb43 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7446,6 +7446,49 @@ unlock:
}
device_initcall(perf_event_sysfs_init);
+static int perf_posix_clock_getres(struct posix_clock *pc, struct timespec *tp)
+{
+ *tp = ns_to_timespec(TICK_NSEC);
+ return 0;
+}
+
+static int perf_posix_clock_gettime(struct posix_clock *pc, struct timespec
*tp)
+{
+ *tp = ns_to_timespec(perf_clock());
+ return 0;
+}
+
+static const struct posix_clock_operations perf_posix_clock_ops = {
+ .clock_getres = perf_posix_clock_getres,
+ .clock_gettime = perf_posix_clock_gettime,
+};
+
+static struct posix_clock perf_posix_clock;
+
+struct posix_clock *perf_get_posix_clock(struct file *fp)
+{
+ if (!fp || fp->f_op != _fops)
+ return NULL;
+
+ down_read(_posix_clock.rwsem);
+
+ return _posix_clock;
+}
+
+static int __init perf_posix_clock_init(void)
+{
+ dev_t devt;
+ int ret;
+
+ ret = alloc_chrdev_region(, 0, 1, "perf-clock");
+ if (ret)
+ return ret;
+
+ perf_posix_clock.ops = perf_posix_clock_ops;
+ return posix_clock_register(_posix_clock, devt);
+}
+device_initcall(perf_posix_clock_init);
+
#ifdef CONFIG_CGROUP_PERF
static struct cgroup_subsys_state *perf_cgroup_css_alloc(struct cgroup *cont)
{
diff --git a/kernel/time/posix-clock.c b/kernel/time/posix-clock.c
index ce033c7..e2a40a5 100644
--- a/kernel/time/posix-clock.c
+++ b/kernel/time/posix-clock.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -249,16 +250,21 @@ struct posix_clock_desc {
static int get_clock_desc(const clockid_t id, struct posix_clock_desc *cd)
{
struct file *fp = fget(CLOCKID_TO_FD(id));
+ struct posix_clock *perf_clk = NULL;
int err = -EINVAL;
if (!fp)
return err;
- if (fp->f_op->open != posix_clock_open || !fp->private_data)
+#if defined(CONFIG_PERF_EVENTS)
+ perf_clk = perf_get_posix_clock(fp);
+#endif
+ if ((fp->f_op->open != posix_clock_open || !fp->private_data) &&
+ !perf_clk)
goto out;
cd->fp = fp;
- cd->clk = get_posix_clock(fp);
+ cd->clk = perf_clk ? perf_clk : get_posix_clock(fp);
err = cd->clk ? 0 : -ENODEV;
out:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/2] cpufreq: AMD "frequency sensitivity feedback" powersave bias for ondemand governor
On Wed, Apr 03, 2013 at 07:04:56PM +0200, Borislav Petkov wrote: > On Wed, Apr 03, 2013 at 11:53:24AM -0500, Jacob Shin wrote: > > Then Thomas, Boris, would it be acceptable if enable the frequency > > feedback feature by default with a sane powersave_bias tunable value? > > And also add proper documentation for both vanila powersave_bias > > and powersave_bias with AMD frequency sensitivity loaded to > > Documentation/cpu-freq/ondemand ? > > Yeah, this was what I was proposing, basically. The only question here > is, would anyone want to disable freq decisions on systems with hw > feedback? If yes, then you'd need to be able to disable the feedback > thing, maybe have a magic value for powersave_bias... Writing 0 to powersave_bias or unloading the AMD driver could do that. When the AMD driver loads, it will give a sane default value to powersave_bias to enable it, when it unloads, it will put it back to 0 > > Thanks. > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- > -- > To unsubscribe from this list: send the line "unsubscribe cpufreq" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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] pinctrl: tegra: add suspend-resume support
On 04/03/2013 08:09 AM, Linus Walleij wrote: > On Thu, Mar 28, 2013 at 6:48 PM, Stephen Warren wrote: > >> Why can't we just use the device suspend/resume functions rather than >> global (syscore) suspend/resume functions? Presumably this is to ensure >> that all other drivers suspend first, then the pinctrl driver does, and >> the reverse for resume. Can't we rely on deferred probe to ensure that >> instead? >> >> To make that work, we might need every affected driver to define a dummy >> pinmux state in DT that references the pinctrl driver, to make sure they >> all get probed after the pinctrl driver. > > Hm that reminds me of that policy change I suggested a while back to > do this instead of using hogs where possible. > > It has the nice side-effect that when we inspect the debugfs info > all pins will be properly owned by respective consuming device. True, in theory that would also work. However, in practice with Tegra's pinmux, it has to all be set up at once to avoid any conflicts, so hogging is really the only practical way to use it in most cases. This is because in many cases, a single controller could have its signals routed out to many different pins (or sets of pins), rather than just having one possible location where each controller could be routed to. In other words, the pinmux is m:n rather than m:1. It's possible program the registers so that the same signal is connected to (or from depending on signal direction) multiple pins at once. If this is done, the behaviour is unspecified; who knows which pin will actually receive (or provide) that signal? This can easily happen if the whole pinmux is not initialized fully in one pass, i.e. through hogs. For example, the HW default may be for e.g. UART1 to get routed to pins A, and B, whereas a particular board may assume that UART1 is routed to pins X, Y. So, SW must program pins X, Y to mux in UART1. However, if pins A, B aren't also re-programmed away from the UART1 option, then UART 1 on X, Y may not actually work. In this case, we can't rely on some other driver having acquire/re-programmed pins A, B, unless it's the hog of the pin controller itself. Hence, the only sensible solution is for the pin controller to hog absolutely everything. The only exception would be for dynamic pin-muxing (e.g. pinctrl-based I2C muxing), where hopefully everything is chosen carefully to avoid this kind of issue. -- 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/4] x86, kdump: Retore crashkernel= to allocate low
On Wed, Apr 3, 2013 at 6:18 AM, Vivek Goyal wrote: > On Tue, Apr 02, 2013 at 01:36:02PM -0700, Yinghai Lu wrote: > > [..] >> > You are just describing what your code does. There is no theme or >> > justification behind this behavior. There is no uniformity. A user can >> > question that so far you used to honor last crashkernel= parameter and >> > suddenly in 3.9 that's no more the case. Out of blue crashkernel=X,high is >> > overriding crashkernel=X and it is not obivious why. >> >> Let me repeat again: >> we keep crashkernel=X old behavior with old kexec-tools. >> crashkernel=X;high is for new kexec-tools that support loading high. >> >> If the user want to use ,high but still with old kexec-tools, that is >> not going to work. >> >> Can we just keep it separated? > > Kernel does not know about old kexec-tools or new kexec-tools. Neither > kernel can enforce what command line options are passed by user. So > kernel needs to define a clean interface here which is easily understood > and is extensible also in future. Looks you are chasing wrong direction. Those four patches fixes the regression that Wang and you reported, User don't need to change their kexec-tools and boot command lines kdump still works. We will never can stop user doing crazy thing with their system. > > [..] >> > >> > If user wants 128M in low memory, they will just specify >> > crashkernel=128M;low >> >> in the kernel-parameter.txt, already says ;low is need to used with ;high. > > But why are we tying ;low to ;high. One should be easily extend > crashkernel=X to be able to reserve memory above 4G if specified amount > is not available below 4G. In that case also one might want to reserve > some low memory? I want to keep crashkernel=X to the old behavior. If you want to have crashkernel=X to allocate high above 4G, old kexec-tools will not work with new kernel. > > For that matter crashkernel=range1:size,range2:size syntax should be > extendible too to reserve memory above 4G if desired size of memory > is not available in low memory. > > Now in those cases too, one would like to have 72M of low memory > reserved. So ;low shoud not be tied to ;high necessarily. > > In fact current code does not care whetehr ;high was specified or not. > If memory is reserved above 4G, ;low code will kick in. No, that is not right. only when ;high is specified, kernel will try to allocate high above 4G. > >> >> > >> > If they want to control multiple ranges of memory, then that's the feature >> > we currently don't support. Currently we support only reserving one range >> > of memory. >> > >> > If you want to support multiple ranges of memory,then do it properly. >> > Parse all crashkernel= options, prepare a list of memory to be reserved >> > and unreserved, resolve all the conflicts between various options and >> > then reserve the memory. But that does not seem to be a requirement at >> > this point of time. >> >> No we does not support multiple ranges, as it will need more changes >> in kexec-tools. >> >> Can we stop here with those four patches? >> >> Later, we can extend it if it is really needed. > > crashkernel= options are already confusing. I think we with this patchset > we will just make them even more confusing and future extensions > difficult. So keep crashkernel= without high and low to old behavior. > > We really need to stick to the notion of only one crashkernel= option > is accepted and that is last one on command line. And if need be, > we need to work on multi range reservation feature where we process > and reserve ranges as specified by all crashkernel= parameters on > command line. That is kept. and only last high is honored > > Creating new combinations where some crashkernel= are preferred over > others and some crashkernel= options work with only selected crashkernel= > options, is asking for trouble, especially keeping in mind future > extensions. I don't think so. old conf that works before still use crashkernel= with high and low. old conf that does not work, could switch to crashkernel=;high/low with new kexec-tools > > I prefer following for 3.9. > > - process only right most crashkernel= option. what is "right most" ? only last crashkernel=X is honored? I restored that already with those four patches. > - implement crashkernel_no_auto_low option to opt out of auto reserved > low memory No, that is ugly. > - implement crashkernel=X;high to support high memory reservations. > > And now old kexec-tools user can use crashkernel=X while users needing > high memory reservation can use crashkernel=X;high. The four patches did not do that? > > If you really want to support user defined crashkernel=X;low along with > crashkernel=Y;high, that is really a multi range reservation feature and > need to be implemented properly instead of coming up with short cuts. No it is not. It's *you* want me to change "Crash kernel low" to "Crash kernel". Do we need to drop second patch? So will still keep
Re: [PATCH 2/2] efi: Distinguish between "remaining space" and actually used space
On 03/04/13 14:48, Matthew Garrett wrote: > On Wed, 2013-04-03 at 14:11 +0100, Matt Fleming wrote: > >> This looks like something that will differ between implementations, and the >> fact that it's appearing in our code is a sure sign that this isn't the way >> to >> go. > > Our choices right now are: > > 1) Break machines that don't garbage collect on every reboot > 2) Leave Samsungs (and some Lenovos?) vulnerable to bricking > 3) Maintain a whitelist or blacklist that will inevitably be inadequate, > either breaking otherwise working machines or risking bricking of broken > ones > 4) Attempt to implement something that'll work in all cases The solution you're proposing has the same downsides as 3) - we risk having to tweak things either way. The difference is that in the case of 3) the tweaking is adding entries to the whitelist, whereas tweaking your solution has more chance of introducing further unwanted regressions because you'd be tweaking an algorithm, an algorithm that relies on the internal implementation of the variable storage code. > Dealing with firmware is hard. This fixes (1) without leaving us with > (2), which seems like a net win. I'm not convinced that implementing 3) would inevitably lead to 2), provided that we apply a bit of common sense when adding entries. I'm not advocating some kind of flag day where we add umpteen machines to the whitelist. For reference, I just pushed two patches to the 'whitelist' branch at, git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git which should hopefully illustrate the kind of thing that I'm talking about. -- Matt Fleming, Intel Open Source Technology Center -- 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 10/10] perf sort: Consolidate sort_entry__setup_elide()
Em Wed, Apr 03, 2013 at 09:26:19PM +0900, Namhyung Kim escreveu:
> From: Namhyung Kim
>
> The same code was duplicate to places, factor them out to common
> sort__setup_elide().
Looks ok, applying after fixing up fuzzes due to this being at the end
of the patchseries. Things like this that are clear cleanups are best
positioned in the start of the patch series.
- Arnaldo
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/builtin-diff.c | 4 +---
> tools/perf/builtin-report.c | 20 +---
> tools/perf/builtin-top.c| 4 +---
> tools/perf/util/sort.c | 45
> +++--
> tools/perf/util/sort.h | 3 +--
> 5 files changed, 47 insertions(+), 29 deletions(-)
>
> diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
> index 03b56c542bb6..316bf13e59c7 100644
> --- a/tools/perf/builtin-diff.c
> +++ b/tools/perf/builtin-diff.c
> @@ -611,9 +611,7 @@ int cmd_diff(int argc, const char **argv, const char
> *prefix __maybe_unused)
>
> setup_pager();
>
> - sort_entry__setup_elide(_dso, symbol_conf.dso_list, "dso", NULL);
> - sort_entry__setup_elide(_comm, symbol_conf.comm_list, "comm",
> NULL);
> - sort_entry__setup_elide(_sym, symbol_conf.sym_list, "symbol",
> NULL);
> + sort__setup_elide(NULL);
>
> return __cmd_diff();
> }
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index c95fd92fbd44..bff244fa4b5d 100644
> --- a/tools/perf/builtin-report.c
> +++ b/tools/perf/builtin-report.c
> @@ -937,25 +937,7 @@ repeat:
> report.symbol_filter_str = argv[0];
> }
>
> - sort_entry__setup_elide(_comm, symbol_conf.comm_list, "comm",
> stdout);
> -
> - if (sort__mode == SORT_MODE__BRANCH) {
> - sort_entry__setup_elide(_dso_from,
> symbol_conf.dso_from_list, "dso_from", stdout);
> - sort_entry__setup_elide(_dso_to, symbol_conf.dso_to_list,
> "dso_to", stdout);
> - sort_entry__setup_elide(_sym_from,
> symbol_conf.sym_from_list, "sym_from", stdout);
> - sort_entry__setup_elide(_sym_to, symbol_conf.sym_to_list,
> "sym_to", stdout);
> - } else {
> - if (report.mem_mode) {
> - sort_entry__setup_elide(_dso,
> symbol_conf.dso_list, "symbol_daddr", stdout);
> - sort_entry__setup_elide(_dso,
> symbol_conf.dso_list, "dso_daddr", stdout);
> - sort_entry__setup_elide(_dso,
> symbol_conf.dso_list, "mem", stdout);
> - sort_entry__setup_elide(_dso,
> symbol_conf.dso_list, "local_weight", stdout);
> - sort_entry__setup_elide(_dso,
> symbol_conf.dso_list, "tlb", stdout);
> - sort_entry__setup_elide(_dso,
> symbol_conf.dso_list, "snoop", stdout);
> - }
> - sort_entry__setup_elide(_dso, symbol_conf.dso_list, "dso",
> stdout);
> - sort_entry__setup_elide(_sym, symbol_conf.sym_list,
> "symbol", stdout);
> - }
> + sort__setup_elide(stdout);
>
> ret = __cmd_report();
> if (ret == K_SWITCH_INPUT_DATA) {
> diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
> index 4aa504baaf0b..fe4acf568483 100644
> --- a/tools/perf/builtin-top.c
> +++ b/tools/perf/builtin-top.c
> @@ -1201,9 +1201,7 @@ int cmd_top(int argc, const char **argv, const char
> *prefix __maybe_unused)
> if (symbol__init() < 0)
> return -1;
>
> - sort_entry__setup_elide(_dso, symbol_conf.dso_list, "dso", stdout);
> - sort_entry__setup_elide(_comm, symbol_conf.comm_list, "comm",
> stdout);
> - sort_entry__setup_elide(_sym, symbol_conf.sym_list, "symbol",
> stdout);
> + sort__setup_elide(stdout);
>
> get_term_dimensions();
> if (top.print_entries == 0) {
> diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
> index 213831133e08..86ae94d8782e 100644
> --- a/tools/perf/util/sort.c
> +++ b/tools/perf/util/sort.c
> @@ -1,5 +1,6 @@
> #include "sort.h"
> #include "hist.h"
> +#include "symbol.h"
>
> regex_t parent_regex;
> const char default_parent_pattern[] = "^sys_|^do_page_fault";
> @@ -1085,8 +1086,9 @@ int setup_sorting(void)
> return ret;
> }
>
> -void sort_entry__setup_elide(struct sort_entry *self, struct strlist *list,
> - const char *list_name, FILE *fp)
> +static void sort_entry__setup_elide(struct sort_entry *self,
> + struct strlist *list,
> + const char *list_name, FILE *fp)
> {
> if (list && strlist__nr_entries(list) == 1) {
> if (fp != NULL)
> @@ -1095,3 +1097,42 @@ void sort_entry__setup_elide(struct sort_entry *self,
> struct strlist *list,
> self->elide = true;
> }
> }
> +
> +void sort__setup_elide(FILE *output)
> +{
> + sort_entry__setup_elide(_dso, symbol_conf.dso_list,
> + "dso", output);
>
Re: [PATCH 8/9] spark: cpufreq: move cpufreq driver to drivers/cpufreq
On 3 April 2013 22:08, David Miller wrote: > From: Viresh Kumar > Date: Wed, 3 Apr 2013 14:59:44 +0530 > >> On 1 April 2013 10:11, Viresh Kumar wrote: >>> On 31 March 2013 22:10, David Miller wrote: > On 26 March 2013 09:55, Viresh Kumar wrote: >> From: Viresh Kumar >> Date: Mon, 25 Mar 2013 11:20:23 +0530 >> Subject: [PATCH] sparc: cpufreq: move cpufreq driver to drivers/cpufreq >>> Subject line still has the "spark" typo. >>> >>> Your mail was scary, really... HOW can i do it?? >>> >>> And then i saw how you got it wrong. I haven't sent a new mail, so mails >>> subject >>> remains the same... I copied V2 in the same mail.. Check above, subject >>> looks >>> fine :) >> >> Hi David, >> >> I think all pending issues are fixed now... Can i have your Ack please? >> Or maybe more comments :) > > Acked-by: David S. Miller Adding everybody else in cc. -- 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: [ 34/77] xen/blkback: Dont trust the handle from the frontend.
On Wed, Apr 03, 2013 at 12:38:28PM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Apr 03, 2013 at 09:01:06AM -0700, Greg Kroah-Hartman wrote: > > On Wed, Apr 03, 2013 at 04:01:54PM +0200, William Dauchy wrote: > > > On Tue, Mar 12, 2013 at 11:10 PM, Greg Kroah-Hartman > > > wrote: > > > >> > >> IOW I don't see why this got proposed for stable at all. > > > >> > > > > > >> > > So, you suggest to just drop this patch for v3.8.3, don't you? > > > >> > > > > >> > I do, yes. But I'd suggest to get Konrad to agree. > > > >> > > > >> Yes. Lets drop it. > > > > > > > > Now reverted, thanks. > > > > > > Seems like still present in 3.4.x branch. Is that a mistake? > > > > It showed up in 3.4.35, if that's a mistake, and I should revert it, > > please, someone let me know. > > Yes. It is a mistake. Please revert it. Now reverted, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/10] perf hist browser: Use sort__has_sym
Em Wed, Apr 03, 2013 at 09:26:18PM +0900, Namhyung Kim escreveu:
> From: Namhyung Kim
>
> The TUI hist browser had a similar variable has_symbols for the same
> purpose. Let's get rid of the duplication.
I'm ok with that, if it involves removing sort__has_sym, that is a
global variable, making it impossible to use different sort orders in
the same session, if we ever want to do that :-)
- Arnaldo
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/ui/browsers/hists.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
> index cad8e37f05d9..a4268cab1921 100644
> --- a/tools/perf/ui/browsers/hists.c
> +++ b/tools/perf/ui/browsers/hists.c
> @@ -25,7 +25,6 @@ struct hist_browser {
> struct map_symbol *selection;
> int print_seq;
> bool show_dso;
> - bool has_symbols;
> };
>
> extern void hist_browser__init_hpp(void);
> @@ -1155,10 +1154,6 @@ static struct hist_browser *hist_browser__new(struct
> hists *hists)
> browser->b.refresh = hist_browser__refresh;
> browser->b.seek = ui_browser__hists_seek;
> browser->b.use_navkeypressed = true;
> - if (sort__mode == SORT_MODE__BRANCH)
> - browser->has_symbols = sort_sym_from.list.next != NULL;
> - else
> - browser->has_symbols = sort_sym.list.next != NULL;
> }
>
> return browser;
> @@ -1386,7 +1381,7 @@ static int perf_evsel__hists_browse(struct perf_evsel
> *evsel, int nr_events,
>*/
> goto out_free_stack;
> case 'a':
> - if (!browser->has_symbols) {
> + if (!sort__has_sym) {
> ui_browser__warning(>b, delay_secs * 2,
> "Annotation is only available for symbolic views, "
> "include \"sym*\" in --sort to use it.");
> @@ -1485,7 +1480,7 @@ static int perf_evsel__hists_browse(struct perf_evsel
> *evsel, int nr_events,
> continue;
> }
>
> - if (!browser->has_symbols)
> + if (!sort__has_sym)
> goto add_exit_option;
>
> if (sort__mode == SORT_MODE__BRANCH) {
> --
> 1.7.11.7
--
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 03/10] perf sort: Add 'addr' sort key
What I expected was that the result was this:
perf report --sort addr | grep -v ^# | sort -k2 -n | less
And in hexadecimal, can you fix this?
- Arnaldo
Em Wed, Apr 03, 2013 at 09:26:12PM +0900, Namhyung Kim escreveu:
> static void hists__set_unres_dso_col_len(struct hists *hists, int dso)
> diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
> index 14c2fe20aa62..9599f805828f 100644
> --- a/tools/perf/util/hist.h
> +++ b/tools/perf/util/hist.h
> @@ -43,12 +43,13 @@ enum hist_column {
> HISTC_COMM,
> HISTC_PARENT,
> HISTC_CPU,
> + HISTC_SRCLINE,
Why move SRCLINE?
> + HISTC_ADDR,
> HISTC_MISPREDICT,
> HISTC_SYMBOL_FROM,
> HISTC_SYMBOL_TO,
> HISTC_DSO_FROM,
> HISTC_DSO_TO,
> - HISTC_SRCLINE,
> HISTC_LOCAL_WEIGHT,
> HISTC_GLOBAL_WEIGHT,
> HISTC_MEM_DADDR_SYMBOL,
> diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
> index 1dbf16949250..5640a95b3575 100644
> --- a/tools/perf/util/sort.c
> +++ b/tools/perf/util/sort.c
> @@ -342,6 +342,34 @@ struct sort_entry sort_cpu = {
> .se_width_idx = HISTC_CPU,
> };
>
> +/* --sort addr */
> +
> +static int64_t
> +sort__addr_cmp(struct hist_entry *left, struct hist_entry *right)
> +{
> + return right->ip - left->ip;
> +}
> +
> +static int hist_entry__addr_snprintf(struct hist_entry *self, char *bf,
> + size_t size, unsigned int width)
> +{
> + struct map *map = self->ms.map;
> + u64 addr = self->ip;
> +
> + if (map)
> + addr = map->unmap_ip(map, self->ip);
> +
> + return repsep_snprintf(bf, size, "%#*llu", width, addr);
> +}
> +
> +struct sort_entry sort_addr = {
> + .se_header = "Address",
> + .se_cmp = sort__addr_cmp,
> + .se_snprintf= hist_entry__addr_snprintf,
> + .se_width_idx = HISTC_ADDR,
> +};
> +
> +
> /* sort keys for branch stacks */
>
> static int64_t
> @@ -871,6 +899,7 @@ static struct sort_dimension common_sort_dimensions[] = {
> DIM(SORT_PARENT, "parent", sort_parent),
> DIM(SORT_CPU, "cpu", sort_cpu),
> DIM(SORT_SRCLINE, "srcline", sort_srcline),
> + DIM(SORT_ADDR, "addr", sort_addr),
> };
>
> #undef DIM
> diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
> index 0232d476da87..0815e344f38c 100644
> --- a/tools/perf/util/sort.h
> +++ b/tools/perf/util/sort.h
> @@ -138,6 +138,7 @@ enum sort_type {
> SORT_PARENT,
> SORT_CPU,
> SORT_SRCLINE,
> + SORT_ADDR,
>
> /* branch stack specific sort keys */
> __SORT_BRANCH_STACK,
> --
> 1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] watchdog: Add Congatec CGEB watchdog driver
On Wed, Apr 03, 2013 at 08:30:00AM -0700, Guenter Roeck wrote: > On Wed, Apr 03, 2013 at 05:09:52PM +0200, Sascha Hauer wrote: > [ ... ] > > > > > > > On a side note, if the driver supports devicetree, it might make sense to > > > call > > > watchdog_init_timeout, since it initializes the timeout from devicetree > > > data. > > > > The driver does not support devicetree. > > > I should have said "the system". Calling watchdog_init_timeout is the only > thing > a watchdog driver has to do to support devicetree. The system does not use devicetrees. I'm very familiar with devicetrees on ARM, but I have never seen a x86 system with devicetree support (although I know they exist) Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 2/2] iio: adc: exynos_adc: Handle timeout and race conditions
Lars, On Sat, Mar 16, 2013 at 7:41 AM, Lars-Peter Clausen wrote: > I think you still need the mutex for serialization, otherwise the requests > would just cancel each other out. Btw. what happens if you start a conversion > while another is still in progress? Is it possible to abort a conversion? I was thinking that the spinlock would just replace the mutex for the purposes of serialization. I stepped back a bit, though, and I'm wondering if we're over-thinking things. The timeout case should certainly be handled properly (thanks for pointing it out), but getting a timeout is really not expected and adding a lot of extra overhead to handle it elegantly seems a bit much? Specifically, the mutex means that we have one user of the ADC at a time, and ADC conversion has nothing variable about it. The user manual that I have access to talks about 12-bit conversion happening in 1 microsecond with a 5MHz input clock or 5 microseconds with a 1MHz input clock. Even if someone has clocks configured very differently, it would be hard to imagine a conversion actually taking a full second. ...so that means that if the timeout actually fires then something else fairly drastic has gone wrong. It's _very_ unlikely that the IRQ will still go off for this conversion sometime in the future. To me, total modifications to what's landed already ought to be: * Change timeout to long (from unsigned long) * Make sure we return errors (negative results) from wait_for_completion_interruptible_timeout() properly. * If we get back a value of 0 from wait_for_completion_interruptible_timeout() then we should print a warning and attempt machinations to reset the ADC. Without ever seeing real-world situtations that would cause a real timeout these machinations would be a bit of a guess (is resetting the adc useful when it's more likely that someone accidentally messed with the clock tree or power gated the ADC?)... ...or perhaps a warning and a TODO in the code would be enough? Thoughts? -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 V3 2/2] cpufreq: AMD "frequency sensitivity feedback" powersave bias for ondemand governor
On Wed, Apr 03, 2013 at 11:53:24AM -0500, Jacob Shin wrote: > Then Thomas, Boris, would it be acceptable if enable the frequency > feedback feature by default with a sane powersave_bias tunable value? > And also add proper documentation for both vanila powersave_bias > and powersave_bias with AMD frequency sensitivity loaded to > Documentation/cpu-freq/ondemand ? Yeah, this was what I was proposing, basically. The only question here is, would anyone want to disable freq decisions on systems with hw feedback? If yes, then you'd need to be able to disable the feedback thing, maybe have a magic value for powersave_bias... Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NVIDIA RAID don't work with kernel 3.8
Hi! I have a motherboard ASUS M2N32-SLI DELUXE with chipset NVIDIA nForce ® 590 SLI ™ MCP (defined as the MCP55) with built-in hardware RAID which I have configured as a RAID 0 of 4-HDD When using kernel 3.8 in the openSUSE repository http://download.opensuse.org/repositories/Kernel:/stable/standard/x86_64/kernel-vanilla-3.8.5-1.1.x86_64.rpm I no longer identificate raid with a message at boot ERROR: nvidia: wrong # of devices in RAID set "nvidia_ieigdchd" [1/4] on /dev/sda ERROR: removing inconsistent RAID set "nvidia_ieigdchd" ERROR: no RAID set found In this case, the base kernel 3.7.10 works fine. Is maybe it some kind of boot options, or editing boot scripts to solve the problem? -- 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] mm, x86: Do not zero hugetlbfs pages at boot. -v2
On Wed, Apr 03, 2013 at 04:02:47PM +0200, Michal Hocko wrote:
> On Tue 02-04-13 21:43:44, Robin Holt wrote:
> [...]
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index ca9a7c6..7683f6a 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -1185,7 +1185,7 @@ int __weak alloc_bootmem_huge_page(struct hstate *h)
> > while (nr_nodes) {
> > void *addr;
> >
> > - addr = __alloc_bootmem_node_nopanic(
> > + addr = __alloc_bootmem_node_nopanic_notzeroed(
> > NODE_DATA(hstate_next_node_to_alloc(h,
> > _states[N_MEMORY])),
> > huge_page_size(h), huge_page_size(h), 0);
>
> Ohh, and powerpc seems to have its own opinion how to allocate huge
> pages. See arch/powerpc/mm/hugetlbpage.c
Do I need to address their allocations? Can I leave that part of the
changes as something powerpc can address if they are affected by this?
Robin
--
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 2/2] cpufreq: AMD "frequency sensitivity feedback" powersave bias for ondemand governor
On Tue, Apr 02, 2013 at 11:01:24PM +0200, Borislav Petkov wrote: > On Tue, Apr 02, 2013 at 10:51:51PM +0200, Thomas Renninger wrote: > > powersave_bias is undocumented in Documentation/cpu-freq/... > > I guess its use-case is for people who want to get some percent more > > power savings out of their laptop and do not care of the one or other > > percent performance. > > In fact I would like to get rid of this extra code and I expect nobody > > would > > miss it. > > I might miss a configuration tool where someone went through the code, > > documented things and allows users to set powersave_bias values through > > some /etc/* config files. > > Yep, if you want anyone to make use of this, it should better get > > embedded in more general, at least general ondemand code. > > Yeah, it all sounds like we want to enable this by default on systems > which support it. Maybe with an off-switch for people who want plain > ondemand decisions. > > The remaining systems with ripped out powersave_bias would get plain > ondemand governor decisions. Provided, of course, nobody uses > powersave_bias and the functionality doesn't make any sense anyway. Rafael, any thoughts on removing powersave_bias altogether ? If we remove it, then is it acceptable to add an alternate callback/ handler registration to ondemand governor to account for hardware feedback ? Or, if we don't want to remove powersave_bias, Then Thomas, Boris, would it be acceptable if enable the frequency feedback feature by default with a sane powersave_bias tunable value ? And also add proper documentation for both vanila powersave_bias and powersave_bias with AMD frequency sensitivity loaded to Documentation/cpu-freq/ondemand ? > > Thanks. > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!)
On 04/04/2013 12:46 AM, Christian Kujau wrote: > On Wed, 3 Apr 2013 at 15:02, Dmitry Monakhov wrote: >> Good news big endian cpu owners >> Please try following patches(second is most important): >> http://patchwork.ozlabs.org/patch/233396/ >> http://patchwork.ozlabs.org/patch/233397/ >> I hope this should fix all known issues > > Zheng Liu also sent a patch: > > [PATCH] ext4: fix a big-endian bug when an extent is zeroed out > > When I try to apply all three of those to 3.9-4c4, the 2nd one from Dmitry > fails: > > $ cat ~/dev/002-ext4_fix-cpu_vs_disk-conversions.diff | patch --dry-run -p1 > patching file fs/ext4/extents.c > Hunk #2 FAILED at 2999. > Hunk #3 FAILED at 3272. > Hunk #4 FAILED at 4639. > 3 out of 4 hunks FAILED -- saving rejects to file fs/ext4/extents.c.rej > patching file fs/ext4/indirect.c > Hunk #1 succeeded at 1539 (offset 215 lines). > patching file fs/ext4/inode.c > patching file fs/ext4/mmp.c > patching file fs/ext4/namei.c > patching file fs/ext4/super.c > Hunk #1 succeeded at 1951 (offset -3 lines). > patching file fs/ext4/xattr.c > patching file include/trace/events/ext4.h > Hunk #1 succeeded at 1956 (offset 8 lines). > Hunk #2 succeeded at 2060 (offset 8 lines). > Hunk #3 succeeded at 2079 (offset 8 lines). > > With only Dimitry's patchesm this happens, to -rc4: > > $ cat ~/dev/001-ext4_fix-usless-declarations.diff | patch -p1 > patching file fs/ext4/ialloc.c > patching file fs/ext4/ioctl.c > Hunk #1 succeeded at 359 (offset 4 lines). > patching file fs/ext4/mballoc.c > patching file fs/ext4/move_extent.c > > $ cat ~/dev/002-ext4_fix-cpu_vs_disk-conversions.diff | patch --dry-run -p1 > patching file fs/ext4/extents.c > Hunk #4 FAILED at 4639. > 1 out of 4 hunks FAILED -- saving rejects to file fs/ext4/extents.c.rej > patching file fs/ext4/indirect.c > Hunk #1 succeeded at 1539 (offset 215 lines). > patching file fs/ext4/inode.c > patching file fs/ext4/mmp.c > patching file fs/ext4/namei.c > patching file fs/ext4/super.c > Hunk #1 succeeded at 1951 (offset -3 lines). > patching file fs/ext4/xattr.c > patching file include/trace/events/ext4.h > Hunk #1 succeeded at 1956 (offset 8 lines). > Hunk #2 succeeded at 2060 (offset 8 lines). > Hunk #3 succeeded at 2079 (offset 8 lines). I guess that is because Dmitry's patch is against dev branch of ext4 tree. Please applied my patch. I think it could fix the bug. That would be great if you could give this patch a try [1]. 1. http://patchwork.ozlabs.org/patch/233555/ Thanks, - Zheng -- 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: s390x: kernel BUG at fs/ext4/inode.c:1591! (powerpc too!)
On Wed, 3 Apr 2013 09:46:56 -0700 (PDT), Christian Kujau wrote: > On Wed, 3 Apr 2013 at 15:02, Dmitry Monakhov wrote: > > Good news big endian cpu owners > > Please try following patches(second is most important): > > http://patchwork.ozlabs.org/patch/233396/ > > http://patchwork.ozlabs.org/patch/233397/ > > I hope this should fix all known issues > > Zheng Liu also sent a patch: > > [PATCH] ext4: fix a big-endian bug when an extent is zeroed out > > When I try to apply all three of those to 3.9-4c4, the 2nd one from Dmitry > fails: Yes. becase my patch was against ext4.git/dev so just ignore it. Teodore have sent a patch http://patchwork.ozlabs.org/patch/233555/ This is most probable candidate for final fix. > > $ cat ~/dev/002-ext4_fix-cpu_vs_disk-conversions.diff | patch --dry-run -p1 > patching file fs/ext4/extents.c > Hunk #2 FAILED at 2999. > Hunk #3 FAILED at 3272. > Hunk #4 FAILED at 4639. > 3 out of 4 hunks FAILED -- saving rejects to file fs/ext4/extents.c.rej > patching file fs/ext4/indirect.c > Hunk #1 succeeded at 1539 (offset 215 lines). > patching file fs/ext4/inode.c > patching file fs/ext4/mmp.c > patching file fs/ext4/namei.c > patching file fs/ext4/super.c > Hunk #1 succeeded at 1951 (offset -3 lines). > patching file fs/ext4/xattr.c > patching file include/trace/events/ext4.h > Hunk #1 succeeded at 1956 (offset 8 lines). > Hunk #2 succeeded at 2060 (offset 8 lines). > Hunk #3 succeeded at 2079 (offset 8 lines). > > With only Dimitry's patchesm this happens, to -rc4: > > $ cat ~/dev/001-ext4_fix-usless-declarations.diff | patch -p1 > patching file fs/ext4/ialloc.c > patching file fs/ext4/ioctl.c > Hunk #1 succeeded at 359 (offset 4 lines). > patching file fs/ext4/mballoc.c > patching file fs/ext4/move_extent.c > > $ cat ~/dev/002-ext4_fix-cpu_vs_disk-conversions.diff | patch --dry-run -p1 > patching file fs/ext4/extents.c > Hunk #4 FAILED at 4639. > 1 out of 4 hunks FAILED -- saving rejects to file fs/ext4/extents.c.rej > patching file fs/ext4/indirect.c > Hunk #1 succeeded at 1539 (offset 215 lines). > patching file fs/ext4/inode.c > patching file fs/ext4/mmp.c > patching file fs/ext4/namei.c > patching file fs/ext4/super.c > Hunk #1 succeeded at 1951 (offset -3 lines). > patching file fs/ext4/xattr.c > patching file include/trace/events/ext4.h > Hunk #1 succeeded at 1956 (offset 8 lines). > Hunk #2 succeeded at 2060 (offset 8 lines). > Hunk #3 succeeded at 2079 (offset 8 lines). > > > Christian. > -- > BOFH excuse #451: > > astropneumatic oscillations in the water-cooling -- 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] ext4: fix big-endian bugs which could cause fs corruptions
On 04/04/2013 12:36 AM, Theodore Ts'o wrote:
> From: Zheng Liu
>
> From: Zheng Liu
>
> When an extent was zeroed out, we forgot to do convert from cpu to le16.
> It could make us hit a BUG_ON when we try to write dirty pages out. So
> fix it.
>
> [ Also fix a bug found by Dmitry Monakhov where we were missing
> le32_to_cpu() calls in the new indirect punch hole code.
>
> There are a number of other big endian warnings found by static code
> analyzers, but we'll wait for the next merge window to fix them all
> up. These fixes are designed to be Obviously Correct by code
> inspection, and easy to demonstrate that it won't make any
> difference (and hence, won't introduce any bugs) on little endian
> architectures such as x86. --tytso ]
>
> Signed-off-by: Zheng Liu
> Signed-off-by: "Theodore Ts'o"
> Reported-by: CAI Qian
> Reported-by: Christian Kujau
> Cc: Dmitry Monakhov
Looks good to me.
Thanks,
- Zheng
> ---
>
> This is what I plan to be sending to Linus very shortly. If anyone
> could test / review this patch ASAP, I'd really appreciate it, thanks!!
>
> fs/ext4/extents.c | 11 +++
> fs/ext4/indirect.c | 4 ++--
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index 56efcaa..9c6d06d 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -2999,20 +2999,23 @@ static int ext4_split_extent_at(handle_t *handle,
> if (split_flag & EXT4_EXT_DATA_VALID1) {
> err = ext4_ext_zeroout(inode, ex2);
> zero_ex.ee_block = ex2->ee_block;
> - zero_ex.ee_len = ext4_ext_get_actual_len(ex2);
> + zero_ex.ee_len = cpu_to_le16(
> + ext4_ext_get_actual_len(ex2));
> ext4_ext_store_pblock(_ex,
> ext4_ext_pblock(ex2));
> } else {
> err = ext4_ext_zeroout(inode, ex);
> zero_ex.ee_block = ex->ee_block;
> - zero_ex.ee_len = ext4_ext_get_actual_len(ex);
> + zero_ex.ee_len = cpu_to_le16(
> + ext4_ext_get_actual_len(ex));
> ext4_ext_store_pblock(_ex,
> ext4_ext_pblock(ex));
> }
> } else {
> err = ext4_ext_zeroout(inode, _ex);
> zero_ex.ee_block = orig_ex.ee_block;
> - zero_ex.ee_len = ext4_ext_get_actual_len(_ex);
> + zero_ex.ee_len = cpu_to_le16(
> +
> ext4_ext_get_actual_len(_ex));
> ext4_ext_store_pblock(_ex,
> ext4_ext_pblock(_ex));
> }
> @@ -3272,7 +3275,7 @@ static int ext4_ext_convert_to_initialized(handle_t
> *handle,
> if (err)
> goto out;
> zero_ex.ee_block = ex->ee_block;
> - zero_ex.ee_len = ext4_ext_get_actual_len(ex);
> + zero_ex.ee_len = cpu_to_le16(ext4_ext_get_actual_len(ex));
> ext4_ext_store_pblock(_ex, ext4_ext_pblock(ex));
>
> err = ext4_ext_get_access(handle, inode, path + depth);
> diff --git a/fs/ext4/indirect.c b/fs/ext4/indirect.c
> index b505a14..a041831 100644
> --- a/fs/ext4/indirect.c
> +++ b/fs/ext4/indirect.c
> @@ -1539,9 +1539,9 @@ static int free_hole_blocks(handle_t *handle, struct
> inode *inode,
> blk = *i_data;
> if (level > 0) {
> ext4_lblk_t first2;
> - bh = sb_bread(inode->i_sb, blk);
> + bh = sb_bread(inode->i_sb, le32_to_cpu(blk));
> if (!bh) {
> - EXT4_ERROR_INODE_BLOCK(inode, blk,
> + EXT4_ERROR_INODE_BLOCK(inode, le32_to_cpu(blk),
> "Read failure");
> return -EIO;
> }
>
--
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] sgy-cts1000: Remove __dev* attributes
On Mar 18, 2013, at 6:19 PM, Ben Collins wrote: > Somehow the driver snuck in with these still in it. > > Signed-off-by: Ben Collins > --- > arch/powerpc/platforms/85xx/sgy_cts1000.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) applied to next - k -- 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: [ 34/77] xen/blkback: Dont trust the handle from the frontend.
On Wed, Apr 03, 2013 at 09:01:06AM -0700, Greg Kroah-Hartman wrote: > On Wed, Apr 03, 2013 at 04:01:54PM +0200, William Dauchy wrote: > > On Tue, Mar 12, 2013 at 11:10 PM, Greg Kroah-Hartman > > wrote: > > >> > >> IOW I don't see why this got proposed for stable at all. > > >> > > > > >> > > So, you suggest to just drop this patch for v3.8.3, don't you? > > >> > > > >> > I do, yes. But I'd suggest to get Konrad to agree. > > >> > > >> Yes. Lets drop it. > > > > > > Now reverted, thanks. > > > > Seems like still present in 3.4.x branch. Is that a mistake? > > It showed up in 3.4.35, if that's a mistake, and I should revert it, > please, someone let me know. Yes. It is a mistake. Please revert it. > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] drivers/block/xen-blkback: preq.dev is used without initialized
On Wed, Apr 03, 2013 at 03:34:16PM +0100, Jan Beulich wrote: > >>> On 03.04.13 at 15:56, William Dauchy wrote: > > On Wed, Apr 3, 2013 at 3:42 PM, Jan Beulich wrote: > >> ChangeLog-3.8.3 for example has > > > > oh sorry, you are right. I wasn't looking is the 3.8.x branch. > > The thing is, the revert seems present only in 3.8.x branch. For > > example in 3.4.x the last patch is still 01c681d > > Should we consider this normal or is it a mistake? > > I think it is a mistake, but ultimately it's Konrad's call. It is a mistake. Please revert it if possible. > > Jan > -- 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] cpufreq: convert the cpufreq_driver to use the rcu
On 04/03/2013 10:32 AM, Viresh Kumar wrote:
Please always mention Version number and history. Not everybody
remembers what changed after last version.
Your right. I was rushing and forgot.
I need to develop the habit of adding some history to my git commits
when I amend them.
On 3 April 2013 20:33, Nathan Zimmer wrote:
We eventually would like to remove the rwlock cpufreq_driver_lock or convert
it back to a spinlock and protect the read sections with RCU. The first step in
Why do we want to convert it back to spinlock?
Documentation/spinlocks.txt:84
I am not sure why but there is the directive I am following.
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
bool have_governor_per_policy(void)
{
- return cpufreq_driver->have_governor_per_policy;
+ bool have_governor;
Name it have_governor_per_policy, it looks wrong otherwise.
+ rcu_read_lock();
+ have_governor =
rcu_dereference(cpufreq_driver)->have_governor_per_policy;
+ rcu_read_unlock();
+ return have_governor;
}
Will do.
static ssize_t show_scaling_driver(struct cpufreq_policy *policy, char *buf)
{
- return scnprintf(buf, CPUFREQ_NAME_PLEN, "%s\n", cpufreq_driver->name);
+ char *name;
+ rcu_read_lock();
+ name = rcu_dereference(cpufreq_driver)->name;
+ rcu_read_unlock();
+ return scnprintf(buf, CPUFREQ_NAME_PLEN, "%s\n", name);
}
This is the definition of struct cpufreq_driver:
struct cpufreq_driver {
struct module *owner;
charname[CPUFREQ_NAME_LEN];
...
};
Purpose of rcu read_lock/unlock are to define the rcu critical section
after which rcu layer is free to free the memory allocated to earlier
instance of cpufreq_driver.
So, after the unlock() call you _should_not_ use the memory allocated to
cpufreq_driver instance. And here, you are using memory allocated to name[]
after the unlock() call.
Ok I'll fix this spot.
Which looks to be wrong... I left other parts of driver upto you to fix for this
"rule of thumb".
In places like show_bios_limit and cpufreq_add_dev_interface we know
that the memory will still
be there since the cpufreq_driver->owner is held.
Sorry for not pointing this earlier but rcu is as new to me as it is
to you. I know
you must be frustrated with so many versions of this patch, and everytime we
get a new problem to you... Don't get disheartened with it.. Keep the good work
going :)
Making a learners mistake isn't really discouraging to me, even when I
do it twice.
--
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/
[PATCH] ext4: fix big-endian bugs which could cause fs corruptions
From: Zheng Liu
From: Zheng Liu
When an extent was zeroed out, we forgot to do convert from cpu to le16.
It could make us hit a BUG_ON when we try to write dirty pages out. So
fix it.
[ Also fix a bug found by Dmitry Monakhov where we were missing
le32_to_cpu() calls in the new indirect punch hole code.
There are a number of other big endian warnings found by static code
analyzers, but we'll wait for the next merge window to fix them all
up. These fixes are designed to be Obviously Correct by code
inspection, and easy to demonstrate that it won't make any
difference (and hence, won't introduce any bugs) on little endian
architectures such as x86. --tytso ]
Signed-off-by: Zheng Liu
Signed-off-by: "Theodore Ts'o"
Reported-by: CAI Qian
Reported-by: Christian Kujau
Cc: Dmitry Monakhov
---
This is what I plan to be sending to Linus very shortly. If anyone
could test / review this patch ASAP, I'd really appreciate it, thanks!!
fs/ext4/extents.c | 11 +++
fs/ext4/indirect.c | 4 ++--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 56efcaa..9c6d06d 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -2999,20 +2999,23 @@ static int ext4_split_extent_at(handle_t *handle,
if (split_flag & EXT4_EXT_DATA_VALID1) {
err = ext4_ext_zeroout(inode, ex2);
zero_ex.ee_block = ex2->ee_block;
- zero_ex.ee_len = ext4_ext_get_actual_len(ex2);
+ zero_ex.ee_len = cpu_to_le16(
+ ext4_ext_get_actual_len(ex2));
ext4_ext_store_pblock(_ex,
ext4_ext_pblock(ex2));
} else {
err = ext4_ext_zeroout(inode, ex);
zero_ex.ee_block = ex->ee_block;
- zero_ex.ee_len = ext4_ext_get_actual_len(ex);
+ zero_ex.ee_len = cpu_to_le16(
+ ext4_ext_get_actual_len(ex));
ext4_ext_store_pblock(_ex,
ext4_ext_pblock(ex));
}
} else {
err = ext4_ext_zeroout(inode, _ex);
zero_ex.ee_block = orig_ex.ee_block;
- zero_ex.ee_len = ext4_ext_get_actual_len(_ex);
+ zero_ex.ee_len = cpu_to_le16(
+
ext4_ext_get_actual_len(_ex));
ext4_ext_store_pblock(_ex,
ext4_ext_pblock(_ex));
}
@@ -3272,7 +3275,7 @@ static int ext4_ext_convert_to_initialized(handle_t
*handle,
if (err)
goto out;
zero_ex.ee_block = ex->ee_block;
- zero_ex.ee_len = ext4_ext_get_actual_len(ex);
+ zero_ex.ee_len = cpu_to_le16(ext4_ext_get_actual_len(ex));
ext4_ext_store_pblock(_ex, ext4_ext_pblock(ex));
err = ext4_ext_get_access(handle, inode, path + depth);
diff --git a/fs/ext4/indirect.c b/fs/ext4/indirect.c
index b505a14..a041831 100644
--- a/fs/ext4/indirect.c
+++ b/fs/ext4/indirect.c
@@ -1539,9 +1539,9 @@ static int free_hole_blocks(handle_t *handle, struct
inode *inode,
blk = *i_data;
if (level > 0) {
ext4_lblk_t first2;
- bh = sb_bread(inode->i_sb, blk);
+ bh = sb_bread(inode->i_sb, le32_to_cpu(blk));
if (!bh) {
- EXT4_ERROR_INODE_BLOCK(inode, blk,
+ EXT4_ERROR_INODE_BLOCK(inode, le32_to_cpu(blk),
"Read failure");
return -EIO;
}
--
1.7.12.rc0.22.gcdd159b
--
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/1] Introduce Intel RAPL cooling device driver
On Tue, Apr 02, 2013 at 09:48:18PM -0700, Jacob Pan wrote: > > Let's step back and start over, what exactly are you trying to tell > > userspace? What data do you have that you need to express to it? How > > do you want userspace to see/use it? > > It is a good idea to step back and let me explain what I wanted to > do here for userspace. > > I have two kinds of applications that might use this driver. > 1. simple use case where user sets a power limit for a RAPL domain. > e.g. set graphics unit power limit to 7w > 2. advanced use case where use can do fine tuning on top of simple > power limit,e.g. the dynamic response parameters of power control > logic, event notifications, etc. > > For #1, this driver register with the abstract generic thermal layer > (/sys/class/thermal) and presents itself as a set of cooling devices > with a single knob per domain for power limits. > root@chromoly:/sys/class/thermal/cooling_device15# echo 7000 > cur_state Great, how about submitting that functionality as patch 1 of your series? That seems like a very "normal" thermal driver, right? > For #2, to give userspace complete control of the RAPL interface, which > is not generic, I put them under the device private sysfs area. > root@chromoly:/sys/class/thermal/cooling_device15/device# echo 1000 > > time_window1 I totally fail to understand the difference. What do you want to show to userspace that can't be expressed through the thermal interface today? Perhaps the thermal interface could be expanded to provide more functionality that you need? Why create a one-off API that will never be used again and require userspace programs to be written just to handle this one type of device? > As you mentioned about using device tree vs. fs, and how kobject are > used for fs. I do have the need to go between a generic thermal sysfs > and the true device tree. This is the reason why I used kobjects and > link them between device tree and its thermal sysfs representation. I don't understand your leap to using kobjects. > e.g. a RAPL package cooling device linked with its platform device > kobj. (device is linked with rapl_domains/package, the line is too long) > > root@chromoly:/sys/class/thermal# ls -l cooling_device15/ > total 0 > -rw-r--r-- 1 root root 4096 Apr 2 15:03 cur_state > lrwxrwxrwx 1 root root0 Apr 2 21:28 device > -> ../../../platform/intel_rapl/rapl_domains/package > -r--r--r-- 1 root root 4096 Apr 2 15:03 max_state > drwxr-xr-x 2 root root0 Apr 2 21:28 power > lrwxrwxrwx 1 root root0 Apr 2 15:03 subsystem > -> ../../../../class/thermal > -r--r--r-- 1 root root 4096 Apr 2 15:03 type > -rw-r--r-- 1 root root 4096 Apr 2 15:03 uevent I still don't understand. What are you adding here, the device symlink? Or something else? > For userspace which is not satisfied with the simple use case of a > single knob for setting power limit, it can follow the link to find the > device tree entry. Then get access to the complete knobs, including > event notifications. And what is in that device directory? What is rapl_domains? Why isn't that a normal 'struct device'? Still confused. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/6] Generic PHY Framework
From: Kishon Vijay Abraham I Date: Wed, 3 Apr 2013 12:05:30 +0530 > This patch series is about drivers/phy which will be used for now by > usb, sata and maybe some video PHY's. Network itself has a > comprehensive PHY in drivers/net/phy which we'd like to merge it with > drivers/phy so that we have all the phy stuff in drivers/phy but we > are not planning too far ahead here. Ok, that makes sense, 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 v8 5/5] hwmon: add ST-Ericsson ABX500 hwmon driver
On Wed, Apr 03, 2013 at 08:18:12PM +0800, Hongbo Zhang wrote: > Each of ST-Ericsson X500 chip set series consists of both ABX500 and DBX500 > chips. This is ABX500 hwmon driver, where the abx500.c is a common layer for > all ABX500s, and the ab8500.c is specific for AB8500 chip. Under this designed > structure, other chip specific files can be added simply using the same common > layer abx500.c. > > Signed-off-by: Hongbo Zhang Acked-by: Guenter Roeck -- 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 v8 4/5] ab8500: power: export abx500_res_to_temp tables for hwmon
On Wed, Apr 03, 2013 at 08:18:11PM +0800, Hongbo Zhang wrote: > This patch exports the thermistor resistance-to-temperature tables, so that > the > hwmon driver can access them, and also adds the corresponding table size > variables. > > Signed-off-by: Hongbo Zhang Acked-by: Guenter Roeck -- 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] clk: divider: Introduce CLK_DIVIDER_ALLOW_ZERO flag
On Wed, Apr 03, 2013 at 08:40:27AM -0700, Mike Turquette wrote: > Quoting Soren Brinkmann (2013-04-02 15:36:56) > > Dividers which have CLK_DIVIDER_ONE_BASED set have a redundant state, > > being a divider value of zero. Some hardware implementations allow a > > zero divider which simply doesn't alter the frequency. I.e. it acts like > > a divide by one or bypassing the divider. > > This flag is used to handle such HW in the clk-divider model. > > > > Signed-off-by: Soren Brinkmann > > This version looks good. Taken into clk-next. Thanks. Sören -- 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/1] Introduce Intel RAPL cooling device driver
On Tue, Apr 02, 2013 at 05:17:14PM -0700, Jacob Pan wrote:
> On Tue, 2 Apr 2013 16:48:05 -0700
> Greg KH wrote:
>
> > On Tue, Apr 02, 2013 at 04:33:57PM -0700, Jacob Pan wrote:
> > > On Tue, 2 Apr 2013 16:00:42 -0700
> > > Greg KH wrote:
> > >
> > > > > +#include "intel_rapl.h"
> > > > > +#include "../../../fs/sysfs/sysfs.h"
> > > >
> > > > WTF?
> > > >
> > > > Oh, that's a sure sign you are not doing something properly, if
> > > > you think it's ok to muck around with the internals of sysfs.
> > > >
> > > > There's a reason that file is "private", why do you think it's ok
> > > > to use it directly? Did you just think that I somehow "forgot"
> > > > to put it in the proper include directory?
> > > I did feel unsure about this but i saw some precedence in the
> > > kernel.
> >
> > Someone else is doing this with the sysfs api? I don't see any other
> > code in Linus's tree doing this at the moment, where did you see this?
> > Let me know and I'll fix it up right away.
> >
> no, i did not mean sysfs api. I mean include internal header files via
> #include ../../
> e.g.in drivers/usb/image/microtek.c
>
> #include "../../scsi/scsi.h"
> #include
That is because this is a scsi host driver. Your code is not part of
sysfs itself.
> > > Anyway, I needed a way to validate a userspace file passed to rapl
> > > driver belong to the same sysfs directory. I will look for
> > > alternative ways.
> >
> > What do you mean by this? What exactly are you trying to do? No
> > normal driver code should _ever_ call sysfs functions directly, nor
> > should they ever care about sysfs internals.
> >
> i did not call sysfs internal calls, just need to use
> struct sysfs_dirent {}
>
> to do the following sanity check against user passed event control file,
> it is still not a 100% strong check.
> /* check if the cfile belongs to the same rapl domain */
> if (strcmp(rd->kobj.sd->s_name,
> cfile->f_dentry->d_parent->d_name.name)) {
> pr_debug("cfile does not belong to domain %s\n",
> rd->kobj.sd->s_name);
> ret = -EINVAL;
> goto exit_cleanup_fds;
> }
This made it through a code review at Intel? Seriously? Come on,
there's just so much wrong here, I don't know where to begin.
Hint, if you find yourself caring about the internals of sysfs in a
device driver, you are doing something so wrong it's not funny. Do you
see _any_ other driver doing anything like this? What makes this driver
so special that it can do unexpected, and totally different things with
sysfs?
> > And, odds are, you didn't test your code as a module, right, as any
> > internal sysfs function that you could get from this .h file, wouldn't
> > be exported for a module to use, unless I missed one somewhere?
> >
> I did run the driver as module since i didn't use sysfs internal
> functions, just the struct. I may be hitting a corner case here, but
> for drivers who need to discover sysfs hierarchy would it be useful to
> expose some info in struct sysfs_dirent{}?
No, not at all, why would a driver ever care about that? Somehow we
have gotten by for the past 10+ years without needing it, why is your
driver so different than the thousands of other Linux drivers?
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] nfsd4: Fix NULL dereference in legacy_recdir_name_error()
The recent rewrite of NFSv4 recovery client tracking options per net
(commit 9a9c6478) introduced Oops when it faces an error for recdir
generation.
NFSD: unable to generate recoverydir name (-2).
NFSD: disabling legacy clientid tracking. Reboot recovery will not function
correctly!
BUG: unable to handle kernel NULL pointer dereference at 07a8
IP: [] nfsd4_client_tracking_exit+0x17/0x70 [nfsd]
PGD 0
Oops: [#1] PREEMPT SMP
Modules linked in: nfsd fuse nfsv3 nfs_acl nfsv4 auth_rpcgss nfs lockd sunrpc
cpufreq_conservative cpufreq_userspace cpufreq_powersave snd_hda_codec_hdmi
snd_hda_codec_realtek intel_powerclamp acpi_cpufreq mperf coretemp
ghash_clmulni_intel aesni_intel kvm_intel snd_hda_intel ablk_helper
snd_hda_codec snd_hwdep kvm snd_pcm cryptd lrw aes_x86_64 snd_timer xts
gf128mul e1000e snd sr_mod iTCO_wdt microcode cdrom usb_storage dcdbas
iTCO_vendor_support i2c_i801 cdc_acm sg ptp lpc_ich mei soundcore pps_core
mfd_core snd_page_alloc pciehp pci_hotplug autofs4 btrfs raid6_pq zlib_deflate
xor libcrc32c i915 crc32c_intel drm_kms_helper drm xhci_hcd i2c_algo_bit
thermal button video processor thermal_sys scsi_dh_rdac scsi_dh_hp_sw
scsi_dh_emc scsi_dh_alua scsi_dh
CPU 1
Pid: 19567, comm: nfsd Not tainted 3.9.0-rc5-test+ #3 Dell Inc. OptiPlex
9010/0M9KCM
RIP: 0010:[] []
nfsd4_client_tracking_exit+0x17/0x70 [nfsd]
RSP: 0018:880181099c28 EFLAGS: 00010202
RAX: 8801810900c0 RBX: 0004 RCX: 0006
RDX: 0007 RSI: 0046 RDI:
RBP: 880181099c38 R08: 000a R09: 039f
R10: R11: 039e R12:
R13: 81a87280 R14: 88014c819220 R15: 88020b75d200
FS: () GS:88021e24() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 07a8 CR3: 01a0d000 CR4: 001407e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process nfsd (pid: 19567, threadinfo 880181098000, task 8801810900c0)
Stack:
fffe 88020b75d200 880181099c58 a060c75c
81a87280 880002ba7000 880181099cc8 a060cb37
880181099d20 88014c819220 0001 88020b75d200
Call Trace:
[] legacy_recdir_name_error+0x3c/0x40 [nfsd]
[] nfsd4_create_clid_dir+0xe7/0x200 [nfsd]
[] ? nfs4_preprocess_seqid_op+0x63/0x160 [nfsd]
[] nfsd4_client_record_create+0x5f/0x80 [nfsd]
[] nfsd4_open_confirm+0x12f/0x1b0 [nfsd]
[] nfsd4_proc_compound+0x55f/0x770 [nfsd]
[] nfsd_dispatch+0xdd/0x220 [nfsd]
[] svc_process_common+0x328/0x6d0 [sunrpc]
[] svc_process+0x10c/0x160 [sunrpc]
[] nfsd+0xbf/0x130 [nfsd]
[] ? nfsd_destroy+0x90/0x90 [nfsd]
[] kthread+0xbb/0xc0
[] ? kthread_create_on_node+0x130/0x130
[] ret_from_fork+0x7c/0xb0
[] ? kthread_create_on_node+0x130/0x130
Code: e0 49 8b 84 24 48 01 00 00 e9 25 ff ff ff 66 0f 1f 44 00 00 55 48 89 e5
41 54 49 89 fc 53 8b 1d 44 b4 00 00 e8 bb a9 a5 e0 85 db <49> 8b 84 24 a8 07 00
00 74 43 3b 18 77 3f 83 eb 01 48 63 db 48
RIP [] nfsd4_client_tracking_exit+0x17/0x70 [nfsd]
RSP
CR2: 07a8
---[ end trace 5dd4307598e98cef ]---
This patch fixes it by passing the proper net instance instead of
NULL.
Signed-off-by: Takashi Iwai
Cc: [v3.8+]
---
fs/nfsd/nfs4recover.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/fs/nfsd/nfs4recover.c b/fs/nfsd/nfs4recover.c
index 899ca26..ae0d5c9 100644
--- a/fs/nfsd/nfs4recover.c
+++ b/fs/nfsd/nfs4recover.c
@@ -146,7 +146,7 @@ out_no_tfm:
* then disable recovery tracking.
*/
static void
-legacy_recdir_name_error(int error)
+legacy_recdir_name_error(struct net *net, int error)
{
printk(KERN_ERR "NFSD: unable to generate recoverydir "
"name (%d).\n", error);
@@ -160,8 +160,7 @@ legacy_recdir_name_error(int error)
printk(KERN_ERR "NFSD: disabling legacy clientid tracking. "
"Reboot recovery will not function correctly!\n");
- /* the argument is ignored by the legacy exit function */
- nfsd4_client_tracking_exit(NULL);
+ nfsd4_client_tracking_exit(net);
}
}
@@ -184,7 +183,7 @@ nfsd4_create_clid_dir(struct nfs4_client *clp)
status = nfs4_make_rec_clidname(dname, >cl_name);
if (status)
- return legacy_recdir_name_error(status);
+ return legacy_recdir_name_error(clp->net, status);
status = nfs4_save_creds(_cred);
if (status < 0)
@@ -341,7 +340,7 @@ nfsd4_remove_clid_dir(struct nfs4_client *clp)
status = nfs4_make_rec_clidname(dname, >cl_name);
if (status)
- return legacy_recdir_name_error(status);
+ return
Re: [PATCH 3.8-stable] thermal: return an error on failure to register thermal
On Wed, Apr 03, 2013 at 09:38:55AM +0900, Jonghwan Choi wrote: > 3.8-stable review patch. If anyone has any objections, please let me know. Ok, I object, given that I told you to change the format of the message you send out. Please look at how others on the stable@ mailing list send "should this patch be applied" messages, and copy how that is done. > -- > > From: "Richard Guy Briggs " > > commit da28d966f6aa942ae836d09729f76a1647932309 upstream. > > The return code from the registration of the thermal class is used to > unallocate resources, but this failure isn't passed back to the caller of > thermal_init. Return this failure back to the caller. > > This bug was introduced in changeset 4cb18728 which overwrote the return > code > when the variable was re-used to catch the return code of the registration > of > the genetlink thermal socket family. You linewrapped the patch message, careful, you might mess up the patch itself as well :( > Signed-off-by: Richard Guy Briggs > Signed-off-by: Zhang Rui You aren't signing off on it as well? Why not? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] ARM: keep __my_cpu_offset consistent with generic one
On Tue, Mar 12, 2013 at 10:56:38AM +, Russell King - ARM Linux wrote: > On Tue, Mar 12, 2013 at 10:32:21AM +0800, Ming Lei wrote: > > On Thu, Mar 7, 2013 at 9:35 PM, Ming Lei wrote: > > > Commit 14318efb(ARM: 7587/1: implement optimized percpu variable access) > > > introduces arm's __my_cpu_offset to optimize percpu vaiable access, > > > which really works well on hackbench, but will cause __my_cpu_offset > > > to return garbage value before it is initialized in cpu_init() called > > > by setup_arch, so accessing percpu variable before setup_arch may cause > > > kernel hang. But generic __my_cpu_offset always returns zero before > > > percpu area is brought up, and won't hang kernel. > > > > > > So the patch tries to clear __my_cpu_offset on boot CPU early > > > to avoid boot hang. > > > > > > At least now percpu variable is accessed by lockdep before > > > setup_arch(), and enabling CONFIG_LOCK_STAT or CONFIG_DEBUG_LOCKDEP > > > can trigger kernel hang. > > > > > > Cc: Peter Zijlstra > > > Cc: Ingo Molnar > > > Cc: Rob Herring > > > Cc: Will Deacon > > > Cc: Nicolas Pitre > > > Cc: Russell King > > > Signed-off-by: Ming Lei > > > --- > > > V1: > > > - documents lockdep uses percpu variable early > > > > Looks no one objects the patch, so I has submitted it into Russell's > > patch system, and hope it can be pushed to linus tree soon and > > make LOCK_STAT/DEBUG_LOCKDEP usable on ARMv7. > > I'm not convinced it is correct. Is the percpu data as stored in the > kernel image (in other words, at offset zero) supposed to be read only? > If so, the above means that we'll be accessing that rather than the > copy of the percpu data we should be accessing. > > The percpu data areas are allocated by setup_per_cpu_areas() - that's > where we should be initializing this, just like it's done on PowerPC. Still not convinced this is a proper fix. Look, the problem is this: - Initially, set the CPU percpu offset to zero. This means the boot CPU reads and writes to the percpu data section in the kernel image. - The percpu areas are initialized, and the percpu data copied to each percpu data - this will have any writes from the boot CPU included as changes to the percpu data. - The boot CPU continues to read/write to the percpu data section. - If the boot CPU suspends/resumes, cpu_init() gets called, which will call set_my_cpu_offset(per_cpu_offset(cpu)); for the boot CPU. - The boot CPU now uses the allocated percpu data section and any updates it did in the percpu data section in the kernel image are lost to it. Your patch may be right on its own to solve the initial problem, but it leaves a _big_ hole. Now, the big question here: is it right that the boot CPU should ever write to the static percpu data section in the kernel image? What if there's a pointer in there, initially NULL, which then gets checked by each CPU and initialized if NULL - we'll end up sharing the same allocation amongst all CPUs, which probably isn't what was intended. If there's a list_head which gets added to, that too will be very bad. Although you have uncovered a problem, I still think by setting the offset to zero initially, you're just papering over a much bigger can of worms. So, should percpu data be used this early in boot before the percpu stuff is properly initialized? That feels _extremely_ unsafe. This, I think, needs to be addressed properly. And part of that is knowing where things went wrong. Will Deacon asked you for a backtrace showing where this problem occured. Your response seems to be to resend the patch with a "v1" tag a no new information. Sorry, not applying this until the above issue has been discussed and the location of these percpu accesses has been properly analysed. -- 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] pinctrl: tegra: add suspend-resume support
On Thu, Mar 28, 2013 at 6:11 PM, Bibek Basu wrote:
Hm I recognize this name :-)
> This patch adds suspend and resume callbacks to the pinctrl-tegra driver.
Please be more verbose. How is this achieved? I have to
guess what the code is doing..
> +#ifdef CONFIG_PM_SLEEP
> +
> +static int pinctrl_suspend(void)
> +{
> + int i, j;
> + u32 *pg_data = pmx->pg_data;
> + u32 *regs;
> +
> + for (i = 0; i < pmx->nbanks; i++) {
> + regs = pmx->regs[i];
> + for (j = 0; j < pmx->regs_size[i] / 4; j++)
> + *pg_data++ = readl(regs++);
> + }
> + return 0;
> +}
> +
> +static void pinctrl_resume(void)
> +{
> + int i, j;
> + u32 *pg_data = pmx->pg_data;
> + u32 *regs;
> +
> + for (i = 0; i < pmx->nbanks; i++) {
> + regs = pmx->regs[i];
> + for (j = 0; j < pmx->regs_size[i] / 4; j++)
> + writel(*pg_data++, regs++);
> + }
> +}
> +
> +static struct syscore_ops pinctrl_syscore_ops = {
> + .suspend = pinctrl_suspend,
> + .resume = pinctrl_resume,
> +};
> +
> +#endif
(...)
> +#ifdef CONFIG_PM_SLEEP
> + register_syscore_ops(_syscore_ops);
> +#endif
So Stephen already commented that syscore ops is maybe too big
a sledgehammer for a fine-granular problem.
I mainly want to know what is happening above, it looks like
a state save/restore for all registers or something like this?
Yours,
Linus Walleij
--
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] Kbuild: Avoid DTB rebuilds if source files are untouched
On 04/03/2013 01:14 AM, Vineet Gupta wrote: > forgot to CC linux-arch > > On 04/03/2013 12:42 PM, Vineet Gupta wrote: >> Currently, for every ARC kernel build I see the following: >> >> --->8- >> DTBarch/arc/boot/dts/angel4.dtb.S >> AS arch/arc/boot/dts/angel4.dtb.o >> LD arch/arc/boot/dts/built-in.o >> rm arch/arc/boot/dts/angel4.dtb.S<-- forces rebuild next iter >> CHK kernel/config_data.h >> --->8- I assume that's because the file is an intermediate file, and only built due to a chain of build rules, and hence make clean it up itself after the build? >> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib >> +.PRECIOUS: $(obj)/%.dtb.S >> + >> $(obj)/%.dtb.S: $(obj)/%.dtb >> $(call cmd,dt_S_dtb) I'm not sure if .PRECIOUS is correct here. That prevents make from deleting the file if make is CTRL-C'd in the middle of generating it. Couldn't that leave a stale/corrupt file around that'd break the build. Judging by: http://www.gnu.org/software/make/manual/html_node/Special-Targets.html I think .SECONDARY might be a better choice? Does that solve the problem you're seeing? -- 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 bugfix 3.9] PCI: Don't try to disable Bus Master on disconnected PCI devices
[+cc linux-pci]
On Mon, Apr 1, 2013 at 2:00 AM, Konstantin Khlebnikov
wrote:
> BUMP. This is degradation from 3.8, so this patch must be in 3.9.
>
> I still don't like this forced clearing bus-master bit. But this hack
> definitely fixes problems in kexec, so there is reason to keep it here.
Applied to for-linus for v3.9, thanks!
> Konstantin Khlebnikov wrote:
>>
>> This is fix for commit 7897e6022761ace7377f0f784fca059da55f5d71 from
>> v3.9-rc1
>> ("PCI: Disable Bus Master unconditionally in pci_device_shutdown()")
>> in turn that was fix for b566a22c23327f18ce941ffad0ca907e50a53d41 from
>> v3.5-rc1
>> ("PCI: disable Bus Master on PCI device shutdown")
>>
>> Unfortunately fixing one bug uncovers another:
>> ->shutdown() callback might switch device to deep sleep state.
>> PCI config space no longer available after that.
>>
>> Link: https://lkml.org/lkml/2013/3/12/529
>> Signed-off-by: Konstantin Khlebnikov
>> Reported-and-Tested-by: Vivek Goyal
>> Cc: Bjorn Helgaas
>> Cc: Rafael J. Wysocki
>> ---
>> drivers/pci/pci-driver.c |5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
>> index 1fa1e48..79277fb 100644
>> --- a/drivers/pci/pci-driver.c
>> +++ b/drivers/pci/pci-driver.c
>> @@ -390,9 +390,10 @@ static void pci_device_shutdown(struct device *dev)
>>
>> /*
>> * Turn off Bus Master bit on the device to tell it to not
>> -* continue to do DMA
>> +* continue to do DMA. Don't touch devices in D3cold or unknown
>> states.
>> */
>> - pci_clear_master(pci_dev);
>> + if (pci_dev->current_state <= PCI_D3hot)
>> + pci_clear_master(pci_dev);
>> }
>>
>> #ifdef CONFIG_PM
>>
>
--
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 9/9] uretprobes: Documentation update
add the uretprobe syntax and update an example Signed-off-by: Anton Arapov --- Documentation/trace/uprobetracer.txt | 114 --- 1 file changed, 67 insertions(+), 47 deletions(-) diff --git a/Documentation/trace/uprobetracer.txt b/Documentation/trace/uprobetracer.txt index 24ce682..d9c3e68 100644 --- a/Documentation/trace/uprobetracer.txt +++ b/Documentation/trace/uprobetracer.txt @@ -1,6 +1,8 @@ - Uprobe-tracer: Uprobe-based Event Tracing - = - Documentation written by Srikar Dronamraju +Uprobe-tracer: Uprobe-based Event Tracing += + + Documentation written by Srikar Dronamraju + Overview @@ -13,78 +15,94 @@ current_tracer. Instead of that, add probe points via /sys/kernel/debug/tracing/events/uprobes//enabled. However unlike kprobe-event tracer, the uprobe event interface expects the -user to calculate the offset of the probepoint in the object +user to calculate the offset of the probepoint in the object. Synopsis of uprobe_tracer - - p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a probe + p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a uprobe + r[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a return uprobe (uretprobe) + -:[GRP/]EVENT : Clear uprobe or uretprobe event - GRP : Group name. If omitted, use "uprobes" for it. - EVENT : Event name. If omitted, the event name is generated - based on SYMBOL+offs. - PATH : path to an executable or a library. - SYMBOL[+offs] : Symbol+offset where the probe is inserted. + GRP : Group name. If omitted, "uprobes" is the default value. + EVENT : Event name. If omitted, the event name is generated based + on SYMBOL+offs. + PATH : Path to an executable or a library. + SYMBOL[+offs] : Symbol+offset where the probe is inserted. - FETCHARGS : Arguments. Each probe can have up to 128 args. - %REG : Fetch register REG + FETCHARGS : Arguments. Each probe can have up to 128 args. + %REG : Fetch register REG Event Profiling --- - You can check the total number of probe hits and probe miss-hits via +You can check the total number of probe hits and probe miss-hits via /sys/kernel/debug/tracing/uprobe_profile. - The first column is event name, the second is the number of probe hits, +The first column is event name, the second is the number of probe hits, the third is the number of probe miss-hits. Usage examples -- -To add a probe as a new event, write a new definition to uprobe_events -as below. + * Add a probe as a new uprobe event, write a new definition to uprobe_events +as below: (sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash) + +echo 'p: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events + + * Add a probe as a new uretprobe event: + +echo 'r: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events + + * Unset registered event: - echo 'p: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events +echo '-:bash_0x4245c0' >> /sys/kernel/debug/tracing/uprobe_events - This sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash + * Print out the events that are registered: - echo > /sys/kernel/debug/tracing/uprobe_events +cat /sys/kernel/debug/tracing/uprobe_events - This clears all probe points. + * Clear all events: -The following example shows how to dump the instruction pointer and %ax -a register at the probed text address. Here we are trying to probe -function zfree in /bin/zsh +echo > /sys/kernel/debug/tracing/uprobe_events + +Following example shows how to dump the instruction pointer and %ax register +at the probed text address. Probe zfree function in /bin/zsh: # cd /sys/kernel/debug/tracing/ -# cat /proc/`pgrep zsh`/maps | grep /bin/zsh | grep r-xp +# cat /proc/`pgrep zsh`/maps | grep /bin/zsh | grep r-xp 0040-0048a000 r-xp 08:03 130904 /bin/zsh # objdump -T /bin/zsh | grep -w zfree 00446420 gDF .text 0012 Basezfree -0x46420 is the offset of zfree in object /bin/zsh that is loaded at -0x0040. Hence the command to probe would be : + 0x46420 is the offset of zfree in object /bin/zsh that is loaded at + 0x0040. Hence the command to uprobe would be: + +# echo 'p:zfree_entry /bin/zsh:0x46420 %ip %ax' > uprobe_events + + And the same for the uretprobe would be: -# echo 'p /bin/zsh:0x46420 %ip %ax' > uprobe_events +# echo 'r:zfree_exit /bin/zsh:0x46420 %ip %ax' >> uprobe_events -Please note: User has to explicitly calculate the offset of the probepoint +Please note: User has to explicitly calculate the offset of the probe-point in
Re: [PATCHv2] rdma: add a new IB_ACCESS_GIFT flag
On Tue, Apr 02, 2013 at 08:05:21PM +0300, Michael S. Tsirkin wrote: > On Tue, Apr 02, 2013 at 09:57:38AM -0700, Roland Dreier wrote: > > On Tue, Apr 2, 2013 at 8:51 AM, Michael S. Tsirkin wrote: > > >> At the moment registering an MR breaks COW. This breaks memory > > >> overcommit for users such as KVM: we have a lot of COW pages, e.g. > > >> instances of the zero page or pages shared using KSM. > > >> > > >> If the application does not care that adapter sees stale data (for > > >> example, it tracks writes reregisters and resends), it can use a new > > >> IBV_ACCESS_GIFT flag to prevent registration from breaking COW. > > >> > > >> The semantics are similar to that of SPLICE_F_GIFT thus the name. > > >> > > >> Signed-off-by: Michael S. Tsirkin > > > > > > Roland, Michael is yet to test this but could you please > > > confirm whether this looks acceptable to you? > > > > The patch itself is reasonable I guess, given the needs of this particular > > app. > > > > I'm not particularly happy with the name of the flag. The analogy > > with SPLICE_F_GIFT doesn't seem particularly strong and I'm not > > convinced even the splice flag name is very understandable. But in > > the RDMA case there's not really any sense in which we're "gifting" > > memory to the adapter -- we're just telling the library "please don't > > trigger copy-on-write" and it doesn't seem particularly easy for users > > to understand that from the flag name. > > > > - R. > > The point really is that any writes by application > won't be seen until re-registration, right? > OK, what's a better name? IBV_ACCESS_NON_COHERENT? > Please tell me what is preferable and we'll go ahead with it. Um. ping? We are at -rc5 and things need to fall into place if we are to have it in 3.10 ... > -- > MST -- 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] sysfs: check if one entry has been removed before freeing
On Wed, Apr 03, 2013 at 03:05:37PM +0800, Ming Lei wrote:
> On Wed, Apr 3, 2013 at 1:35 PM, Greg Kroah-Hartman
> wrote:
> > On Wed, Apr 03, 2013 at 11:52:39AM +0800, Ming Lei wrote:
> >> On Wed, Apr 3, 2013 at 11:04 AM, Dave Jones wrote:
> >> > On Wed, Apr 03, 2013 at 10:58:23AM +0800, Ming Lei wrote:
> >> >
> >> > > diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
> >> > > index 1bf016b..328ef9b 100644
> >> > > --- a/fs/sysfs/dir.c
> >> > > +++ b/fs/sysfs/dir.c
> >> > > @@ -268,6 +268,13 @@ void release_sysfs_dirent(struct sysfs_dirent *
> >> > sd)
> >> > > */
> >> > > parent_sd = sd->s_parent;
> >> > >
> >> > > +if (unlikely(!(sd->s_flags & SYSFS_FLAG_REMOVED))) {
> >> > > +printk(KERN_ERR "sysfs: free using entry: %s/%s\n",
> >> > > +parent_sd ? parent_sd->s_name : "",
> >> > > +sd->s_name);
> >> > > +BUG();
> >> > > +}
> >> >
> >> > Please use WARN instead of BUG. For an in-ram filesystem like
> >> > sysfs, there's no real reason to lock-up the machine in this way
> >> > making it harder to debug.
> >>
> >> If WARN is used, the freed memory will be allocated to other
> >> kernel components, then sysfs may change the memory and cause
> >> destruction, so maybe it is better to use BUG to stop kernel.
> >
> > No, it's never ok to call BUG(), sorry, please fix this.
>
> Sorry, could you explain it in a bit detail? IMO, it is really a bug
> when code runs here, and there are much similar BUG_ON()
> uses in current sysfs code too.
Then make it a WARN() call, like David said, to give us a chance to get
the report from a user so we can fix it. If the machine crashes after
that, fine, but hopefully we will get a oops report out of it.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] watchdog: fix w83627hf_wdt clear timeout expired
On Wed, Apr 03, 2013 at 08:50:26AM -0700, Guenter Roeck wrote: > On Wed, Apr 03, 2013 at 08:06:59AM -0700, Tony Chung wrote: > > On Tue, Apr 2, 2013 at 9:21 PM, Guenter Roeck wrote: > > > > > > > > > > > What is the exact chip type in your system ? I want to have a look into > > > the > > > datasheet; maybe I can find out how it can trigger without causing a > > > reset. > > > > Winbond 83627HF chip > > Followup: what chip revision ? Revision G or later have a new configuration bit, bit 3 of CR E7 on logical device A. SELWDTORST. Watch Dog Timer Reset Control. = 0 is reset by LPC_RST. = 1 is reset by PWR_OK. I could imagine that the WDT logic is never correctly initialized in your system, which might explain the behavior. If so, your code is indeed correct (or the best I could come up with too), as we would have to ensure that the wdt subsystem is initialized correctly by writing into all its registers. Given that, I would suggest to re-submit the patch with a different explanation (we don't know if the wdt really started running, all we know is that the expired bit is set), and I'll give it an Acked-by. Something along the line of "Observed that the Watchdog Timer Status bit can be set when the driver is loaded. Reset it during initialization. The time-out value must be set to 0 explicitly in this case to prevent an immediate reset". Thanks, Guenter > > I believe BIOS has watchdog disabled otherwise it would have reboot the box. > > However, the timer just start counting. > > > > Comparing to ipmi_watchdog, you can do this: > > modprobe ipmi_watchdog ... start_now=0 ...action=<> nowayout=1 > > > > So it is possible to load the driver without start counting. > > > That is a different driver, though. you don't have the start_now option here. > > > Notice it is an else, so t is actually 0 already (i.e. expired or > > never start running): > > Still no idea why that would cause the system to reboot when you reset > the trigger without setting t to 0 again (or why the system doesn't reset > in the first place if the watchdog already triggered). > > I am not really sure what the best approach is here, so let's leave it > up to the maintainer to decide which way to go. > > Thanks, > Guenter > -- > To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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/9] uretprobes: Introduce uprobe_consumer->ret_handler()
Enclose return probes implementation, introduce ->ret_handler() and update
existing code to rely on ->handler() *and* ->ret_handler() for uprobe and
uretprobe respectively.
v1 changes:
* add bp_vaddr argument to ->ret_handler()
RFCv5 changes:
* don't remove uprobe in case there are no uprobe consumer(handler),
see handler_chain() changes.
RFCv3 changes: (the patch is introduced in v3)
* check whether at least one of the consumer's handlers were set.
* a 'TODO' cap that will be removed once return probes be implemented.
* introduce ->ret_handler().
Signed-off-by: Anton Arapov
---
include/linux/uprobes.h | 3 +++
kernel/events/uprobes.c | 17 ++---
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 02b83db..4042cad 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -46,6 +46,9 @@ enum uprobe_filter_ctx {
struct uprobe_consumer {
int (*handler)(struct uprobe_consumer *self, struct pt_regs *regs);
+ int (*ret_handler)(struct uprobe_consumer *self,
+ unsigned long func,
+ struct pt_regs *regs);
bool (*filter)(struct uprobe_consumer *self,
enum uprobe_filter_ctx ctx,
struct mm_struct *mm);
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 21d8a65..27c964b 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -815,6 +815,14 @@ int uprobe_register(struct inode *inode, loff_t offset,
struct uprobe_consumer *
struct uprobe *uprobe;
int ret;
+ /* Uprobe must have at least one set consumer */
+ if (!uc->handler && !uc->ret_handler)
+ return -EINVAL;
+
+ /* TODO: Implement return probes */
+ if (uc->ret_handler)
+ return -ENOSYS;
+
/* Racy, just to catch the obvious mistakes */
if (offset > i_size_read(inode))
return -EINVAL;
@@ -1473,10 +1481,13 @@ static void handler_chain(struct uprobe *uprobe, struct
pt_regs *regs)
down_read(>register_rwsem);
for (uc = uprobe->consumers; uc; uc = uc->next) {
- int rc = uc->handler(uc, regs);
+ int rc = 0;
- WARN(rc & ~UPROBE_HANDLER_MASK,
- "bad rc=0x%x from %pf()\n", rc, uc->handler);
+ if (uc->handler) {
+ rc = uc->handler(uc, regs);
+ WARN(rc & ~UPROBE_HANDLER_MASK,
+ "bad rc=0x%x from %pf()\n", rc, uc->handler);
+ }
remove &= rc;
}
--
1.8.1.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 v1 2/9] uretprobes: Reserve the first slot in xol_vma for trampoline
Allocate trampoline page, as the very first one in uprobed
task xol area, and fill it with breakpoint opcode.
Also introduce get_trampoline_vaddr() helper, to wrap the
trampoline address extraction from area->vaddr. That removes
confusion and eases the debug experience in case ->vaddr
notion will be changed.
v1 changes:
* rework get_trampoline_vaddr() helper.
* init xol_area->slot_count.
Signed-off-by: Anton Arapov
---
kernel/events/uprobes.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 27c964b..d3c8201 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1109,6 +1109,7 @@ static struct xol_area *get_xol_area(void)
{
struct mm_struct *mm = current->mm;
struct xol_area *area;
+ uprobe_opcode_t insn = UPROBE_SWBP_INSN;
area = mm->uprobes_state.xol_area;
if (area)
@@ -1126,7 +1127,12 @@ static struct xol_area *get_xol_area(void)
if (!area->page)
goto free_bitmap;
+ /* allocate first slot of task's xol_area for the return probes */
+ set_bit(0, area->bitmap);
+ copy_to_page(area->page, 0, , UPROBE_SWBP_INSN_SIZE);
+ atomic_set(>slot_count, 1);
init_waitqueue_head(>wq);
+
if (!xol_add_vma(area))
return area;
@@ -1323,6 +1329,25 @@ static struct uprobe_task *get_utask(void)
return current->utask;
}
+/*
+ * Current area->vaddr notion assume the trampoline address is always
+ * equal area->vaddr.
+ *
+ * Returns -1 in case the xol_area is not allocated.
+ */
+static unsigned long get_trampoline_vaddr(void)
+{
+ struct xol_area *area;
+ unsigned long trampoline_vaddr = -1;
+
+ area = current->mm->uprobes_state.xol_area;
+ smp_read_barrier_depends();
+ if (area)
+ trampoline_vaddr = area->vaddr;
+
+ return trampoline_vaddr;
+}
+
/* Prepare to single-step probed instruction out of line. */
static int
pre_ssout(struct uprobe *uprobe, struct pt_regs *regs, unsigned long bp_vaddr)
--
1.8.1.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 v1 0/9] uretprobes: Return uprobes implementation
Hello All! Uretprobes' core implementation. Enables a function's return probes in uprobe- based event tracing. Patchset introduce additional handler (ret_handler) in uprobe consumer that defines uretprobe. There is a regular uprobe with return probe handler behind every uretprobe. Once hit the uprobe that has ret_handler set, we hijack the return address of the probed function and replace it with the address of trampoline. Trampoline is a preallocated page in probed task's xol area that filled with breakpoint opcode. In turn, when the return breakpoint is hit, we invoke the ret_handler. The patchset shouldn't be difficult to read and hopefully the comments to commits will help. Please, review. patchset in git: http://github.com/arapov/linux-aa/commits/uretprobes_v1 previous versions: v0: https://lkml.org/lkml/2013/3/22/218 RFC reviews: RFCv4: https://lkml.org/lkml/2013/3/4/246 RFCv3: https://lkml.org/lkml/2013/2/28/148 RFCv2: https://lkml.org/lkml/2013/1/9/157 RFCv1: https://lkml.org/lkml/2012/12/21/133 thanks, Anton. Anton Arapov (9): uretprobes: Introduce uprobe_consumer->ret_handler() uretprobes: Reserve the first slot in xol_vma for trampoline uretprobes/x86: Hijack return address uretprobes/ppc: Hijack return address uretprobes: Return probe entry, prepare_uretprobe() uretprobes: Return probe exit, invoke handlers uretprobes: Limit the depth of return probe nestedness uretprobes: Remove -ENOSYS as return probes implemented uretprobes: Documentation update Documentation/trace/uprobetracer.txt | 126 +- arch/powerpc/include/asm/uprobes.h | 1 + arch/powerpc/kernel/uprobes.c| 13 +++ arch/x86/include/asm/uprobes.h | 1 + arch/x86/kernel/uprobes.c| 29 + include/linux/uprobes.h | 7 ++ kernel/events/uprobes.c | 202 +-- 7 files changed, 320 insertions(+), 59 deletions(-) -- 1.8.1.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 v1 6/9] uretprobes: Return probe exit, invoke handlers
Uretprobe handlers are invoked when the trampoline is hit, on completion the
trampoline is replaced with the saved return address and the uretprobe instance
deleted.
v1 changes:
* pass bp_vaddr to ret_handler()
* simplify handle_uretprobe()
RFCv6 changes:
* rework handle_uretprobe()
RFCv5 changes:
* switch to simply linked list ->return_uprobes
* rework handle_uretprobe()
RFCv4 changes:
* check, whether utask is not NULL in handle_uretprobe()
* get rid of area->rp_trampoline_vaddr
* minor handle_uretprobe() fixups
RFCv3 changes:
* protected uprobe with refcounter. See put_uprobe() in handle_uretprobe()
that reflects increment in prepare_uretprobe()
RFCv2 changes:
* get rid of ->return_consumers member from struct uprobe, introduce
ret_handler() in consumer instead
Signed-off-by: Anton Arapov
---
kernel/events/uprobes.c | 60 -
1 file changed, 59 insertions(+), 1 deletion(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 08ecfff..d129c1d 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1609,6 +1609,57 @@ static void handler_chain(struct uprobe *uprobe, struct
pt_regs *regs)
up_read(>register_rwsem);
}
+static void
+handler_uretprobe_chain(struct return_instance *ri, struct pt_regs *regs)
+{
+ struct uprobe *uprobe = ri->uprobe;
+ struct uprobe_consumer *uc;
+
+ down_read(>register_rwsem);
+ for (uc = uprobe->consumers; uc; uc = uc->next) {
+ if (uc->ret_handler)
+ uc->ret_handler(uc, ri->func, regs);
+ }
+ up_read(>register_rwsem);
+}
+
+static bool handler_uretprobe(struct pt_regs *regs)
+{
+ struct uprobe_task *utask;
+ struct return_instance *ri, *tmp;
+ bool chained;
+
+ utask = current->utask;
+ if (!utask)
+ return false;
+
+ ri = utask->return_instances;
+ if (!ri)
+ return false;
+
+ instruction_pointer_set(regs, ri->orig_ret_vaddr);
+
+ for (;;) {
+ handler_uretprobe_chain(ri, regs);
+
+ chained = ri->chained;
+ put_uprobe(ri->uprobe);
+
+ tmp = ri;
+ ri = ri->next;
+ kfree(tmp);
+
+ if (!chained)
+ break;
+
+ BUG_ON(!ri);
+ }
+
+ utask->return_instances = ri;
+
+ return true;
+}
+
/*
* Run handler and ask thread to singlestep.
* Ensure all non-fatal signals cannot interrupt thread while it singlesteps.
@@ -1620,8 +1671,15 @@ static void handle_swbp(struct pt_regs *regs)
int uninitialized_var(is_swbp);
bp_vaddr = uprobe_get_swbp_addr(regs);
- uprobe = find_active_uprobe(bp_vaddr, _swbp);
+ if (bp_vaddr == get_trampoline_vaddr()) {
+ if (handler_uretprobe(regs))
+ return;
+ pr_warn("uprobe: unable to handle uretprobe pid/tgid=%d/%d\n",
+ current->pid, current->tgid);
+ }
+
+ uprobe = find_active_uprobe(bp_vaddr, _swbp);
if (!uprobe) {
if (is_swbp > 0) {
/* No matching uprobe; signal SIGTRAP. */
--
1.8.1.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 v1 7/9] uretprobes: Limit the depth of return probe nestedness
Unlike the kretprobes we can't trust userspace, thus must have
protection from user space attacks. User-space have "unlimited"
stack, and this patch limits the return probes nestedness as a
simple remedy for it.
Note that this implementation leaks return_instance on siglongjmp
until exit()/exec().
The intention is to have KISS and bare minimum solution for the
initial implementation in order to not complicate the uretprobes
code.
In the future we may come up with more sophisticated solution that
remove this depth limitation. It is not easy task and lays beyond
this patchset.
Signed-off-by: Anton Arapov
---
include/linux/uprobes.h | 3 +++
kernel/events/uprobes.c | 11 +++
2 files changed, 14 insertions(+)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 5f8960e..d7bcf10 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -38,6 +38,8 @@ struct inode;
#define UPROBE_HANDLER_REMOVE 1
#define UPROBE_HANDLER_MASK1
+#define MAX_URETPROBE_DEPTH64
+
enum uprobe_filter_ctx {
UPROBE_FILTER_REGISTER,
UPROBE_FILTER_UNREGISTER,
@@ -72,6 +74,7 @@ struct uprobe_task {
struct arch_uprobe_task autask;
struct return_instance *return_instances;
+ unsigned intdepth;
struct uprobe *active_uprobe;
unsigned long xol_vaddr;
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index d129c1d..489f5e3 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1381,6 +1381,13 @@ static void prepare_uretprobe(struct uprobe *uprobe,
struct pt_regs *regs)
if (!utask)
return;
+ if (utask->depth >= MAX_URETPROBE_DEPTH) {
+ printk_ratelimited(KERN_INFO "uprobe: omit uretprobe due to"
+ " nestedness limit pid/tgid=%d/%d\n",
+ current->pid, current->tgid);
+ return;
+ }
+
ri = kzalloc(sizeof(struct return_instance), GFP_KERNEL);
if (!ri)
goto fail;
@@ -1416,6 +1423,8 @@ static void prepare_uretprobe(struct uprobe *uprobe,
struct pt_regs *regs)
ri->orig_ret_vaddr = orig_ret_vaddr;
ri->chained = chained;
+ utask->depth++;
+
/* add instance to the stack */
ri->next = utask->return_instances;
utask->return_instances = ri;
@@ -1652,6 +1661,8 @@ static bool handler_uretprobe(struct pt_regs *regs)
if (!chained)
break;
+ utask->depth--;
+
BUG_ON(!ri);
}
--
1.8.1.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 v1 8/9] uretprobes: Remove -ENOSYS as return probes implemented
Enclose return probes implementation. Signed-off-by: Anton Arapov --- kernel/events/uprobes.c | 4 1 file changed, 4 deletions(-) diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index 489f5e3..9af52f7 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -828,10 +828,6 @@ int uprobe_register(struct inode *inode, loff_t offset, struct uprobe_consumer * if (!uc->handler && !uc->ret_handler) return -EINVAL; - /* TODO: Implement return probes */ - if (uc->ret_handler) - return -ENOSYS; - /* Racy, just to catch the obvious mistakes */ if (offset > i_size_read(inode)) return -EINVAL; -- 1.8.1.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 v1 4/9] uretprobes/ppc: Hijack return address
Hijack the return address and replace it with a trampoline address.
PowerPC implementation.
Signed-off-by: Anton Arapov
---
arch/powerpc/include/asm/uprobes.h | 1 +
arch/powerpc/kernel/uprobes.c | 13 +
2 files changed, 14 insertions(+)
diff --git a/arch/powerpc/include/asm/uprobes.h
b/arch/powerpc/include/asm/uprobes.h
index b532060..2301602 100644
--- a/arch/powerpc/include/asm/uprobes.h
+++ b/arch/powerpc/include/asm/uprobes.h
@@ -51,4 +51,5 @@ extern int arch_uprobe_post_xol(struct arch_uprobe *aup,
struct pt_regs *regs);
extern bool arch_uprobe_xol_was_trapped(struct task_struct *tsk);
extern int arch_uprobe_exception_notify(struct notifier_block *self, unsigned
long val, void *data);
extern void arch_uprobe_abort_xol(struct arch_uprobe *aup, struct pt_regs
*regs);
+extern unsigned long arch_uretprobe_hijack_return_addr(unsigned long
trampoline_vaddr, struct pt_regs *regs);
#endif /* _ASM_UPROBES_H */
diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
index bc77834..567b975 100644
--- a/arch/powerpc/kernel/uprobes.c
+++ b/arch/powerpc/kernel/uprobes.c
@@ -188,3 +188,16 @@ bool arch_uprobe_skip_sstep(struct arch_uprobe *auprobe,
struct pt_regs *regs)
return false;
}
+
+unsigned long
+arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr, struct
pt_regs *regs)
+{
+ unsigned long orig_ret_vaddr;
+
+ orig_ret_vaddr = regs->link;
+
+ /* Replace the return addr with trampoline addr */
+ regs->link = trampoline_vaddr;
+
+ return orig_ret_vaddr;
+}
--
1.8.1.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 v1 5/9] uretprobes: Return probe entry, prepare_uretprobe()
When a uprobe with return probe consumer is hit, prepare_uretprobe()
function is invoked. It creates return_instance, hijacks return address
and replaces it with the trampoline.
* Return instances are kept as stack per uprobed task.
* Return instance is chained, when the original return address is
trampoline's page vaddr (e.g. recursive call of the probed function).
v1 changes:
* preserve address of the breakpoint in return_instance.
* don't forget NULLify return_instances on free_utask.
* simplify prepare_uretprobe().
RFCv6 changes:
* rework prepare_uretprobe() logic in order to make further unwinding
in handler_uretprobe() simplier.
* introduce the 'dirty' field.
RFCv5 changes:
* switch from hlist to simply linked list for tracking ->*return_uprobes.
* preallocate first slot xol_area for return probes, see xol_get_area()
changes.
* add get_trampoline_vaddr() helper, to emphasize area->vaddr overload.
RFCv4 changes:
* get rid of area->rp_trampoline_vaddr as it always the same as ->vaddr.
* cleanup ->return_uprobes list in uprobe_free_utask(), because the
task can exit from inside the ret-probe'd function(s).
* in find_active_uprobe(): Once we inserted "int3" we must ensure that
handle_swbp() will be called even if this uprobe goes away. We have
the reference but it only protects uprobe itself, it can't protect
agains delete_uprobe().
IOW, we must ensure that uprobe_pre_sstep_notifier() can't return 0.
RFCv3 changes:
* protected uprobe with refcounter. See atomic_inc in prepare_uretprobe()
and put_uprobe() in a following patch in handle_uretprobe().
RFCv2 changes:
* get rid of ->return_consumers member from struct uprobe, introduce
ret_handler() in consumer.
Signed-off-by: Anton Arapov
---
include/linux/uprobes.h | 1 +
kernel/events/uprobes.c | 92 -
2 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 4042cad..5f8960e 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -71,6 +71,7 @@ struct uprobe_task {
enum uprobe_task_state state;
struct arch_uprobe_task autask;
+ struct return_instance *return_instances;
struct uprobe *active_uprobe;
unsigned long xol_vaddr;
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index d3c8201..08ecfff 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -75,6 +75,15 @@ struct uprobe {
struct arch_uprobe arch;
};
+struct return_instance {
+ struct uprobe *uprobe;
+ unsigned long func;
+ unsigned long orig_ret_vaddr; /* original return address */
+ boolchained;/* true, if instance is nested
*/
+
+ struct return_instance *next; /* keep as stack */
+};
+
/*
* valid_vma: Verify if the specified vma is an executable vma
* Relax restrictions while unregistering: vm_flags might have
@@ -1294,6 +1303,7 @@ unsigned long __weak uprobe_get_swbp_addr(struct pt_regs
*regs)
void uprobe_free_utask(struct task_struct *t)
{
struct uprobe_task *utask = t->utask;
+ struct return_instance *ri, *tmp;
if (!utask)
return;
@@ -1301,6 +1311,15 @@ void uprobe_free_utask(struct task_struct *t)
if (utask->active_uprobe)
put_uprobe(utask->active_uprobe);
+ ri = utask->return_instances;
+ while (ri) {
+ tmp = ri;
+ ri = ri->next;
+
+ put_uprobe(tmp->uprobe);
+ kfree(tmp);
+ }
+
xol_free_insn_slot(t);
kfree(utask);
t->utask = NULL;
@@ -1348,6 +1367,65 @@ static unsigned long get_trampoline_vaddr(void)
return trampoline_vaddr;
}
+static void prepare_uretprobe(struct uprobe *uprobe, struct pt_regs *regs)
+{
+ struct return_instance *ri;
+ struct uprobe_task *utask;
+ unsigned long orig_ret_vaddr, trampoline_vaddr;
+ bool chained = false;
+
+ if (!get_xol_area())
+ return;
+
+ utask = get_utask();
+ if (!utask)
+ return;
+
+ ri = kzalloc(sizeof(struct return_instance), GFP_KERNEL);
+ if (!ri)
+ goto fail;
+
+ trampoline_vaddr = get_trampoline_vaddr();
+ orig_ret_vaddr = arch_uretprobe_hijack_return_addr(trampoline_vaddr,
regs);
+ if (orig_ret_vaddr == -1)
+ goto fail;
+
+ /*
+* We don't want to keep trampoline address in stack, rather keep the
+* original return address of first caller thru all the consequent
+* instances. This also makes breakpoint unwrapping easier.
+*/
+ if (orig_ret_vaddr == trampoline_vaddr) {
+ if (!utask->return_instances) {
+ /*
+* This situation is not possible.
Re: [PATCH] xen: drop tracking of IRQ vector
On Wed, 3 Apr 2013, Jan Beulich wrote:
> For quite a few Xen versions, this wasn't the IRQ vector anymore
> anyway, and it is not being used by the kernel for anything. Hence
> drop the field from struct irq_info, and respective function
> parameters.
>
> Signed-off-by: Jan Beulich
> Cc: Stefano Stabellini
Acked-by: Stefano Stabellini
> ---
> arch/x86/pci/xen.c |6 +++---
> drivers/xen/events.c | 13 -
> include/xen/events.h |3 +--
> 3 files changed, 8 insertions(+), 14 deletions(-)
>
> --- 3.9-rc5/arch/x86/pci/xen.c
> +++ 3.9-rc5-xen-irq-no-vector/arch/x86/pci/xen.c
> @@ -177,7 +177,7 @@ static int xen_setup_msi_irqs(struct pci
> goto error;
> i = 0;
> list_for_each_entry(msidesc, >msi_list, list) {
> - irq = xen_bind_pirq_msi_to_irq(dev, msidesc, v[i], 0,
> + irq = xen_bind_pirq_msi_to_irq(dev, msidesc, v[i],
> (type == PCI_CAP_ID_MSIX) ?
> "pcifront-msi-x" :
> "pcifront-msi",
> @@ -244,7 +244,7 @@ static int xen_hvm_setup_msi_irqs(struct
> dev_dbg(>dev,
> "xen: msi already bound to pirq=%d\n", pirq);
> }
> - irq = xen_bind_pirq_msi_to_irq(dev, msidesc, pirq, 0,
> + irq = xen_bind_pirq_msi_to_irq(dev, msidesc, pirq,
> (type == PCI_CAP_ID_MSIX) ?
> "msi-x" : "msi",
> DOMID_SELF);
> @@ -326,7 +326,7 @@ static int xen_initdom_setup_msi_irqs(st
> }
>
> ret = xen_bind_pirq_msi_to_irq(dev, msidesc,
> -map_irq.pirq, map_irq.index,
> +map_irq.pirq,
> (type == PCI_CAP_ID_MSIX) ?
> "msi-x" : "msi",
> domid);
> --- 3.9-rc5/drivers/xen/events.c
> +++ 3.9-rc5-xen-irq-no-vector/drivers/xen/events.c
> @@ -85,8 +85,7 @@ enum xen_irq_type {
> * event channel - irq->event channel mapping
> * cpu - cpu this event channel is bound to
> * index - type-specific information:
> - *PIRQ - vector, with MSB being "needs EIO", or physical IRQ of the HVM
> - * guest, or GSI (real passthrough IRQ) of the device.
> + *PIRQ - physical IRQ, GSI, flags, and owner domain
> *VIRQ - virq number
> *IPI - IPI vector
> *EVTCHN -
> @@ -105,7 +104,6 @@ struct irq_info {
> struct {
> unsigned short pirq;
> unsigned short gsi;
> - unsigned char vector;
> unsigned char flags;
> uint16_t domid;
> } pirq;
> @@ -211,7 +209,6 @@ static void xen_irq_info_pirq_init(unsig
> unsigned short evtchn,
> unsigned short pirq,
> unsigned short gsi,
> -unsigned short vector,
> uint16_t domid,
> unsigned char flags)
> {
> @@ -221,7 +218,6 @@ static void xen_irq_info_pirq_init(unsig
>
> info->u.pirq.pirq = pirq;
> info->u.pirq.gsi = gsi;
> - info->u.pirq.vector = vector;
> info->u.pirq.domid = domid;
> info->u.pirq.flags = flags;
> }
> @@ -714,7 +710,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gs
> goto out;
> }
>
> - xen_irq_info_pirq_init(irq, 0, pirq, gsi, irq_op.vector, DOMID_SELF,
> + xen_irq_info_pirq_init(irq, 0, pirq, gsi, DOMID_SELF,
> shareable ? PIRQ_SHAREABLE : 0);
>
> pirq_query_unmask(irq);
> @@ -762,8 +758,7 @@ int xen_allocate_pirq_msi(struct pci_dev
> }
>
> int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc,
> - int pirq, int vector, const char *name,
> - domid_t domid)
> + int pirq, const char *name, domid_t domid)
> {
> int irq, ret;
>
> @@ -776,7 +771,7 @@ int xen_bind_pirq_msi_to_irq(struct pci_
> irq_set_chip_and_handler_name(irq, _pirq_chip, handle_edge_irq,
> name);
>
> - xen_irq_info_pirq_init(irq, 0, pirq, 0, vector, domid, 0);
> + xen_irq_info_pirq_init(irq, 0, pirq, 0, domid, 0);
> ret = irq_set_msi_desc(irq, msidesc);
> if (ret < 0)
> goto error_irq;
> --- 3.9-rc5/include/xen/events.h
> +++ 3.9-rc5-xen-irq-no-vector/include/xen/events.h
> @@ -90,8 +90,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gs
> int xen_allocate_pirq_msi(struct pci_dev *dev, struct msi_desc *msidesc);
> /* Bind an PSI pirq to an irq. */
> int
[PATCH v1 3/9] uretprobes/x86: Hijack return address
Hijack the return address and replace it with a trampoline address.
v1 changes:
* use force_sig_info()
* rework and simplify logic
RFCv5 changes:
* change the fail return code, because orig_ret_vaddr=0 is possible
* style fixup
RFCv2 changes:
* remove ->doomed flag, kill task immediately
Signed-off-by: Anton Arapov
---
arch/x86/include/asm/uprobes.h | 1 +
arch/x86/kernel/uprobes.c | 29 +
2 files changed, 30 insertions(+)
diff --git a/arch/x86/include/asm/uprobes.h b/arch/x86/include/asm/uprobes.h
index 8ff8be7..6e51979 100644
--- a/arch/x86/include/asm/uprobes.h
+++ b/arch/x86/include/asm/uprobes.h
@@ -55,4 +55,5 @@ extern int arch_uprobe_post_xol(struct arch_uprobe *aup,
struct pt_regs *regs);
extern bool arch_uprobe_xol_was_trapped(struct task_struct *tsk);
extern int arch_uprobe_exception_notify(struct notifier_block *self, unsigned
long val, void *data);
extern void arch_uprobe_abort_xol(struct arch_uprobe *aup, struct pt_regs
*regs);
+extern unsigned long arch_uretprobe_hijack_return_addr(unsigned long
trampoline_vaddr, struct pt_regs *regs);
#endif /* _ASM_UPROBES_H */
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 0ba4cfb..2ed8459 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -697,3 +697,32 @@ bool arch_uprobe_skip_sstep(struct arch_uprobe *auprobe,
struct pt_regs *regs)
send_sig(SIGTRAP, current, 0);
return ret;
}
+
+unsigned long
+arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr, struct
pt_regs *regs)
+{
+ int rasize, ncopied;
+ unsigned long orig_ret_vaddr = 0; /* clear high bits for 32-bit apps */
+
+ rasize = is_ia32_task() ? 4 : 8;
+ ncopied = copy_from_user(_ret_vaddr, (void __user *)regs->sp,
rasize);
+ if (unlikely(ncopied))
+ return -1;
+
+ /* check whether address has been already hijacked */
+ if (orig_ret_vaddr == trampoline_vaddr)
+ return orig_ret_vaddr;
+
+ ncopied = copy_to_user((void __user *)regs->sp, _vaddr,
rasize);
+ if (likely(!ncopied))
+ return orig_ret_vaddr;
+
+ if (ncopied != rasize) {
+ pr_err("uprobe: return address clobbered: pid=%d, %%sp=%#lx, "
+ "%%ip=%#lx\n", current->pid, regs->sp, regs->ip);
+
+ force_sig_info(SIGSEGV, SEND_SIG_FORCED, current);
+ }
+
+ return -1;
+}
--
1.8.1.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: [ 34/77] xen/blkback: Dont trust the handle from the frontend.
On Wed, Apr 03, 2013 at 04:01:54PM +0200, William Dauchy wrote: > On Tue, Mar 12, 2013 at 11:10 PM, Greg Kroah-Hartman > wrote: > >> > >> IOW I don't see why this got proposed for stable at all. > >> > > > >> > > So, you suggest to just drop this patch for v3.8.3, don't you? > >> > > >> > I do, yes. But I'd suggest to get Konrad to agree. > >> > >> Yes. Lets drop it. > > > > Now reverted, thanks. > > Seems like still present in 3.4.x branch. Is that a mistake? It showed up in 3.4.35, if that's a mistake, and I should revert it, please, someone let me know. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
> -Original Message-
> From: Sethi Varun-B16395
> Sent: Wednesday, April 03, 2013 12:12 AM
> To: Wood Scott-B07421; Timur Tabi
> Cc: Joerg Roedel; lkml; Kumar Gala; Yoder Stuart-B08248;
> io...@lists.linux-foundation.org; Benjamin
> Herrenschmidt; linuxppc-...@lists.ozlabs.org
> Subject: RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu
> implementation.
>
>
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, April 03, 2013 7:23 AM
> > To: Timur Tabi
> > Cc: Joerg Roedel; Sethi Varun-B16395; lkml; Kumar Gala; Yoder Stuart-
> > B08248; io...@lists.linux-foundation.org; Benjamin Herrenschmidt;
> > linuxppc-...@lists.ozlabs.org
> > Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu
> > implementation.
> >
> > On 04/02/2013 08:35:54 PM, Timur Tabi wrote:
> > > On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel wrote:
> > >
> > > > > + panic("\n");
> > > >
> > > > A kernel panic seems like an over-reaction to an access violation.
> > >
> > > We have no way to determining what code caused the violation, so we
> > > can't just kill the process. I agree it seems like overkill, but what
> > > else should we do? Does the IOMMU layer have a way for the IOMMU
> > > driver to stop the device that caused the problem?
> >
> > At a minimum, log a message and continue. Probably turn off the LIODN,
> > at least if it continues to be noisy (otherwise we could get stuck in an
> > interrupt storm as you note). Possibly let the user know somehow,
> > especially if it's a VFIO domain.
> [Sethi Varun-B16395] Can definitely log the message and disable the LIODN (to
> avoid an interrupt storm),
> but
> we definitely need a mechanism to inform vfio subsystem about the error.
> Also, disabling LIODN may not
> be a viable
> option with the new LIODN allocation scheme (where LIODN would be associated
> with a domain).
I think for phase 1 of this, just log the error, shut down DMA as you described.
We can implement more full featured error management, like notifying vfio
or the VM somehow in the future.
Stuart
--
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 2/2] watchdog: fix w83627hf_wdt clear timeout expired
On Wed, Apr 03, 2013 at 08:06:59AM -0700, Tony Chung wrote: > On Tue, Apr 2, 2013 at 9:21 PM, Guenter Roeck wrote: > > > > > > > What is the exact chip type in your system ? I want to have a look into the > > datasheet; maybe I can find out how it can trigger without causing a reset. > > Winbond 83627HF chip > > I believe BIOS has watchdog disabled otherwise it would have reboot the box. > However, the timer just start counting. > > Comparing to ipmi_watchdog, you can do this: > modprobe ipmi_watchdog ... start_now=0 ...action=<> nowayout=1 > > So it is possible to load the driver without start counting. > That is a different driver, though. you don't have the start_now option here. > Notice it is an else, so t is actually 0 already (i.e. expired or > never start running): Still no idea why that would cause the system to reboot when you reset the trigger without setting t to 0 again (or why the system doesn't reset in the first place if the watchdog already triggered). I am not really sure what the best approach is here, so let's leave it up to the maintainer to decide which way to go. Thanks, Guenter -- 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 2/6] usb: phy: omap-usb2: use the new generic PHY framework
Hi,
On Wed, Apr 03, 2013 at 02:55:47PM +, Arnd Bergmann wrote:
> On Wednesday 03 April 2013, Felipe Balbi wrote:
> > const ? Maybe provide a:
> >
> > #define DEFINE_PHY_OPS(name)\
> > const struct phy_ops #name_phy_ops = {
> >
> > macro ? This will force people to add the const keyword :-)
>
> Forcing people to use const structures is good, but I think it would be
> better without the macro, just by marking the argument in
> devm_phy_create() as const.
that won't force the definition of the struct to be const, however. But
I get your point.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v5 1/6] drivers: phy: add generic PHY framework
Hi, On Wed, Apr 03, 2013 at 08:02:52PM +0530, Kishon Vijay Abraham I wrote: > + ret = -EINVAL; > + goto err0; > + } > + > + if (!phy_class) > + phy_core_init(); > >>> > >>>why don't you setup the class on module_init ? Then this would be a > >>>terrible error condition here :-) > >> > >>This is for the case where the PHY driver gets loaded before the PHY > >>framework. I could have returned EPROBE_DEFER here instead I thought > >>will have it this way. > > > >looks a bit weird IMO. Is it really possible for PHY to load before ? > > yeah. it actually happened when I tried with beagle and had all the > modules as built-in. Because twl4030 has subsys_initcall(), it loads > before PHY framework. that's a bug in twl4030. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/3] check regulator_enable() return value
Hi, On Wed, Apr 03, 2013 at 07:22:38AM -0700, Greg KH wrote: > On Wed, Apr 03, 2013 at 05:06:22PM +0300, Felipe Balbi wrote: > > Hi, > > > > On Wed, Apr 03, 2013 at 04:02:24PM +0200, Fabio Baltieri wrote: > > > While testing your 'next' branch merged with today's next I got some new > > > warnings, caused by a recently introduced __must_check in: > > > > > > c8801a8 regulator: core: Mark all get and enable calls as __must_check > > > > > > These patches introduces a check for regulator_enable() return value in > > > all three affected USB phy drivers, and issue a dev_err() in case it > > > fails. > > > > > > TWL4030 and TWL6030 patches has been build-tested only. > > > > Sorry but I can't change my tree anymore, we can send these during > > v3.10-rc. > > Really? You are going to send me a tree that adds build warnings? > > Please don't. alright, I'll merge these in. -- balbi signature.asc Description: Digital signature
Re: Loopback device hung [was Re: xfs deadlock on 3.9-rc5 running xfstests case #78]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/3/2013 7:41 AM, Jens Axboe wrote: >> Thanks for testing! I don't particularly like this stuff in >> loop, though. It's quite nasty and depends on other behaviour. It >> would be prettier if we just had rescan_partitions() do the right >> thing, and only drop partitions and not rescan if NO_PART_SCAN is >> set. >> >> Ala the below, dropping the loop change and implementing that >> change in the core code. Phillip, can you check whether this does >> the right thing for your bug too? > > Phillip? I'm going to revert the loop change asap, so if you want > this fixed for 3.10, it's about that time to test it out. I have not tested it yet, but I am pretty sure it won't work. It looks like the patch changes the BLKRRPART path to go ahead and remove existing partitions when GENHD_FL_NO_PARTSCAN is set. loop doesn't issue the BLKRRPART ioctl when !LO_FLAGS_PARTSCAN so this won't help. I think loop needs to set GENHD_FL_NO_PARTSCAN and then issue the ioctl regardless of the LO_FLAGS_PARTSCAN flag to get the partitions to be removed. I will try to test tonight. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRXE2dAAoJEJrBOlT6nu75PM0IAIxVmuHdxLPtdtUNPqkU2a1r QanHb6F43qSbd7l37XlwYgzUlybVlntf1yvKGzh29g3QM0603sFqV1o+mbXd5LI3 b+I5QrQJh90Vou9oVSAxz1Ps/AlZvxVIDv8bRwNhpXcMmaj0EN5R+6pU5L7KU2BU GFsvajssedFh3XnNskgkR3XlqevI7U7A8VqLRsswl7FJVu7R1s45xP/sQgBWgiUS P5viykwhje4OTKmu0D7bFKrOVx6O3gK7IHzdOwwT9aWRxuxL+Y9yfBF9nx/xZXkc I2G09w852KgYDVYUHgW3IfuRo4F+4Y7Mw0Klu4XX5OmEXhselIqhwwTmEKMvEns= =OLri -END PGP SIGNATURE- -- 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-3.9.0-rc1+: Output from "make kernelrelease"contains incorrect data
On 04/03/13 15:32, Michal Marek wrote: On 1.4.2013 11:28, Chris Clayton wrote: Ping! This is still happening with 3.9-rc5. [chris:~/kernel/linux]$ make bzImage ... Kernel: arch/x86/boot/bzImage is ready (#14) [chris:~/kernel/linux]$ make kernelrelease scripts/kconfig/conf --silentoldconfig Kconfig 3.9.0-rc5 [chris:~/kernel/linux]$ make kernelrelease 3.9.0-rc5 You need to run make -s kernelrelease. Ah, right. I didn't see that announcement. The -s argument was not necessary with earlier releases. Sorry for the noise. Chris Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 105/124] af_unix: dont send SCM_CREDENTIAL when dest socket is NULL
On Wed, 2013-04-03 at 17:10 +0200, Sven Joachim wrote: > On 2013-04-03 16:00 +0200, Eric Dumazet wrote: > > > It might be a wrong sender (application bug or bad identity), and udevd > > correctly discards the incoming message. > > How would I find out the culprit? Change udevd to display the pid as well, and hopefully track the sender. udevd receives uid and pid in the credentials. -- 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] cpufreq: convert the cpufreq_driver to use the rcu
Please always mention Version number and history. Not everybody
remembers what changed after last version.
On 3 April 2013 20:33, Nathan Zimmer wrote:
> We eventually would like to remove the rwlock cpufreq_driver_lock or convert
> it back to a spinlock and protect the read sections with RCU. The first step
> in
Why do we want to convert it back to spinlock?
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> bool have_governor_per_policy(void)
> {
> - return cpufreq_driver->have_governor_per_policy;
> + bool have_governor;
Name it have_governor_per_policy, it looks wrong otherwise.
> + rcu_read_lock();
> + have_governor =
> rcu_dereference(cpufreq_driver)->have_governor_per_policy;
> + rcu_read_unlock();
> + return have_governor;
> }
> static ssize_t show_scaling_driver(struct cpufreq_policy *policy, char *buf)
> {
> - return scnprintf(buf, CPUFREQ_NAME_PLEN, "%s\n",
> cpufreq_driver->name);
> + char *name;
> + rcu_read_lock();
> + name = rcu_dereference(cpufreq_driver)->name;
> + rcu_read_unlock();
> + return scnprintf(buf, CPUFREQ_NAME_PLEN, "%s\n", name);
> }
This is the definition of struct cpufreq_driver:
struct cpufreq_driver {
struct module *owner;
charname[CPUFREQ_NAME_LEN];
...
};
Purpose of rcu read_lock/unlock are to define the rcu critical section
after which rcu layer is free to free the memory allocated to earlier
instance of cpufreq_driver.
So, after the unlock() call you _should_not_ use the memory allocated to
cpufreq_driver instance. And here, you are using memory allocated to name[]
after the unlock() call.
Which looks to be wrong... I left other parts of driver upto you to fix for this
"rule of thumb".
Sorry for not pointing this earlier but rcu is as new to me as it is
to you. I know
you must be frustrated with so many versions of this patch, and everytime we
get a new problem to you... Don't get disheartened with it.. Keep the good work
going :)
--
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/
Re: [RFC][PATCH 2/7] memcg: don't use mem_cgroup_get() when creating a kmemcg cache
On Wed 03-04-13 17:12:21, Li Zefan wrote:
> Use css_get()/css_put() instead of mem_cgroup_get()/mem_cgroup_put().
>
> Signed-off-by: Li Zefan
> ---
> mm/memcontrol.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 43ca91d..dafacb8 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3191,7 +3191,7 @@ void memcg_release_cache(struct kmem_cache *s)
> list_del(>memcg_params->list);
> mutex_unlock(>slab_caches_mutex);
>
> - mem_cgroup_put(memcg);
> + css_put(>css);
> out:
> kfree(s->memcg_params);
> }
> @@ -3350,16 +3350,18 @@ static struct kmem_cache
> *memcg_create_kmem_cache(struct mem_cgroup *memcg,
>
> mutex_lock(_cache_mutex);
> new_cachep = cachep->memcg_params->memcg_caches[idx];
> - if (new_cachep)
> + if (new_cachep) {
> + css_put(>css);
> goto out;
> + }
>
> new_cachep = kmem_cache_dup(memcg, cachep);
> if (new_cachep == NULL) {
> new_cachep = cachep;
> + css_put(>css);
> goto out;
> }
>
> - mem_cgroup_get(memcg);
> atomic_set(_cachep->memcg_params->nr_pages , 0);
>
> cachep->memcg_params->memcg_caches[idx] = new_cachep;
> @@ -3449,8 +3451,6 @@ static void memcg_create_cache_work_func(struct
> work_struct *w)
>
> cw = container_of(w, struct create_work, work);
> memcg_create_kmem_cache(cw->memcg, cw->cachep);
> - /* Drop the reference gotten when we enqueued. */
> - css_put(>memcg->css);
> kfree(cw);
> }
You are putting references but I do not see any single css_{try}get
here. /me puzzled.
--
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/
[PATCH] block: avoid using uninitialized value in from queue_var_store
As found by gcc-4.8, the QUEUE_SYSFS_BIT_FNS macro creates functions that use a value generated by queue_var_store independent of whether that value was set or not. block/blk-sysfs.c: In function 'queue_store_nonrot': block/blk-sysfs.c:244:385: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized] Unlike most other such warnings, this one is not a false positive, writing any non-number string into the sysfs files indeed has an undefined result, rather than returning an error. Signed-off-by: Arnd Bergmann Cc: Jens Axboe --- diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c index 6206a93..5efc5a6 100644 --- a/block/blk-sysfs.c +++ b/block/blk-sysfs.c @@ -229,6 +229,8 @@ queue_store_##name(struct request_queue *q, const char *page, size_t count) \ unsigned long val; \ ssize_t ret;\ ret = queue_var_store(, page, count); \ + if (ret < 0)\ +return ret;\ if (neg)\ val = !val; \ \ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] watchdog: Add Congatec CGEB watchdog driver
On Wed, Apr 03, 2013 at 05:09:52PM +0200, Sascha Hauer wrote: [ ... ] > > > > On a side note, if the driver supports devicetree, it might make sense to > > call > > watchdog_init_timeout, since it initializes the timeout from devicetree > > data. > > The driver does not support devicetree. > I should have said "the system". Calling watchdog_init_timeout is the only thing a watchdog driver has to do to support devicetree. Thanks, Guenter -- 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/7] memcg: use css_get in sock_update_memcg()
On Wed 03-04-13 16:58:48, Glauber Costa wrote:
> On 04/03/2013 01:11 PM, Li Zefan wrote:
> > Use css_get/css_put instead of mem_cgroup_get/put.
> >
> > Note, if at the same time someone is moving @current to a different
> > cgroup and removing the old cgroup, css_tryget() may return false,
> > and sock->sk_cgrp won't be initialized.
> >
> > Signed-off-by: Li Zefan
> > ---
> > mm/memcontrol.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 23d0f6e..43ca91d 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -536,15 +536,15 @@ void sock_update_memcg(struct sock *sk)
> > */
> > if (sk->sk_cgrp) {
> > BUG_ON(mem_cgroup_is_root(sk->sk_cgrp->memcg));
> > - mem_cgroup_get(sk->sk_cgrp->memcg);
> > + css_get(>sk_cgrp->memcg->css);
I am not sure I understand this one. So we have a goup here (which means
that somebody already took a reference on it, right?) and we are taking
another reference. If this is released by sock_release_memcg then who
releases the previous one? It is not directly related to the patch
because this has been done previously already. Could you clarify
Glauber, please?
> > return;
> > }
> >
> > rcu_read_lock();
> > memcg = mem_cgroup_from_task(current);
> > cg_proto = sk->sk_prot->proto_cgroup(memcg);
> > - if (!mem_cgroup_is_root(memcg) && memcg_proto_active(cg_proto))
> > {
> > - mem_cgroup_get(memcg);
> > + if (!mem_cgroup_is_root(memcg) &&
> > + memcg_proto_active(cg_proto) && css_tryget(>css)) {
> > sk->sk_cgrp = cg_proto;
> > }
>
> What happens if this tryget fails ? Won't we leak a reference here? We
> will put regardless when the socket is released, and this may go
> negative. No?
AFAICS sock_release_memcg releases the reference only if sk->sk_cgrp and
that one wouldn't be set if css_tryget fails.
--
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: [ 000/124] 3.8.6-stable review
On Wed, Apr 03, 2013 at 09:17:33AM -0600, Shuah Khan wrote: > On Tue, Apr 2, 2013 at 4:09 PM, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 3.8.6 release. > > There are 124 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Apr 4 22:09:55 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.8.6-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Patches applied cleanly to 3.0.71, 3.4.38, and 3.8.5 > > Reviewing patches - will let you know anything odd. > > Compiled and booted on the following systems: > > HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz > HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics > > dmesgs for all releases look good. No regressions compared to the > previous dmesgs for each of these releases. > > mips compile problem fixed > > Cross-compile tests results: > > alpha: defconfig passed on all > arm: defconfig passed on all > arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.8.y > c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.8.y. > powerpc: wii_defconfig passed on all > sh: defconfig passed on all > sparc: defconfig passed on all > tile: tilegx_defconfig passed on all > mips: defconfig passed on all > mipsel: defconfig passed on all Thanks for testing, and confirming that I got the build problem fixed. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v3.8, v3.9] [Regression] brcmsmac: move PHY functions
On 04/02/2013 05:02 AM, Piotr Haber wrote: On 04/01/13 17:18, Joseph Salisbury wrote: On 04/01/2013 10:42 AM, John W. Linville wrote: On Fri, Mar 29, 2013 at 03:52:39PM -0400, Joseph Salisbury wrote: Hi Piotr, A bug was opened against the Ubuntu kernel[0]. After a kernel bisect, it was found that reverting the following commit resolved this bug: commit b83576341664957978e125f5f5db2f15496980b1 Author: Piotr Haber Date: Wed Nov 28 21:44:09 2012 +0100 brcmsmac: move PHY functions The regression was introduced as of v3.8-rc1. The regression still exists in v3.9-rc4. I see that you are the author of this patch, so I wanted to run this by you. I was thinking of requesting a revert for v3.9, but I wanted to get your feedback first. Thanks, Joe [0] http://pad.lv/1131914 I recently reverted b6fc28a1, which is the follow-on to that patch. The revert is _not_ in 3.9-rc5. Could you try reverting that patch instead? Does that fix the issue for you? John Hi John, Thanks for the response. Yes, reverting commit b6fc28a1 does resolve this bug. That is the appropriate fix for this issue. Thanks for the assistance. Thanks, Joe Hi Joe, could you elaborate a little bit on your failure scenario? In bug report you say it happens after suspend/resume, are there any other scenarios you see this behaviour? (like disassociation/association without suspend) Also you mention it comes back after some time - what is the time needed? We had reports of problems on 4313 with this patch (that's why the revert was done) but so far i assumed it was a total breakdown, in your case this seem like a transient issue. This only happens after a suspend/resume cycle. I haven't seen the issue happen with disassociation/association without suspend. After suspend, the connection will re-establish after about 15 minutes or so. One more thing, could you provide info about your hardware by sending me contents of: /brcmsmac/bcma0:0/hardware board vendor: 144f board type: 7179 board revision: 1408 board flags: 8402a01 board flags2: 880 firmware revision: 262032c Kind regards Piotr -- 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: [ 105/124] af_unix: dont send SCM_CREDENTIAL when dest socket is NULL
On Wed, Apr 03, 2013 at 05:10:40PM +0200, Sven Joachim wrote: > On 2013-04-03 16:00 +0200, Eric Dumazet wrote: > > > On Wed, 2013-04-03 at 13:41 +0200, Sven Joachim wrote: > >> On 2013-04-03 00:11 +0200, Greg Kroah-Hartman wrote: > >> > >> > 3.8-stable review patch. If anyone has any objections, please let me > >> > know. > >> > >> I'm seeing several complaints from udevd at boot in both 3.8.6-rc1 and > >> 3.9-rc5: "udevd[56]: sender uid=65534, message ignored". Reverting the > >> patch below on top of 3.8.6-rc1 fixes that. I'm using udev version 175 > >> here, and 65534 is the uid of user "nobody". > > > > And if you use a 3.1 kernel (before commit > > 16e5726269611b71c930054ffe9b858c1cea88eb) are you seeing this message ? > > No (tested with 3.1.10). > > > It might be a wrong sender (application bug or bad identity), and udevd > > correctly discards the incoming message. > > How would I find out the culprit? Try running 'udevadm monitor' as root and see if something shows up there. I can't reproduce this here, running a newer version of udev (195), sorry, I don't have any systems with older udev releases. Note, someone else posted this same error earlier today on the linux-usb mailing list, saying that USB storage devices would not automount anymore. Does that work properly for you? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: fix rebuild with EFI_STUB enabled
On 04/03/2013 07:58 AM, Jan Beulich wrote: On 03.04.13 at 16:48, "H. Peter Anvin" wrote: >> This looks awesome for 3.10, but getting a minimal fix for 3.9/stable would >> be good, too. > > Do you really view this as relevant for stable? Considering that this > had been this way for a while with apparently no-one having noticed, > I wouldn't think so. Nor would I see a strong need for this to go into > 3.9. > > Jan > Since it is a build fix, I think I do. You never quite know who build problems is going to bite, and I'd rather just fix them as long as the fix is suitably small and obvious. It doesn't exactly help that kbuild is hideously fragile. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] s390 patches for the 3.9-rc6
Hi Linus,
please pull from the 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
to receive the following updates: Just a bunch of bugfixes.
Heiko Carstens (4):
drivers/Kconfig: add several missing GENERIC_HARDIRQS dependencies
s390/uaccess: fix clear_user_pt()
s390/uaccess: fix page table walk
s390/mm: provide emtpy check_pgt_cache() function
Martin Schwidefsky (1):
s390/3270: fix minor_start issue
Sebastian Ott (1):
s390/scm_block: fix printk format string
Wei Yongjun (1):
s390/scm_blk: fix error return code in scm_blk_init()
arch/s390/include/asm/pgtable.h |4 +-
arch/s390/lib/uaccess_pt.c | 83 ++-
drivers/dma/Kconfig |1 +
drivers/media/platform/Kconfig |2 +-
drivers/s390/block/scm_blk.c| 11 --
drivers/s390/block/scm_drv.c|2 +-
drivers/s390/char/tty3270.c | 16
drivers/spi/Kconfig |3 +-
8 files changed, 79 insertions(+), 43 deletions(-)
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 4a29308..4a54431 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -344,6 +344,7 @@ extern unsigned long MODULES_END;
#define _REGION3_ENTRY_CO 0x100 /* change-recording override*/
/* Bits in the segment table entry */
+#define _SEGMENT_ENTRY_ORIGIN_LARGE ~0xfUL /* large page address */
#define _SEGMENT_ENTRY_ORIGIN ~0x7ffUL/* segment table origin */
#define _SEGMENT_ENTRY_RO 0x200 /* page protection bit */
#define _SEGMENT_ENTRY_INV 0x20/* invalid segment table entry */
@@ -1531,7 +1532,8 @@ extern int s390_enable_sie(void);
/*
* No page table caches to initialise
*/
-#define pgtable_cache_init() do { } while (0)
+static inline void pgtable_cache_init(void) { }
+static inline void check_pgt_cache(void) { }
#include
diff --git a/arch/s390/lib/uaccess_pt.c b/arch/s390/lib/uaccess_pt.c
index dff631d..466fb33 100644
--- a/arch/s390/lib/uaccess_pt.c
+++ b/arch/s390/lib/uaccess_pt.c
@@ -77,42 +77,69 @@ static size_t copy_in_kernel(size_t count, void __user *to,
* >= -4095 (IS_ERR_VALUE(x) returns true), a fault has occured and the address
* contains the (negative) exception code.
*/
-static __always_inline unsigned long follow_table(struct mm_struct *mm,
- unsigned long addr, int write)
+#ifdef CONFIG_64BIT
+static unsigned long follow_table(struct mm_struct *mm,
+ unsigned long address, int write)
{
- pgd_t *pgd;
- pud_t *pud;
- pmd_t *pmd;
- pte_t *ptep;
+ unsigned long *table = (unsigned long *)__pa(mm->pgd);
+
+ switch (mm->context.asce_bits & _ASCE_TYPE_MASK) {
+ case _ASCE_TYPE_REGION1:
+ table = table + ((address >> 53) & 0x7ff);
+ if (unlikely(*table & _REGION_ENTRY_INV))
+ return -0x39UL;
+ table = (unsigned long *)(*table & _REGION_ENTRY_ORIGIN);
+ case _ASCE_TYPE_REGION2:
+ table = table + ((address >> 42) & 0x7ff);
+ if (unlikely(*table & _REGION_ENTRY_INV))
+ return -0x3aUL;
+ table = (unsigned long *)(*table & _REGION_ENTRY_ORIGIN);
+ case _ASCE_TYPE_REGION3:
+ table = table + ((address >> 31) & 0x7ff);
+ if (unlikely(*table & _REGION_ENTRY_INV))
+ return -0x3bUL;
+ table = (unsigned long *)(*table & _REGION_ENTRY_ORIGIN);
+ case _ASCE_TYPE_SEGMENT:
+ table = table + ((address >> 20) & 0x7ff);
+ if (unlikely(*table & _SEGMENT_ENTRY_INV))
+ return -0x10UL;
+ if (unlikely(*table & _SEGMENT_ENTRY_LARGE)) {
+ if (write && (*table & _SEGMENT_ENTRY_RO))
+ return -0x04UL;
+ return (*table & _SEGMENT_ENTRY_ORIGIN_LARGE) +
+ (address & ~_SEGMENT_ENTRY_ORIGIN_LARGE);
+ }
+ table = (unsigned long *)(*table & _SEGMENT_ENTRY_ORIGIN);
+ }
+ table = table + ((address >> 12) & 0xff);
+ if (unlikely(*table & _PAGE_INVALID))
+ return -0x11UL;
+ if (write && (*table & _PAGE_RO))
+ return -0x04UL;
+ return (*table & PAGE_MASK) + (address & ~PAGE_MASK);
+}
- pgd = pgd_offset(mm, addr);
- if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd)))
- return -0x3aUL;
+#else /* CONFIG_64BIT */
- pud = pud_offset(pgd, addr);
- if (pud_none(*pud) || unlikely(pud_bad(*pud)))
- return -0x3bUL;
+static unsigned long follow_table(struct mm_struct *mm,
+ unsigned long address, int write)
+{
+ unsigned
Re: [PATCH 3/3] watchdog: Add Congatec CGEB watchdog driver
On Tue, Mar 26, 2013 at 07:33:31AM -0700, Guenter Roeck wrote:
> On Tue, Mar 26, 2013 at 11:16:35AM +0100, Christian Gmeiner wrote:
> > 2013/2/12 Sascha Hauer :
> > > This driver provides support for the CGEB watchdog found on some
> > > Congatec x86 modules.
> > >
> > > Signed-off-by: Sascha Hauer
> > > ---
> > > drivers/watchdog/Kconfig | 10 ++
> > > drivers/watchdog/Makefile |1 +
> > > drivers/watchdog/congatec_cgeb_watchdog.c | 161
> > > +
> > > 3 files changed, 172 insertions(+)
> > > create mode 100644 drivers/watchdog/congatec_cgeb_watchdog.c
> > >
> > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > > index 7f809fd..47138fb 100644
> > > --- a/drivers/watchdog/Kconfig
> > > +++ b/drivers/watchdog/Kconfig
> > > @@ -934,6 +934,16 @@ config SBC_EPX_C3_WATCHDOG
> > > To compile this driver as a module, choose M here: the
> > > module will be called sbc_epx_c3.
> > >
> > > +config CONGATEC_CGEB_WATCHDOG
> > > + depends on CONGATEC_CGEB
> > > + tristate "Congatec CGEB watchdog"
> > > + ---help---
> > > + This driver provides support for the watchdogs found on Congatec
> > > + modules with the CGEB BIOS interface.
> > > +
> > > + To compile this driver as a module, choose M here: the
> > > + module will be called congatec_cgeb_wdt.
> > > +
> > > # M32R Architecture
> > >
> > > # M68K Architecture
> > > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > > index 97bbdb3a..e67eee5 100644
> > > --- a/drivers/watchdog/Makefile
> > > +++ b/drivers/watchdog/Makefile
> > > @@ -108,6 +108,7 @@ obj-$(CONFIG_W83977F_WDT) += w83977f_wdt.o
> > > obj-$(CONFIG_MACHZ_WDT) += machzwd.o
> > > obj-$(CONFIG_SBC_EPX_C3_WATCHDOG) += sbc_epx_c3.o
> > > obj-$(CONFIG_INTEL_SCU_WATCHDOG) += intel_scu_watchdog.o
> > > +obj-$(CONFIG_CONGATEC_CGEB_WATCHDOG) += congatec_cgeb_watchdog.o
> > >
> > > # M32R Architecture
> > >
> > > diff --git a/drivers/watchdog/congatec_cgeb_watchdog.c
> > > b/drivers/watchdog/congatec_cgeb_watchdog.c
> > > new file mode 100644
> > > index 000..b7b6cf5
> > > --- /dev/null
> > > +++ b/drivers/watchdog/congatec_cgeb_watchdog.c
> > > @@ -0,0 +1,161 @@
> > > +/*
> > > + * CGEB watchdog driver
> > > + *
> > > + * (c) 2011 Sascha Hauer, Pengutronix
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; version 2 of the License.
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > > + * GNU General Public License for more details.
> > > + */
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#define CGOS_WDOG_MODE_REBOOT_PC0
> > > +#define CGOS_WDOG_MODE_RESTART_OS 1
> > > +#define CGOS_WDOG_MODE_STAGED0x80
> > > +
> > > +#define CGOS_WDOG_OPMODE_DISABLED 0
> > > +#define CGOS_WDOG_OPMODE_ONETIME_TRIG 1
> > > +#define CGOS_WDOG_OPMODE_SINGLE_EVENT 2
> > > +#define CGOS_WDOG_OPMODE_EVENT_REPEAT 3
> > > +
> > > +#define CGOS_WDOG_EVENT_INT 0 /* NMI/IRQ */
> > > +#define CGOS_WDOG_EVENT_SCI 1 /* SMI/SCI */
> > > +#define CGOS_WDOG_EVENT_RST 2 /* system reset */
> > > +#define CGOS_WDOG_EVENT_BTN 3 /* power button */
> > > +
> > > +#define CGOS_WDOG_EVENT_MAX_STAGES 3
> > > +
> > > +struct cgeb_watchdog_stage {
> > > + unsigned long timeout;
> > > + unsigned long event;
> > > +};
> > > +
> > > +struct cgeb_watchdog_config {
> > > + unsigned long size;
> > > + unsigned long timeout; /* not used in staged mode */
> > > + unsigned long delay;
> > > + unsigned long mode;
> > > + /* optional parameters for staged watchdog */
> > > + unsigned long op_mode;
> > > + unsigned long stage_count;
> > > + struct cgeb_watchdog_stage stages[CGOS_WDOG_EVENT_MAX_STAGES];
> > > +};
>
> Presumably that is a data structure sent to the board. Just wondering - can
> the
> driver ever be build as 64 bit driver ? If so, you might want to use u32
> instead
> of unsigned long.
I don't think that this is used on any 64bit capable hardware. Anyway,
explicitly using u32 here sounds very good. I'll change it.
> > > +static int cgeb_watchdog_start(struct watchdog_device *wdd)
> > > +{
> > > + struct cgeb_watchdog_priv *priv = watchdog_get_drvdata(wdd);
> > > +
> > > + return watchdog_set_config(priv, wdd->timeout);
> > > +}
> > > +
> > > +static int cgeb_watchdog_stop(struct watchdog_device *wdd)
> > > +{
> > > + struct cgeb_watchdog_priv *priv = watchdog_get_drvdata(wdd);
> > > +
> > > + return watchdog_set_config(priv, 0);
> > > +}
> > > +
> > > +static int
Re: [PATCH 3/3] watchdog: Add Congatec CGEB watchdog driver
On Tue, Mar 26, 2013 at 11:16:35AM +0100, Christian Gmeiner wrote: > 2013/2/12 Sascha Hauer : > > -- > > There seems to be a problem: > > Mar 26 16:11:25 OT kernel: [ 80.207514] cgeb-watchdog > cgeb-watchdog.0: registered > Mar 26 16:11:38 OT watchdog[2519]: stopping daemon (5.9) > Mar 26 16:11:43 OT watchdog[2750]: starting daemon (5.9): > Mar 26 16:11:43 OT watchdog[2750]: int=1s realtime=yes sync=no soft=no > mla=0 mem=0 > Mar 26 16:11:43 OT watchdog[2750]: ping: no machine to check > Mar 26 16:11:43 OT watchdog[2750]: file: no file to check > Mar 26 16:11:43 OT watchdog[2750]: pidfile: no server process to check > Mar 26 16:11:43 OT watchdog[2750]: interface: no interface to check > Mar 26 16:11:43 OT watchdog[2750]: test=none(0) repair=none(0) > alive=/dev/watchdog heartbeat=none temp=none to=root no_act=no > Mar 26 16:11:43 OT watchdog[2750]: cannot set timeout 60 (errno = 95 = > 'Operation not supported') As mentioned in my other mail the watchdog core no longer sets wdd->timeout which results in the above message. Should be fixed with the next version. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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] ext4: fix a big-endian bug when an extent is zeroed out
Hello, Le 04/03/13 16:41, Theodore Ts'o a écrit : On Wed, Apr 03, 2013 at 10:34:06AM -0400, Eric Whitney wrote: The TI OMAP4 processor on my Pandaboard test system is little endian. Ah... so basically, we need to find a test platform which allows us to boot arbitrary kernels and allows us to have root access (which means it's unlikely we'll be able to do this via remote access) and which doesn't have exotic power requirements (which as far as I know rules out pSeries and zSeries systems) It would also be nice if we could run tests in finite time, which probably rules out the Hercules emulator (it runs at one-tenth zSeries processor speeds, which doesn't win speed competitions by default, and I suspect their storage speeds are even worse). Anyone else have any suggestions? Or anyone willing to help us run ext4 regression tests on the ext4 dev tree, so we can find these problems before we merge into mainline? Qemu emulates various mainline PowerPC, MIPS and SPARC big-endian systems pretty efficiently and it should not be too hard neither to script nor to get a recent kernel up and running on these platforms. My 2 cents. -- Florian -- 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: Excessive stall times on ext4 in 3.9-rc2
On Tue, Apr 02, 2013 at 07:16:13PM -0400, Theodore Ts'o wrote: > I've tried doing some quick timing, and if it is a performance > regression, it's not a recent one --- or I haven't been able to > reproduce what Mel is seeing. I tried the following commands while > booted into 3.2, 3.8, and 3.9-rc3 kernels: > > time git clone ... > rm .git/index ; time git reset > FWIW, I had run a number if git checkout based tests over time and none of them revealed anything useful. Granted it was on other machines but I don't think it's git on its own. It's a combination that leads to this problem. Maybe it's really an IO scheduler problem and I need to figure out what combination triggers it. > > > Mel, how bad is various git commands that you are trying? Have you > tried using time to get estimates of how long a git clone or other git > operation is taking? > Unfortunately, the milage varies considerably and it's not always possible to time the operation. It may be that one occasion that opening a mail takes an abnormal length time with git operations occasionally making it far worse. -- Mel Gorman 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 2/3] usb: phy: twl4030-usb: check regulator_enable return value
On Wed, 2013-04-03 at 16:02 +0200, Fabio Baltieri wrote:
> Since regulator_enable() is going to be marked as __must_check in the
> next merge window, always check regulator_enable() return value and
> print a warning if it fails.
Could go bananas with this and all kinds of recovery schemes, but nah..
Looks good to me. FWIW,
Reviewed-by: Kalle Jokiniemi
>
> Cc: Kalle Jokiniemi
> Signed-off-by: Fabio Baltieri
> ---
> drivers/usb/phy/phy-twl4030-usb.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> b/drivers/usb/phy/phy-twl4030-usb.c
> index 3f9858f..13e17ae 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -384,9 +384,17 @@ static void __twl4030_phy_power(struct twl4030_usb *twl,
> int on)
>
> static void twl4030_phy_power(struct twl4030_usb *twl, int on)
> {
> + int ret;
> +
> if (on) {
> - regulator_enable(twl->usb3v1);
> - regulator_enable(twl->usb1v8);
> + ret = regulator_enable(twl->usb3v1);
> + if (ret)
> + dev_err(twl->dev, "Failed to enable usb3v1\n");
> +
> + ret = regulator_enable(twl->usb1v8);
> + if (ret)
> + dev_err(twl->dev, "Failed to enable usb1v8\n");
> +
> /*
>* Disabling usb3v1 regulator (= writing 0 to VUSB3V1_DEV_GRP
>* in twl4030) resets the VUSB_DEDICATED2 register. This reset
> @@ -395,7 +403,11 @@ static void twl4030_phy_power(struct twl4030_usb *twl,
> int on)
>* is re-activated. This ensures that VUSB3V1 is really active.
>*/
> twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB_DEDICATED2);
> - regulator_enable(twl->usb1v5);
> +
> + ret = regulator_enable(twl->usb1v5);
> + if (ret)
> + dev_err(twl->dev, "Failed to enable usb1v5\n");
> +
> __twl4030_phy_power(twl, 1);
> twl4030_usb_write(twl, PHY_CLK_CTRL,
> twl4030_usb_read(twl, PHY_CLK_CTRL) |
--
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: [ 00/68] 3.4.39-stable review
On Tue, Apr 2, 2013 at 4:12 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.4.39 release. > There are 68 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Apr 4 22:12:59 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.39-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Patches applied cleanly to 3.0.71, 3.4.38, and 3.8.5 Reviewing patches - will let you know anything odd. Compiled and booted on the following systems: HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics dmesgs for all releases look good. No regressions compared to the previous dmesgs for each of these releases. mips compile problem fixed Cross-compile tests results: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.8.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.8.y. powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all mips: defconfig passed on all mipsel: defconfig passed on all -- Shuah -- 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: [ 00/56] 3.0.72-stable review
On Tue, Apr 2, 2013 at 4:49 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.0.72 release. > There are 56 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Apr 4 22:46:30 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.72-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Patches applied cleanly to 3.0.71, 3.4.38, and 3.8.5 Reviewing patches - will let you know anything odd. Compiled and booted on the following systems: HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics dmesgs for all releases look good. No regressions compared to the previous dmesgs for each of these releases. mips compile problem fixed Cross-compile tests results: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.8.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.8.y. powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all mips: defconfig passed on all mipsel: defconfig passed on all -- Shuah -- 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] sysfs: fix crash_notes_size build warning
>From b60d17603df3225d9f51c4f8168e8e00a1090911 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann
Date: Wed, 3 Apr 2013 17:14:32 +0200
Subject: [PATCH] sysfs: fix crash_notes_size build warning
commit eca4549f57 "sysfs: Add crash_notes_size to export percpu
note size" adds a printk that outputs a size_t value as %lu
when it should be %zu, resulting in this warning.
drivers/base/cpu.c: In function 'show_crash_notes_size':
drivers/base/cpu.c:142:2: warning: format '%lu' expects argument of type 'long
unsigned int', but argument 3 has type 'unsigned int' [-Wformat=]
Signed-off-by: Arnd Bergmann
Cc: Zhang Yanfei
Cc: Simon Horman
Cc: Greg Kroah-Hartman
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index a55b590..d8c7f3e 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -139,7 +139,7 @@ static ssize_t show_crash_notes_size(struct device *dev,
{
ssize_t rc;
- rc = sprintf(buf, "%lu\n", sizeof(note_buf_t));
+ rc = sprintf(buf, "%zu\n", sizeof(note_buf_t));
return rc;
}
static DEVICE_ATTR(crash_notes_size, 0400, show_crash_notes_size, NULL);
--
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: [ 000/124] 3.8.6-stable review
On Tue, Apr 2, 2013 at 4:09 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.8.6 release. > There are 124 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Apr 4 22:09:55 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.8.6-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Patches applied cleanly to 3.0.71, 3.4.38, and 3.8.5 Reviewing patches - will let you know anything odd. Compiled and booted on the following systems: HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics dmesgs for all releases look good. No regressions compared to the previous dmesgs for each of these releases. mips compile problem fixed Cross-compile tests results: alpha: defconfig passed on all arm: defconfig passed on all arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.8.y c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.8.y. powerpc: wii_defconfig passed on all sh: defconfig passed on all sparc: defconfig passed on all tile: tilegx_defconfig passed on all mips: defconfig passed on all mipsel: defconfig passed on all -- Shuah -- 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: Excessive stall times on ext4 in 3.9-rc2
On Wed, Apr 03, 2013 at 08:05:30AM -0400, Theodore Ts'o wrote: > On Wed, Apr 03, 2013 at 11:19:25AM +0100, Mel Gorman wrote: > > > > I'm running with -rc5 now. I have not noticed much interactivity problems > > as such but the stall detection script reported that mutt stalled for > > 20 seconds opening an inbox and imapd blocked for 59 seconds doing path > > lookups, imaps blocked again for 12 seconds doing an atime update, an RSS > > reader blocked for 3.5 seconds writing a file. etc. > > If imaps blocked for 12 seconds during an atime update, combined with > everything else, at a guess it got caught by something holding up a > journal commit. It's a possibility. I apologise but I forgot that mail is stored on a crypted partition on this machine. It's formatted ext4 but dmcrypt could be making this problem worse if it's stalling ext4 waiting to encrypt/decrypt data due to either a scheduler or workqueue change. > Could you try enabling the jbd2_run_stats tracepoint > and grabbing the trace log? This will give you statistics on how long > (in milliseconds) each of the various phases of a jbd2 commit is > taking, i.e.: > > jbd2/sdb1-8-327 [002] 39681.874661: jbd2_run_stats: dev 8,17 tid > 7163786 wait 0 request_delay 0 running 3530 locked 0 flushing 0 logging 0 > handle_count 75 blocks 8 blocks_logged 9 > jbd2/sdb1-8-327 [003] 39682.514153: jbd2_run_stats: dev 8,17 tid > 7163787 wait 0 request_delay 0 running 640 locked 0 flushing 0 logging 0 > handle_count 39 blocks 12 blocks_logged 13 > jbd2/sdb1-8-327 [000] 39687.665609: jbd2_run_stats: dev 8,17 tid > 7163788 wait 0 request_delay 0 running 5150 locked 0 flushing 0 logging 0 > handle_count 60 blocks 13 blocks_logged 14 > jbd2/sdb1-8-327 [000] 39693.200453: jbd2_run_stats: dev 8,17 tid > 7163789 wait 0 request_delay 0 running 4840 locked 0 flushing 0 logging 0 > handle_count 53 blocks 10 blocks_logged 11 > jbd2/sdb1-8-327 [001] 39695.061657: jbd2_run_stats: dev 8,17 tid > 7163790 wait 0 request_delay 0 running 1860 locked 0 flushing 0 logging 0 > handle_count 124 blocks 19 blocks_logged 20 > Attached as well as the dstate summary that was recorded at the same time. It's not quite as compelling but I'll keep the monitor running and see if something falls out. I didn't find anything useful in the existing mmtests tests that could be used to bisect this but not many of them are focused on IO. > In the above sample each journal commit is running for no more than 5 > seconds or so (since that's the default jbd2 commit timeout; if a > transaction is running for less than 5 seconds, then either we ran out > of room in the journal, and the blocks_logged number will be high, or > a commit was forced by something such as an fsync call). > I didn't see anything majorly compelling in the jbd tracepoints but I'm not 100% sure I'm looking for the right thing either. I also recorded /proc/latency_stat and there were some bad sync latencies from the file as you can see here 3 4481 1586 jbd2_log_wait_commit ext4_sync_file vfs_fsync sys_msync system_call_fastpath 3 11325 4373 sleep_on_page wait_on_page_bit kretprobe_trampoline filemap_write_and_wait_range ext4_sync_file vfs_fsync sys_msync system_call_fastpath 85 1130707 14904 jbd2_journal_stop jbd2_journal_force_commit ext4_force_commit ext4_sync_file do_fsync sys_fsync system_call_fastpath 1 2161073 2161073 start_this_handle jbd2__journal_start.part.8 jbd2__journal_start __ext4_journal_start_sb ext4_da_writepages do_writepages __filemap_fdatawrite_range filemap_write_and_wait_range ext4_sync_file do_fsync sys_fsync system_call_fastpath 118 7798435 596184 jbd2_log_wait_commit jbd2_journal_stop jbd2_journal_force_commit ext4_force_commit ext4_sync_file do_fsync sys_fsync system_call_fastpath 599 15496449 3405822 sleep_on_page wait_on_page_bit kretprobe_trampoline filemap_write_and_wait_range ext4_sync_file do_fsync sys_fsync system_call_fastpath 405 28572881 2619592 jbd2_log_wait_commit ext4_sync_file do_fsync sys_fsync system_call_fastpath > If an atime update is getting blocked by 12 seconds, then it would be > interesting to see if a journal commit is running for significantly > longer than 5 seconds, or if one of the other commit phases is taking > significant amounts of time. (On the example above they are all > taking no time, since I ran this on a relatively uncontended system; > only a single git operation taking place.) > > Something else that might be worth trying is grabbing a lock_stat > report and see if something is sitting on an ext4 or jbd2 mutex for a > long time. > Ok, if nothing useful falls out in this session I'll enable lock debugging. latency_stat on its own would not be enough to conclude that a problem was related to lock contention. > Finally, as I mentioned I tried some rather simplistic tests and I > didn't notice any difference between a 3.2 kernel and a 3.8/3.9-rc5 > kernel. Assuming you
Re: [ 105/124] af_unix: dont send SCM_CREDENTIAL when dest socket is NULL
On 2013-04-03 16:00 +0200, Eric Dumazet wrote: > On Wed, 2013-04-03 at 13:41 +0200, Sven Joachim wrote: >> On 2013-04-03 00:11 +0200, Greg Kroah-Hartman wrote: >> >> > 3.8-stable review patch. If anyone has any objections, please let me know. >> >> I'm seeing several complaints from udevd at boot in both 3.8.6-rc1 and >> 3.9-rc5: "udevd[56]: sender uid=65534, message ignored". Reverting the >> patch below on top of 3.8.6-rc1 fixes that. I'm using udev version 175 >> here, and 65534 is the uid of user "nobody". > > And if you use a 3.1 kernel (before commit > 16e5726269611b71c930054ffe9b858c1cea88eb) are you seeing this message ? No (tested with 3.1.10). > It might be a wrong sender (application bug or bad identity), and udevd > correctly discards the incoming message. How would I find out the culprit? Cheers, Sven -- 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 2/2] watchdog: fix w83627hf_wdt clear timeout expired
On Tue, Apr 2, 2013 at 9:21 PM, Guenter Roeck wrote:
>
>
> What is the exact chip type in your system ? I want to have a look into the
> datasheet; maybe I can find out how it can trigger without causing a reset.
Winbond 83627HF chip
I believe BIOS has watchdog disabled otherwise it would have reboot the box.
However, the timer just start counting.
Comparing to ipmi_watchdog, you can do this:
modprobe ipmi_watchdog ... start_now=0 ...action=<> nowayout=1
So it is possible to load the driver without start counting.
Notice it is an else, so t is actually 0 already (i.e. expired or
never start running):
> + } else {
> + outb_p(0, WDT_EFDR);/* disable to prevent reboot */
--
- Tony Chung
--
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] cpufreq: convert the cpufreq_driver to use the rcu
We eventually would like to remove the rwlock cpufreq_driver_lock or convert
it back to a spinlock and protect the read sections with RCU. The first step in
that is moving the cpufreq_driver to use the RCU for its read areas.
I don't see an easy wasy to protect the cpufreq_cpu_data structure with the
RCU, so I am leaving it with the rwlock for now since under certain configs
__cpufreq_cpu_get is hot spot with 256+ cores.
Cc: Viresh Kumar
Cc: "Rafael J. Wysocki"
Signed-off-by: Nathan Zimmer
---
drivers/cpufreq/cpufreq.c | 278 ++
1 file changed, 207 insertions(+), 71 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 85963fc..e89506c 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -39,7 +39,7 @@
* level driver of CPUFreq support, and its spinlock. This lock
* also protects the cpufreq_cpu_data array.
*/
-static struct cpufreq_driver *cpufreq_driver;
+static struct cpufreq_driver __rcu *cpufreq_driver;
static DEFINE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_data);
#ifdef CONFIG_HOTPLUG_CPU
/* This one keeps track of the previously set governor of a removed CPU */
@@ -130,26 +130,33 @@ static DEFINE_MUTEX(cpufreq_governor_mutex);
bool have_governor_per_policy(void)
{
- return cpufreq_driver->have_governor_per_policy;
+ bool have_governor;
+ rcu_read_lock();
+ have_governor =
rcu_dereference(cpufreq_driver)->have_governor_per_policy;
+ rcu_read_unlock();
+ return have_governor;
}
static struct cpufreq_policy *__cpufreq_cpu_get(unsigned int cpu, bool sysfs)
{
struct cpufreq_policy *data;
+ struct cpufreq_driver *driver;
unsigned long flags;
if (cpu >= nr_cpu_ids)
goto err_out;
/* get the cpufreq driver */
- read_lock_irqsave(_driver_lock, flags);
+ rcu_read_lock();
+ driver = rcu_dereference(cpufreq_driver);
- if (!cpufreq_driver)
+ if (!driver)
goto err_out_unlock;
- if (!try_module_get(cpufreq_driver->owner))
+ if (!try_module_get(driver->owner))
goto err_out_unlock;
+ read_lock_irqsave(_driver_lock, flags);
/* get the CPU */
data = per_cpu(cpufreq_cpu_data, cpu);
@@ -161,12 +168,14 @@ static struct cpufreq_policy *__cpufreq_cpu_get(unsigned
int cpu, bool sysfs)
goto err_out_put_module;
read_unlock_irqrestore(_driver_lock, flags);
+ rcu_read_unlock();
return data;
err_out_put_module:
- module_put(cpufreq_driver->owner);
-err_out_unlock:
+ module_put(driver->owner);
read_unlock_irqrestore(_driver_lock, flags);
+err_out_unlock:
+ rcu_read_unlock();
err_out:
return NULL;
}
@@ -189,7 +198,9 @@ static void __cpufreq_cpu_put(struct cpufreq_policy *data,
bool sysfs)
{
if (!sysfs)
kobject_put(>kobj);
- module_put(cpufreq_driver->owner);
+ rcu_read_lock();
+ module_put(rcu_dereference(cpufreq_driver)->owner);
+ rcu_read_unlock();
}
void cpufreq_cpu_put(struct cpufreq_policy *data)
@@ -267,7 +278,9 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs,
unsigned int state)
if (cpufreq_disabled())
return;
- freqs->flags = cpufreq_driver->flags;
+ rcu_read_lock();
+ freqs->flags = rcu_dereference(cpufreq_driver)->flags;
+ rcu_read_unlock();
pr_debug("notification %u of frequency transition to %u kHz\n",
state, freqs->new);
@@ -282,7 +295,7 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs,
unsigned int state)
* which is not equal to what the cpufreq core thinks is
* "old frequency".
*/
- if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
+ if (!(freqs->flags & CPUFREQ_CONST_LOOPS)) {
if ((policy) && (policy->cpu == freqs->cpu) &&
(policy->cur) && (policy->cur != freqs->old)) {
pr_debug("Warning: CPU frequency is"
@@ -334,11 +347,21 @@ static int cpufreq_parse_governor(char *str_governor,
unsigned int *policy,
struct cpufreq_governor **governor)
{
int err = -EINVAL;
-
- if (!cpufreq_driver)
+ struct cpufreq_driver *driver;
+ bool has_setpolicy;
+ bool has_target;
+
+ rcu_read_lock();
+ driver = rcu_dereference(cpufreq_driver);
+ if (!driver) {
+ rcu_read_unlock();
goto out;
+ }
+ has_setpolicy = driver->setpolicy ? true : false;
+ has_target = driver->target ? true : false;
+ rcu_read_unlock();
- if (cpufreq_driver->setpolicy) {
+ if (has_setpolicy) {
if (!strnicmp(str_governor, "performance", CPUFREQ_NAME_LEN)) {
[PATCH] fscache: extended "dying" check before emitting EV_INVALIDATE
Before emitting an FSCACHE_OBJECT_EV_INVALIDATE event, the function
__fscache_invalidate() checks whether the fscache_object is currently
"dying". This checks only the current state, not the queued events
that will very soon lead to the object's death.
The problem is that fscache_object_state_machine() will
BUG("Unsupported event") when there is object->events includes
EV_INVALIDATE during "terminal_transit". Even if we would ignore that
check, we could run into "Unexpected event in dead state" later
because object->work may still be queued.
The solution is to check for EV_RETIRE and EV_RELEASE; if one of those
two terminal events is already queued, don't bother to queue
EV_INVALIDATE.
Signed-off-by: Max Kellermann
---
fs/fscache/cookie.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/fscache/cookie.c b/fs/fscache/cookie.c
index 8dcb114..ed80d7f 100644
--- a/fs/fscache/cookie.c
+++ b/fs/fscache/cookie.c
@@ -402,7 +402,8 @@ void __fscache_invalidate(struct fscache_cookie *cookie)
object = hlist_entry(cookie->backing_objects.first,
struct fscache_object,
cookie_link);
- if (object->state < FSCACHE_OBJECT_DYING)
+ if (object->state < FSCACHE_OBJECT_DYING &&
+ (object->events &
(FSCACHE_OBJECT_EV_RETIRE|FSCACHE_OBJECT_EV_RELEASE)) == 0)
fscache_raise_event(
object, FSCACHE_OBJECT_EV_INVALIDATE);
}
--
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 v9 14/14] clk: tegra: Remove forced clk_enable of uartd
The UART driver enables the console uart clock, so we don't need to do that
anymore in this file.
Signed-off-by: Peter De Schrijver
---
drivers/clk/tegra/clk-tegra114.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index e2a7fa1..0db81dd 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -2011,7 +2011,7 @@ static __initdata struct tegra_clk_init_table
init_table[] = {
{uarta, pll_p, 40800, 0},
{uartb, pll_p, 40800, 0},
{uartc, pll_p, 40800, 0},
- {uartd, pll_p, 40800, 1},
+ {uartd, pll_p, 40800, 0},
{pll_a, clk_max, 56448, 1},
{pll_a_out0, clk_max, 11289600, 1},
{extern1, pll_a_out0, 0, 1},
--
1.7.7.rc0.72.g4b5ea.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: fix rebuild with EFI_STUB enabled
>>> On 03.04.13 at 16:48, "H. Peter Anvin" wrote: > This looks awesome for 3.10, but getting a minimal fix for 3.9/stable would > be good, too. Do you really view this as relevant for stable? Considering that this had been this way for a while with apparently no-one having noticed, I wouldn't think so. Nor would I see a strong need for this to go into 3.9. Jan > Jan Beulich wrote: > >>eboot.o and efi_stub_$(BITS).o didn't get added to "targets", and hence >>their .cmd files don't get included by the build machinery, leading to >>the files always getting rebuilt. >> >>Rather than adding the two files individually, take the opportunity and >>add $(VMLINUX_OBJS) to "targets" instead, thus allowing the assignment >>at the top of the file to be shrunk quite a bit. >> >>At the same time, remove a pointless flags override line - the variable >>assigned to was misspelled anyway, and the options added are >>meaningless for assembly sources. >> >>Signed-off-by: Jan Beulich >>Cc: Matthew Garrett >>Cc: Matt Fleming >>--- >> arch/x86/boot/compressed/Makefile |5 ++--- >> 1 file changed, 2 insertions(+), 3 deletions(-) >> >>--- 3.9-rc5/arch/x86/boot/compressed/Makefile >>+++ 3.9-rc5-x86-EFI-stub-rebuild/arch/x86/boot/compressed/Makefile >>@@ -4,7 +4,7 @@ >> # create a compressed vmlinux image from the original vmlinux >> # >> >>-targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz >>vmlinux.bin.bz2 vmlinux.bin.lzma vmlinux.bin.xz vmlinux.bin.lzo >>head_$(BITS).o misc.o string.o cmdline.o early_serial_console.o piggy.o >>+targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 >>vmlinux.bin.lzma vmlinux.bin.xz vmlinux.bin.lzo >> >> KBUILD_CFLAGS := -m$(BITS) -D__KERNEL__ $(LINUX_INCLUDE) -O2 >> KBUILD_CFLAGS += -fno-strict-aliasing -fPIC >>@@ -29,7 +29,6 @@ VMLINUX_OBJS = $(obj)/vmlinux.lds $(obj) >> $(obj)/piggy.o >> >> $(obj)/eboot.o: KBUILD_CFLAGS += -fshort-wchar -mno-red-zone >>-$(obj)/efi_stub_$(BITS).o: KBUILD_CLFAGS += -fshort-wchar >>-mno-red-zone >> >> ifeq ($(CONFIG_EFI_STUB), y) >> VMLINUX_OBJS += $(obj)/eboot.o $(obj)/efi_stub_$(BITS).o >>@@ -43,7 +42,7 @@ OBJCOPYFLAGS_vmlinux.bin := -R .comment >> $(obj)/vmlinux.bin: vmlinux FORCE >> $(call if_changed,objcopy) >> >>-targets += vmlinux.bin.all vmlinux.relocs >>+targets += $(patsubst $(obj)/%,%,$(VMLINUX_OBJS)) vmlinux.bin.all >>vmlinux.relocs >> >> CMD_RELOCS = arch/x86/tools/relocs >> quiet_cmd_relocs = RELOCS $@ > > -- > Sent from my mobile phone. Please excuse brevity and lack of formatting. -- 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 v9 13/14] ARM: dt: Add references to tegra_car clocks
Add references to tegra_car clocks for the basic device nodes. Also remove
the clock-frequency property of the serial node as the UART driver can now
use the clock framework to obtain the frequency.
Signed-off-by: Peter De Schrijver
---
arch/arm/boot/dts/tegra114-dalmore.dts |1 -
arch/arm/boot/dts/tegra114-pluto.dts |1 -
arch/arm/boot/dts/tegra114.dtsi|8 +++-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
b/arch/arm/boot/dts/tegra114-dalmore.dts
index a61974e..52f1b45 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -715,7 +715,6 @@
serial@70006300 {
status = "okay";
- clock-frequency = <40800>;
};
pmc {
diff --git a/arch/arm/boot/dts/tegra114-pluto.dts
b/arch/arm/boot/dts/tegra114-pluto.dts
index 9bea8f5..31955d7 100644
--- a/arch/arm/boot/dts/tegra114-pluto.dts
+++ b/arch/arm/boot/dts/tegra114-pluto.dts
@@ -12,7 +12,6 @@
serial@70006300 {
status = "okay";
- clock-frequency = <40800>;
};
pmc {
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 5302044..33831a0 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -31,10 +31,11 @@
0 42 0x04
0 121 0x04
0 122 0x04>;
+ clocks = <_car 5>;
};
tegra_car: clock {
- compatible = "nvidia,tegra114-car, nvidia,tegra30-car";
+ compatible = "nvidia,tegra114-car";
reg = <0x60006000 0x1000>;
#clock-cells = <1>;
};
@@ -120,6 +121,7 @@
interrupts = <0 36 0x04>;
nvidia,dma-request-selector = < 8>;
status = "disabled";
+ clocks = <_car 6>;
};
uartb: serial@70006040 {
@@ -129,6 +131,7 @@
interrupts = <0 37 0x04>;
nvidia,dma-request-selector = < 9>;
status = "disabled";
+ clocks = <_car 192>;
};
uartc: serial@70006200 {
@@ -138,6 +141,7 @@
interrupts = <0 46 0x04>;
nvidia,dma-request-selector = < 10>;
status = "disabled";
+ clocks = <_car 55>;
};
uartd: serial@70006300 {
@@ -147,6 +151,7 @@
interrupts = <0 90 0x04>;
nvidia,dma-request-selector = < 19>;
status = "disabled";
+ clocks = <_car 65>;
};
pwm: pwm {
@@ -288,6 +293,7 @@
compatible = "nvidia,tegra114-rtc", "nvidia,tegra20-rtc";
reg = <0x7000e000 0x100>;
interrupts = <0 2 0x04>;
+ clocks = <_car 4>;
};
kbc {
--
1.7.7.rc0.72.g4b5ea.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 13/14] ARM: dt: Add references to tegra_car clocks
Add references to tegra_car clocks for the basic device nodes. Also remove
the clock-frequency property of the serial node as the UART driver can now
use the clock framework to obtain the frequency.
Signed-off-by: Peter De Schrijver
---
arch/arm/boot/dts/tegra114-dalmore.dts |1 -
arch/arm/boot/dts/tegra114-pluto.dts |1 -
arch/arm/boot/dts/tegra114.dtsi|8 +++-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
b/arch/arm/boot/dts/tegra114-dalmore.dts
index a61974e..52f1b45 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -715,7 +715,6 @@
serial@70006300 {
status = "okay";
- clock-frequency = <40800>;
};
pmc {
diff --git a/arch/arm/boot/dts/tegra114-pluto.dts
b/arch/arm/boot/dts/tegra114-pluto.dts
index 9bea8f5..31955d7 100644
--- a/arch/arm/boot/dts/tegra114-pluto.dts
+++ b/arch/arm/boot/dts/tegra114-pluto.dts
@@ -12,7 +12,6 @@
serial@70006300 {
status = "okay";
- clock-frequency = <40800>;
};
pmc {
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 5302044..33831a0 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -31,10 +31,11 @@
0 42 0x04
0 121 0x04
0 122 0x04>;
+ clocks = <_car 5>;
};
tegra_car: clock {
- compatible = "nvidia,tegra114-car, nvidia,tegra30-car";
+ compatible = "nvidia,tegra114-car";
reg = <0x60006000 0x1000>;
#clock-cells = <1>;
};
@@ -120,6 +121,7 @@
interrupts = <0 36 0x04>;
nvidia,dma-request-selector = < 8>;
status = "disabled";
+ clocks = <_car 6>;
};
uartb: serial@70006040 {
@@ -129,6 +131,7 @@
interrupts = <0 37 0x04>;
nvidia,dma-request-selector = < 9>;
status = "disabled";
+ clocks = <_car 192>;
};
uartc: serial@70006200 {
@@ -138,6 +141,7 @@
interrupts = <0 46 0x04>;
nvidia,dma-request-selector = < 10>;
status = "disabled";
+ clocks = <_car 55>;
};
uartd: serial@70006300 {
@@ -147,6 +151,7 @@
interrupts = <0 90 0x04>;
nvidia,dma-request-selector = < 19>;
status = "disabled";
+ clocks = <_car 65>;
};
pwm: pwm {
@@ -288,6 +293,7 @@
compatible = "nvidia,tegra114-rtc", "nvidia,tegra20-rtc";
reg = <0x7000e000 0x100>;
interrupts = <0 2 0x04>;
+ clocks = <_car 4>;
};
kbc {
--
1.7.7.rc0.72.g4b5ea.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/6] usb: phy: omap-usb2: use the new generic PHY framework
On Wednesday 03 April 2013, Felipe Balbi wrote:
> const ? Maybe provide a:
>
> #define DEFINE_PHY_OPS(name)\
> const struct phy_ops #name_phy_ops = {
>
> macro ? This will force people to add the const keyword :-)
Forcing people to use const structures is good, but I think it would be
better without the macro, just by marking the argument in
devm_phy_create() as const.
Arnd
--
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 v9 12/14] clk: tegra: devicetree match for nvidia,tegra114-car
Signed-off-by: Peter De Schrijver
---
drivers/clk/tegra/clk.c |1 +
drivers/clk/tegra/clk.h |6 ++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/clk/tegra/clk.c b/drivers/clk/tegra/clk.c
index 70b7a47..923ca7e 100644
--- a/drivers/clk/tegra/clk.c
+++ b/drivers/clk/tegra/clk.c
@@ -77,6 +77,7 @@ void __init tegra_init_from_table(struct tegra_clk_init_table
*tbl,
static const struct of_device_id tegra_dt_clk_match[] = {
{ .compatible = "nvidia,tegra20-car", .data = tegra20_clock_init },
{ .compatible = "nvidia,tegra30-car", .data = tegra30_clock_init },
+ { .compatible = "nvidia,tegra114-car", .data = tegra114_clock_init },
{ }
};
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index fb48f04..e056562 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -583,6 +583,12 @@ void tegra30_clock_init(struct device_node *np);
static inline void tegra30_clock_init(struct device_node *np) {}
#endif /* CONFIG_ARCH_TEGRA_3x_SOC */
+#ifdef CONFIG_ARCH_TEGRA_114_SOC
+void tegra114_clock_init(struct device_node *np);
+#else
+static inline void tegra114_clock_init(struct device_node *np) {}
+#endif /* CONFIG_ARCH_TEGRA114_SOC */
+
typedef void (*tegra_clk_apply_init_table_func)(void);
extern tegra_clk_apply_init_table_func tegra_clk_apply_init_table;
--
1.7.7.rc0.72.g4b5ea.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 01/21] usb: phy: nop: Add some parameters to platform data
On 04/02/2013 08:21 PM, Tony Lindgren wrote: > * Felipe Balbi [130320 09:24]: >> On Wed, Mar 20, 2013 at 09:13:24AM -0700, Tony Lindgren wrote: >>> * Felipe Balbi [130320 09:00]: On Wed, Mar 20, 2013 at 05:44:40PM +0200, Roger Quadros wrote: > Add clk_rate parameter to platform data. If supplied, the > NOP phy driver will program the clock to that rate during probe. > > Also add 2 flags, needs_vcc and needs_reset. > If the flag is set and the regulator couldn't be found > then the driver will bail out with -EPROBE_DEFER. > > Signed-off-by: Roger Quadros > Acked-by: Felipe Balbi Hi Tony, maybe you might prefer to merge commit 1f0972f from my next branch which is exactly this patch. Basically, if you: $ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next $ git merge 1f0972f you get $SUBJECT and can apply the others without fear of conflicts later. >>> >>> OK thanks will use commit 1f0972f, so let's consider that commit immutable. >> >> yeah, once it hits my 'next' branch, I don't rebase anymore. > > I've applied the board related patchs into omap-for-v3.10/usb that's based > on commit 1f0972f. Thanks Tony. cheers, -roger -- 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 v9 09/14] clk: tegra: Workaround for Tegra114 MSENC problem
Workaround a hardware bug in MSENC during clock enable.
Signed-off-by: Peter De Schrijver
---
drivers/clk/tegra/clk-periph-gate.c |9 +
drivers/clk/tegra/clk.h |2 ++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/clk/tegra/clk-periph-gate.c
b/drivers/clk/tegra/clk-periph-gate.c
index 6dd5332..c9083fb 100644
--- a/drivers/clk/tegra/clk-periph-gate.c
+++ b/drivers/clk/tegra/clk-periph-gate.c
@@ -43,6 +43,8 @@ static DEFINE_SPINLOCK(periph_ref_lock);
#define periph_clk_to_bit(periph) (1 << (gate->clk_num % 32))
+#define LVL2_CLK_GATE_OVRE 0x554
+
/* Peripheral gate clock ops */
static int clk_periph_is_enabled(struct clk_hw *hw)
{
@@ -83,6 +85,13 @@ static int clk_periph_enable(struct clk_hw *hw)
}
}
+ if (gate->flags & TEGRA_PERIPH_WAR_1005168) {
+ writel_relaxed(0, gate->clk_base + LVL2_CLK_GATE_OVRE);
+ writel_relaxed(BIT(22), gate->clk_base + LVL2_CLK_GATE_OVRE);
+ udelay(1);
+ writel_relaxed(0, gate->clk_base + LVL2_CLK_GATE_OVRE);
+ }
+
spin_unlock_irqrestore(_ref_lock, flags);
return 0;
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index fd12b77..fb48f04 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -358,6 +358,7 @@ struct tegra_clk_periph_regs {
* TEGRA_PERIPH_ON_APB - If peripheral is in the APB bus then read the
* bus to flush the write operation in apb bus. This flag indicates
* that this peripheral is in apb bus.
+ * TEGRA_PERIPH_WAR_1005168 - Apply workaround for Tegra114 MSENC bug
*/
struct tegra_clk_periph_gate {
u32 magic;
@@ -377,6 +378,7 @@ struct tegra_clk_periph_gate {
#define TEGRA_PERIPH_NO_RESET BIT(0)
#define TEGRA_PERIPH_MANUAL_RESET BIT(1)
#define TEGRA_PERIPH_ON_APB BIT(2)
+#define TEGRA_PERIPH_WAR_1005168 BIT(3)
void tegra_periph_reset(struct tegra_clk_periph_gate *gate, bool assert);
extern const struct clk_ops tegra_clk_periph_gate_ops;
--
1.7.7.rc0.72.g4b5ea.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 10/14] ARM: tegra: Define Tegra114 CAR binding
The device tree binding models Tegra114 CAR (Clock And Reset) as a single monolithic clock provider. Signed-off-by: Peter De Schrijver --- .../bindings/clock/nvidia,tegra114-car.txt | 317 1 files changed, 317 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt new file mode 100644 index 000..33574a2 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt @@ -0,0 +1,317 @@ +NVIDIA Tegra114 Clock And Reset Controller + +This binding uses the common clock binding: +Documentation/devicetree/bindings/clock/clock-bindings.txt + +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible +for muxing and gating Tegra's clocks, and setting their rates. + +Required properties : +- compatible : Should be "nvidia,tegra114-car" +- reg : Should contain CAR registers location and length +- clocks : Should contain phandle and clock specifiers for two clocks: + the 32 KHz "32k_in", and the board-specific oscillator "osc". +- #clock-cells : Should be 1. + In clock consumers, this cell represents the clock ID exposed by the CAR. + + The first 160 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB + registers. These IDs often match those in the CAR's RST_DEVICES registers, + but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In + this case, those clocks are assigned IDs above 160 in order to highlight + this issue. Implementations that interpret these clock IDs as bit values + within the CLK_OUT_ENB or RST_DEVICES registers should be careful to + explicitly handle these special cases. + + The balance of the clocks controlled by the CAR are assigned IDs of 160 and + above. + + 0unassigned + 1unassigned + 2unassigned + 3unassigned + 4rtc + 5timer + 6uarta + 7unassigned (register bit affects uartb and vfir) + 8unassigned + 9sdmmc2 + 10 unassigned (register bit affects spdif_in and spdif_out) + 11 i2s1 + 12 i2c1 + 13 ndflash + 14 sdmmc1 + 15 sdmmc4 + 16 unassigned + 17 pwm + 18 i2s2 + 19 epp + 20 unassigned (register bit affects vi and vi_sensor) + 21 2d + 22 usbd + 23 isp + 24 3d + 25 unassigned + 26 disp2 + 27 disp1 + 28 host1x + 29 vcp + 30 i2s0 + 31 unassigned + + 32 unassigned + 33 unassigned + 34 apbdma + 35 unassigned + 36 kbc + 37 unassigned + 38 unassigned + 39 unassigned (register bit affects fuse and fuse_burn) + 40 kfuse + 41 sbc1 + 42 nor + 43 unassigned + 44 sbc2 + 45 unassigned + 46 sbc3 + 47 i2c5 + 48 dsia + 49 unassigned + 50 mipi + 51 hdmi + 52 csi + 53 unassigned + 54 i2c2 + 55 uartc + 56 mipi-cal + 57 emc + 58 usb2 + 59 usb3 + 60 msenc + 61 vde + 62 bsea + 63 bsev + + 64 unassigned + 65 uartd + 66 unassigned + 67 i2c3 + 68 sbc4 + 69 sdmmc3 + 70 unassigned + 71 owr + 72 afi + 73 csite + 74 unassigned + 75 unassigned + 76 la + 77 trace + 78 soc_therm + 79 dtv + 80 ndspeed + 81 i2cslow + 82 dsib + 83 tsec + 84 unassigned + 85 unassigned + 86 unassigned + 87 unassigned + 88 unassigned + 89 xusb_host + 90 unassigned + 91 msenc + 92 csus + 93 unassigned + 94 unassigned + 95 unassigned (bit affects xusb_dev and xusb_dev_src) + + 96 unassigned + 97 unassigned + 98 unassigned + 99 mselect + 100 tsensor + 101 i2s3 + 102 i2s4 + 103 i2c4 + 104 sbc5 + 105 sbc6 + 106 d_audio + 107 apbif + 108 dam0 + 109 dam1 + 110 dam2 + 111 hda2codec_2x + 112 unassigned + 113 audio0_2x + 114 audio1_2x + 115 audio2_2x + 116 audio3_2x + 117 audio4_2x + 118 spdif_2x + 119 actmon + 120 extern1 + 121 extern2 + 122 extern3 + 123 unassigned + 124 unassigned + 125 hda + 126 unassigned + 127 se + + 128 hda2hdmi + 129 unassigned + 130 unassigned + 131 unassigned + 132 unassigned + 133 unassigned + 134 unassigned + 135 unassigned + 136 unassigned + 137 unassigned + 138 unassigned + 139 unassigned + 140 unassigned + 141 unassigned + 142 unassigned + 143 unassigned (bit affects xusb_falcon_src, xusb_fs_src, +xusb_host_src and xusb_ss_src) + 144 cilab + 145 cilcd + 146 cile + 147 dsialp + 148 dsiblp + 149 unassigned + 150 dds + 151 unassigned + 152 dp2 + 153 amx + 154 adx + 155 unassigned (bit affects dfll_ref and dfll_soc) + 156 xusb_ss + + 192 uartb + 193 vfir + 194 spdif_in + 195 spdif_out + 196 vi + 197 vi_sensor + 198 fuse + 199 fuse_burn + 200 clk_32k + 201 clk_m + 202 clk_m_div2 + 203 clk_m_div4 + 204 pll_ref
[PATCH] xen: drop tracking of IRQ vector
For quite a few Xen versions, this wasn't the IRQ vector anymore
anyway, and it is not being used by the kernel for anything. Hence
drop the field from struct irq_info, and respective function
parameters.
Signed-off-by: Jan Beulich
Cc: Stefano Stabellini
---
arch/x86/pci/xen.c |6 +++---
drivers/xen/events.c | 13 -
include/xen/events.h |3 +--
3 files changed, 8 insertions(+), 14 deletions(-)
--- 3.9-rc5/arch/x86/pci/xen.c
+++ 3.9-rc5-xen-irq-no-vector/arch/x86/pci/xen.c
@@ -177,7 +177,7 @@ static int xen_setup_msi_irqs(struct pci
goto error;
i = 0;
list_for_each_entry(msidesc, >msi_list, list) {
- irq = xen_bind_pirq_msi_to_irq(dev, msidesc, v[i], 0,
+ irq = xen_bind_pirq_msi_to_irq(dev, msidesc, v[i],
(type == PCI_CAP_ID_MSIX) ?
"pcifront-msi-x" :
"pcifront-msi",
@@ -244,7 +244,7 @@ static int xen_hvm_setup_msi_irqs(struct
dev_dbg(>dev,
"xen: msi already bound to pirq=%d\n", pirq);
}
- irq = xen_bind_pirq_msi_to_irq(dev, msidesc, pirq, 0,
+ irq = xen_bind_pirq_msi_to_irq(dev, msidesc, pirq,
(type == PCI_CAP_ID_MSIX) ?
"msi-x" : "msi",
DOMID_SELF);
@@ -326,7 +326,7 @@ static int xen_initdom_setup_msi_irqs(st
}
ret = xen_bind_pirq_msi_to_irq(dev, msidesc,
- map_irq.pirq, map_irq.index,
+ map_irq.pirq,
(type == PCI_CAP_ID_MSIX) ?
"msi-x" : "msi",
domid);
--- 3.9-rc5/drivers/xen/events.c
+++ 3.9-rc5-xen-irq-no-vector/drivers/xen/events.c
@@ -85,8 +85,7 @@ enum xen_irq_type {
* event channel - irq->event channel mapping
* cpu - cpu this event channel is bound to
* index - type-specific information:
- *PIRQ - vector, with MSB being "needs EIO", or physical IRQ of the HVM
- * guest, or GSI (real passthrough IRQ) of the device.
+ *PIRQ - physical IRQ, GSI, flags, and owner domain
*VIRQ - virq number
*IPI - IPI vector
*EVTCHN -
@@ -105,7 +104,6 @@ struct irq_info {
struct {
unsigned short pirq;
unsigned short gsi;
- unsigned char vector;
unsigned char flags;
uint16_t domid;
} pirq;
@@ -211,7 +209,6 @@ static void xen_irq_info_pirq_init(unsig
unsigned short evtchn,
unsigned short pirq,
unsigned short gsi,
- unsigned short vector,
uint16_t domid,
unsigned char flags)
{
@@ -221,7 +218,6 @@ static void xen_irq_info_pirq_init(unsig
info->u.pirq.pirq = pirq;
info->u.pirq.gsi = gsi;
- info->u.pirq.vector = vector;
info->u.pirq.domid = domid;
info->u.pirq.flags = flags;
}
@@ -714,7 +710,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gs
goto out;
}
- xen_irq_info_pirq_init(irq, 0, pirq, gsi, irq_op.vector, DOMID_SELF,
+ xen_irq_info_pirq_init(irq, 0, pirq, gsi, DOMID_SELF,
shareable ? PIRQ_SHAREABLE : 0);
pirq_query_unmask(irq);
@@ -762,8 +758,7 @@ int xen_allocate_pirq_msi(struct pci_dev
}
int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc,
-int pirq, int vector, const char *name,
-domid_t domid)
+int pirq, const char *name, domid_t domid)
{
int irq, ret;
@@ -776,7 +771,7 @@ int xen_bind_pirq_msi_to_irq(struct pci_
irq_set_chip_and_handler_name(irq, _pirq_chip, handle_edge_irq,
name);
- xen_irq_info_pirq_init(irq, 0, pirq, 0, vector, domid, 0);
+ xen_irq_info_pirq_init(irq, 0, pirq, 0, domid, 0);
ret = irq_set_msi_desc(irq, msidesc);
if (ret < 0)
goto error_irq;
--- 3.9-rc5/include/xen/events.h
+++ 3.9-rc5-xen-irq-no-vector/include/xen/events.h
@@ -90,8 +90,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gs
int xen_allocate_pirq_msi(struct pci_dev *dev, struct msi_desc *msidesc);
/* Bind an PSI pirq to an irq. */
int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct msi_desc *msidesc,
-int pirq, int vector, const char *name,
-domid_t
[PATCH v9 08/14] clk: tegra: Add flags to tegra_clk_periph()
We will need some tegra peripheral clocks with the CLK_IGNORE_UNUSED flag,
most notably mselect, which is a bridge between AXI and most peripherals.
Signed-off-by: Peter De Schrijver
---
drivers/clk/tegra/clk-periph.c | 11 ++-
drivers/clk/tegra/clk-tegra20.c |2 +-
drivers/clk/tegra/clk-tegra30.c |2 +-
drivers/clk/tegra/clk.h |9 ++---
4 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/tegra/clk-periph.c b/drivers/clk/tegra/clk-periph.c
index 788486e..067abb3 100644
--- a/drivers/clk/tegra/clk-periph.c
+++ b/drivers/clk/tegra/clk-periph.c
@@ -170,14 +170,15 @@ const struct clk_ops tegra_clk_periph_nodiv_ops = {
static struct clk *_tegra_clk_register_periph(const char *name,
const char **parent_names, int num_parents,
struct tegra_clk_periph *periph,
- void __iomem *clk_base, u32 offset, bool div)
+ void __iomem *clk_base, u32 offset, bool div,
+ unsigned long flags)
{
struct clk *clk;
struct clk_init_data init;
init.name = name;
init.ops = div ? _clk_periph_ops : _clk_periph_nodiv_ops;
- init.flags = div ? 0 : CLK_SET_RATE_PARENT;
+ init.flags = flags;
init.parent_names = parent_names;
init.num_parents = num_parents;
@@ -202,10 +203,10 @@ static struct clk *_tegra_clk_register_periph(const char
*name,
struct clk *tegra_clk_register_periph(const char *name,
const char **parent_names, int num_parents,
struct tegra_clk_periph *periph, void __iomem *clk_base,
- u32 offset)
+ u32 offset, unsigned long flags)
{
return _tegra_clk_register_periph(name, parent_names, num_parents,
- periph, clk_base, offset, true);
+ periph, clk_base, offset, true, flags);
}
struct clk *tegra_clk_register_periph_nodiv(const char *name,
@@ -214,5 +215,5 @@ struct clk *tegra_clk_register_periph_nodiv(const char
*name,
u32 offset)
{
return _tegra_clk_register_periph(name, parent_names, num_parents,
- periph, clk_base, offset, false);
+ periph, clk_base, offset, false, CLK_SET_RATE_PARENT);
}
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index b6a747f..05c4995 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -1019,7 +1019,7 @@ static void __init tegra20_periph_clk_init(void)
data = _periph_clk_list[i];
clk = tegra_clk_register_periph(data->name, data->parent_names,
data->num_parents, >periph,
- clk_base, data->offset);
+ clk_base, data->offset, data->flags);
clk_register_clkdev(clk, data->con_id, data->dev_id);
clks[data->clk_id] = clk;
}
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 9c43bb4..7e749b0 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1668,7 +1668,7 @@ static void __init tegra30_periph_clk_init(void)
data = _periph_clk_list[i];
clk = tegra_clk_register_periph(data->name, data->parent_names,
data->num_parents, >periph,
- clk_base, data->offset);
+ clk_base, data->offset, data->flags);
clk_register_clkdev(clk, data->con_id, data->dev_id);
clks[data->clk_id] = clk;
}
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index 8cedb09..fd12b77 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -417,7 +417,7 @@ extern const struct clk_ops tegra_clk_periph_ops;
struct clk *tegra_clk_register_periph(const char *name,
const char **parent_names, int num_parents,
struct tegra_clk_periph *periph, void __iomem *clk_base,
- u32 offset);
+ u32 offset, unsigned long flags);
struct clk *tegra_clk_register_periph_nodiv(const char *name,
const char **parent_names, int num_parents,
struct tegra_clk_periph *periph, void __iomem *clk_base,
@@ -460,12 +460,14 @@ struct tegra_periph_init_data {
u32 offset;
const char *con_id;
const char *dev_id;
+ unsigned long flags;
};
#define TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parent_names, _offset,\
_mux_shift, _mux_mask, _mux_flags, _div_shift, \
_div_width, _div_frac_width, _div_flags, _regs, \
- _clk_num, _enb_refcnt, _gate_flags, _clk_id, _table) \
+ _clk_num, _enb_refcnt, _gate_flags, _clk_id, _table,\
+ _flags) \
{
[PATCH v3 10/12] ARM: tegra: harmony: Initialize PCIe from DT
With the device tree support in place, probe the PCIe controller from
the device tree and remove the corresponding workaround in the board
file.
Signed-off-by: Thierry Reding
---
arch/arm/boot/dts/tegra20-harmony.dts | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts
b/arch/arm/boot/dts/tegra20-harmony.dts
index 5fb0888..8799d7a 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -334,7 +334,7 @@
regulator-always-on;
};
- ldo0 {
+ pci_clk_reg: ldo0 {
regulator-name =
"vdd_ldo0,vddio_pex_clk";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
@@ -418,6 +418,20 @@
nvidia,invert-interrupt;
};
+ pcie-controller {
+ pex-clk-supply = <_clk_reg>;
+ vdd-supply = <_vdd_reg>;
+ status = "okay";
+
+ pci@1,0 {
+ status = "okay";
+ };
+
+ pci@2,0 {
+ status = "okay";
+ };
+ };
+
usb@c500 {
status = "okay";
};
@@ -601,7 +615,7 @@
enable-active-high;
};
- regulator@3 {
+ pci_vdd_reg: regulator@3 {
compatible = "regulator-fixed";
reg = <3>;
regulator-name = "vdd_1v05";
@@ -609,8 +623,6 @@
regulator-max-microvolt = <105>;
gpio = < 2 0>;
enable-active-high;
- /* Hack until board-harmony-pcie.c is removed */
- status = "disabled";
};
regulator@4 {
--
1.8.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 v3 08/12] ARM: tegra: tamonten: Add PCIe support
Add properties common to all Tamonten-derived boards to the Tamonten
DTSI and add the fixed 1.05 V regulator.
Signed-off-by: Thierry Reding
---
Changes in v2:
- add properties common to all Tamonten boards
- add fixed 1.05 V regulator
arch/arm/boot/dts/tegra20-tamonten.dtsi | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi
b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index 08cc557..020f7bc 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -438,7 +438,7 @@
regulator-always-on;
};
- ldo0 {
+ pci_clk_reg: ldo0 {
regulator-name =
"vdd_ldo0,vddio_pex_clk";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
@@ -533,6 +533,11 @@
nvidia,invert-interrupt;
};
+ pcie-controller {
+ pex-clk-supply = <_clk_reg>;
+ vdd-supply = <_vdd_reg>;
+ };
+
usb@c5008000 {
status = "okay";
};
@@ -558,5 +563,15 @@
regulator-max-microvolt = <500>;
regulator-always-on;
};
+
+ pci_vdd_reg: regulator@1 {
+ compatible = "regulator-fixed";
+ reg = <1>;
+ regulator-name = "vdd_1v05";
+ regulator-min-microvolt = <105>;
+ regulator-max-microvolt = <105>;
+ gpio = < 2 0>;
+ enable-active-high;
+ };
};
};
--
1.8.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 v3 12/12] ARM: tegra: Update default configuration (PCIe)
Enable PCI and MSI support as well as the new Tegra PCIe controller driver. Signed-off-by: Thierry Reding --- arch/arm/configs/tegra_defconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig index 2b42a2c..6cedaa1 100644 --- a/arch/arm/configs/tegra_defconfig +++ b/arch/arm/configs/tegra_defconfig @@ -26,8 +26,10 @@ CONFIG_GPIO_PCA953X=y CONFIG_ARCH_TEGRA_2x_SOC=y CONFIG_ARCH_TEGRA_3x_SOC=y CONFIG_ARCH_TEGRA_114_SOC=y -CONFIG_TEGRA_PCI=y CONFIG_TEGRA_EMC_SCALING_ENABLE=y +CONFIG_PCI=y +CONFIG_PCI_MSI=y +CONFIG_PCI_TEGRA=y CONFIG_SMP=y CONFIG_PREEMPT=y CONFIG_AEABI=y -- 1.8.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 v3 00/12] Rewrite Tegra PCIe driver
This patch series contains an almost complete rewrite of the Tegra PCIe driver. The code is moved to the drivers/pci/host directory and turned into a proper platform driver, adding MSI and DT support while at it. Other PCI host controller drivers can be added to that directory in an attempt to make it easier to factor out common code. Patches 1 to 3 add generic OF helpers to parse a PCI node's ranges property as well as obtain the device and function numbers from a node's reg property. Patch 4 introduces a new MSI chip infrastructure which is required to make multiple platform-specific implementations of the MSI support functions coexist peacefully. Patches 5 and 6 move some of the Tegra specific code around to allow it to be used from outside the arch/arm/mach-tegra directory. Patch 7 moves the Tegra PCIe controller driver to the drivers/pci/host directory and turns it into a proper platform driver. It also adds MSI (based on patches by NVIDIA) and DT support. Patches 8 to 11 add device tree based probing for the TEC, Harmony and TrimSlice boards. Finally the default configuration for Tegra is updated in patch 12. Thierry Andrew Murray (1): of/pci: Provide support for parsing PCI DT ranges property Thierry Reding (11): of/pci: Add of_pci_get_devfn() function of/pci: Add of_pci_parse_bus_range() function PCI: Introduce new MSI chip infrastructure ARM: tegra: Move tegra_pcie_xclk_clamp() to PMC ARM: tegra: Move pmc.h to include/linux/tegra-pmc.h PCI: tegra: Move PCIe driver to drivers/pci/host ARM: tegra: tamonten: Add PCIe support ARM: tegra: tec: Add PCIe support ARM: tegra: harmony: Initialize PCIe from DT ARM: tegra: trimslice: Initialize PCIe from DT ARM: tegra: Update default configuration (PCIe) .../bindings/pci/nvidia,tegra20-pcie.txt | 123 ++ arch/arm/boot/dts/tegra20-harmony.dts | 20 +- arch/arm/boot/dts/tegra20-tamonten.dtsi| 17 +- arch/arm/boot/dts/tegra20-tec.dts |8 + arch/arm/boot/dts/tegra20-trimslice.dts| 28 + arch/arm/boot/dts/tegra20.dtsi | 53 + arch/arm/configs/tegra_defconfig |4 +- arch/arm/mach-tegra/Kconfig|7 +- arch/arm/mach-tegra/Makefile |3 - arch/arm/mach-tegra/board-harmony-pcie.c | 89 -- arch/arm/mach-tegra/board.h|8 - arch/arm/mach-tegra/iomap.h|3 - arch/arm/mach-tegra/pcie.c | 886 --- arch/arm/mach-tegra/pmc.c | 16 + arch/arm/mach-tegra/tegra.c| 24 - arch/microblaze/pci/pci-common.c | 110 +- arch/mips/pci/pci.c| 50 +- arch/powerpc/kernel/pci-common.c | 99 +- drivers/of/address.c | 63 + drivers/of/of_pci.c| 59 +- drivers/pci/Kconfig|2 + drivers/pci/Makefile |3 + drivers/pci/host/Kconfig |8 + drivers/pci/host/Makefile |1 + drivers/pci/host/pci-tegra.c | 1560 drivers/pci/msi.c | 35 +- drivers/pci/probe.c|1 + include/linux/msi.h| 10 + include/linux/of_address.h | 42 + include/linux/of_pci.h |2 + include/linux/pci.h|1 + include/linux/tegra-pmc.h | 23 + 32 files changed, 2155 insertions(+), 1203 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt delete mode 100644 arch/arm/mach-tegra/board-harmony-pcie.c delete mode 100644 arch/arm/mach-tegra/pcie.c create mode 100644 drivers/pci/host/Kconfig create mode 100644 drivers/pci/host/Makefile create mode 100644 drivers/pci/host/pci-tegra.c create mode 100644 include/linux/tegra-pmc.h -- 1.8.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 v9 02/14] clk: tegra: Refactor PLL programming code
Refactor the PLL programming code to make it useable by the new PLL types
introduced by Tegra114.
The following changes were done:
* Split programming the PLL into updating m,n,p and updating cpcon
* Move locking from _update_pll_cpcon() to clk_pll_set_rate()
* Introduce _get_pll_mnp() helper
* Move check for identical m,n,p values to clk_pll_set_rate()
* struct tegra_clk_pll_freq_table will always contain the values as defined
by the hardware.
* Simplify the arguments to clk_pll_wait_for_lock()
* Split _tegra_clk_register_pll()
Signed-off-by: Peter De Schrijver
---
drivers/clk/tegra/clk-pll.c | 262 ---
drivers/clk/tegra/clk-tegra20.c | 144 +++---
drivers/clk/tegra/clk-tegra30.c | 234 +-
drivers/clk/tegra/clk.h |9 +-
4 files changed, 356 insertions(+), 293 deletions(-)
diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 165f247..3feefb1 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2012, NVIDIA CORPORATION. All rights reserved.
+ * Copyright (c) 2012, 2013, NVIDIA CORPORATION. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
@@ -113,20 +113,28 @@ static void clk_pll_enable_lock(struct tegra_clk_pll *pll)
pll_writel_misc(val, pll);
}
-static int clk_pll_wait_for_lock(struct tegra_clk_pll *pll,
-void __iomem *lock_addr, u32 lock_bit_idx)
+static int clk_pll_wait_for_lock(struct tegra_clk_pll *pll)
{
int i;
- u32 val;
+ u32 val, lock_bit;
+ void __iomem *lock_addr;
if (!(pll->flags & TEGRA_PLL_USE_LOCK)) {
udelay(pll->params->lock_delay);
return 0;
}
+ lock_addr = pll->clk_base;
+ if (pll->flags & TEGRA_PLL_LOCK_MISC)
+ lock_addr += pll->params->misc_reg;
+ else
+ lock_addr += pll->params->base_reg;
+
+ lock_bit = BIT(pll->params->lock_bit_idx);
+
for (i = 0; i < pll->params->lock_delay; i++) {
val = readl_relaxed(lock_addr);
- if (val & BIT(lock_bit_idx)) {
+ if (val & lock_bit) {
udelay(PLL_POST_LOCK_DELAY);
return 0;
}
@@ -155,7 +163,7 @@ static int clk_pll_is_enabled(struct clk_hw *hw)
return val & PLL_BASE_ENABLE ? 1 : 0;
}
-static int _clk_pll_enable(struct clk_hw *hw)
+static void _clk_pll_enable(struct clk_hw *hw)
{
struct tegra_clk_pll *pll = to_clk_pll(hw);
u32 val;
@@ -172,11 +180,6 @@ static int _clk_pll_enable(struct clk_hw *hw)
val |= PMC_PLLP_WB0_OVERRIDE_PLLM_ENABLE;
writel_relaxed(val, pll->pmc + PMC_PLLP_WB0_OVERRIDE);
}
-
- clk_pll_wait_for_lock(pll, pll->clk_base + pll->params->base_reg,
- pll->params->lock_bit_idx);
-
- return 0;
}
static void _clk_pll_disable(struct clk_hw *hw)
@@ -204,7 +207,9 @@ static int clk_pll_enable(struct clk_hw *hw)
if (pll->lock)
spin_lock_irqsave(pll->lock, flags);
- ret = _clk_pll_enable(hw);
+ _clk_pll_enable(hw);
+
+ ret = clk_pll_wait_for_lock(pll);
if (pll->lock)
spin_unlock_irqrestore(pll->lock, flags);
@@ -241,8 +246,6 @@ static int _get_table_rate(struct clk_hw *hw,
if (sel->input_rate == 0)
return -EINVAL;
- BUG_ON(sel->p < 1);
-
cfg->input_rate = sel->input_rate;
cfg->output_rate = sel->output_rate;
cfg->m = sel->m;
@@ -290,88 +293,109 @@ static int _calc_rate(struct clk_hw *hw, struct
tegra_clk_pll_freq_table *cfg,
cfg->output_rate <<= 1)
p_div++;
- cfg->p = 1 << p_div;
+ cfg->p = p_div;
cfg->m = parent_rate / cfreq;
cfg->n = cfg->output_rate / cfreq;
cfg->cpcon = OUT_OF_TABLE_CPCON;
if (cfg->m > divm_max(pll) || cfg->n > divn_max(pll) ||
- cfg->p > divp_max(pll) || cfg->output_rate > pll->params->vco_max) {
+ (1 << p_div) > divp_max(pll)
+ || cfg->output_rate > pll->params->vco_max) {
pr_err("%s: Failed to set %s rate %lu\n",
__func__, __clk_get_name(hw->clk), rate);
return -EINVAL;
}
+ if (pll->flags & TEGRA_PLLU)
+ cfg->p ^= 1;
+
return 0;
}
-static int _program_pll(struct clk_hw *hw, struct tegra_clk_pll_freq_table
*cfg,
- unsigned long rate)
+static void _update_pll_mnp(struct tegra_clk_pll *pll,
+ struct tegra_clk_pll_freq_table *cfg)
{
- struct tegra_clk_pll *pll = to_clk_pll(hw);
- unsigned long flags = 0;
- u32 divp, val,
