Re: [PATCH 2/9] perf, tools: Add support for text descriptions of events and alias add
Hi Andi, On Mon, 9 Jun 2014 18:52:45 +0200, Andi Kleen wrote: >> Hmm.. this will print the description at right side and I think it'd be >> better if it prints in another line(s) like below: > > I think it's better to show the descriptions by default without > an extra option. I suspect most people want to see them, or if they > need them they won't know about obscure -v options. I partially agree, but I guess adding -v option to the command is not that hard for them. :) Maybe we could add a message in order to advise users to use -v option for description like below: $ perf list # Use -v/--verbose to see event description (if exists) ... > >> >> agu_bypass_cancel.count[Kernel PMU event] >> This event counts executed load operations with all the following >> traits: 1. addressing of the format [base + offset], 2. the offset >> is between 1 and 2047, 3. the address specified in the base register >> is in one page and the address [base+offset] is in an > > The problem with this format is that it is not compatible, so it would > break existing parsers that look at perf list output. That is why I ended up > with the right side format. Hmm.. I think existing parsers should not use -v option then. The perf list was for listing only event names (and their types). I think the main problem of the right side format is that it hurts readability especially on small screens/terminals. Thanks, Namhyung > > >> arith.fpu_div [Kernel PMU event] >> Divide operations executed >> arith.fpu_div_active [Kernel PMU event] >> Cycles when divider is busy executing divide operations >> ... >> >> >> I just tweaked it using -v option for perf list. Below is the change I >> made on top of your series. What do you think? > > I prefer not to apply that patch. > > I guess what could make sense is a quiet option to not print > descriptions. > > -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 08/42] x86, ACPI, irq: enhance error handling in function acpi_register_gsi()
On 2014/6/10 7:19, Thomas Gleixner wrote:
> On Mon, 9 Jun 2014, Jiang Liu wrote:
>
>> Function mp_register_gsi() may return invalid GSI if error happens,
>> so enhance acpi_register_gsi() to handle possible error cases.
>
> Can you please explain how that happens? I think I know it, but it'd
> be nice if it would be documented.
Sure.
>
>> Signed-off-by: Jiang Liu
>> ---
>> arch/x86/kernel/acpi/boot.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
>> index 392360c607dc..f201579cd0df 100644
>> --- a/arch/x86/kernel/acpi/boot.c
>> +++ b/arch/x86/kernel/acpi/boot.c
>> @@ -97,6 +97,8 @@ static u32 isa_irq_to_gsi[NR_IRQS_LEGACY] __read_mostly = {
>> 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
>> };
>>
>> +#define ACPI_INVALID_GSIINT_MIN
>> +
>> static unsigned int gsi_to_irq(unsigned int gsi)
>> {
>> unsigned int irq = gsi + NR_IRQS_LEGACY;
>> @@ -441,7 +443,7 @@ static int mp_register_gsi(struct device *dev, u32 gsi,
>> int trigger,
>> polarity == ACPI_ACTIVE_HIGH ? 0 : 1);
>> ret = io_apic_set_pci_routing(dev, gsi_to_irq(gsi), _attr);
>> if (ret < 0)
>> -gsi = INT_MIN;
>> +gsi = ACPI_INVALID_GSI;
>>
>> return gsi;
>> }
>> @@ -666,13 +668,13 @@ int (*acpi_suspend_lowlevel)(void);
>> */
>> int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int
>> polarity)
>> {
>> -unsigned int irq;
>> unsigned int plat_gsi = gsi;
>
> The assignemend of gsi to plat_gsi is pointless
This was done in patch 21. And eventually function acpi_register_gsi()
will be simplified as below by patch 21 and 22.
int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int
polarity)
{
return (*__acpi_register_gsi)(dev, gsi, trigger, polarity);
}
I will rework and resend patch 8, 21 and 22.
>
>> plat_gsi = (*__acpi_register_gsi)(dev, gsi, trigger, polarity);
>
> __acpi_register_gsi is a function pointer, so
>
> plat_gsi = __acpi_register_gsi(dev, gsi, trigger, polarity);
>
> is completely correct and way simpler to read.
Thanks, will change to the simpler way.
>
>> -irq = gsi_to_irq(plat_gsi);
>> +if (plat_gsi != ACPI_INVALID_GSI)
>> +return gsi_to_irq(plat_gsi);
>>
>> -return irq;
>> +return -1;
>> }
>> EXPORT_SYMBOL_GPL(acpi_register_gsi);
>
> No need to repost the whole series. Just reply with a new version to
> this.
>
> Thanks,
>
> tglx
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/42] x86, ioapic: kill static variable nr_irqs_gsi
Hi Thomas,
This piece of code is inherited from current IOAPIC driver
and I think it's a workaround for some weird platforms.
For normal platforms with both 8259A and IOAPIC controllers,
legacy ISA IRQs should be connected to both 8259A and IOAPIC pins
(ignore timer and cascade IRQs for simplicity). According to comments
in current kernel, there are some platforms on which:
1) some ISA IRQs are only connected to 8259A controllers.
2) the corresponding IOAPIC pins are connected to some non-ISA IRQs.
For such platforms, IRQ0-15 are used for ISA IRQs and another
16 IRQs just above gsi_top are reserved for IOAPIC pins 0-15 which
are connected to non-ISA IRQs.
I have no real experience with such a platform, but just
guessing possible cases according to kernel comments and "Multiple
Processor Specification". Please look at these two pictures for quick
reference.
http://www.manualslib.com/manual/77733/Intel-Multiprocessor.html?page=31#manual
http://www.manualslib.com/manual/77733/Intel-Multiprocessor.html?page=63#manual
Thanks!
Gerry
On 2014/6/10 7:22, Thomas Gleixner wrote:
> On Mon, 9 Jun 2014, Jiang Liu wrote:
>> unsigned int arch_dynirq_lower_bound(unsigned int from)
>> {
>> -return from < nr_irqs_gsi ? nr_irqs_gsi : from;
>> +unsigned int min = gsi_top + NR_IRQS_LEGACY;
>
> Why is this gsi_top + NR_IRQ_LEGACY? The legacy interrupts are part of
> the gsi space, aren't they?
>
> Thanks,
>
> tglx
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] cpufreq: intel_pstate: Remove redundant includes
On 10 June 2014 02:30, Stratos Karafotis wrote: > Also put them in alphabetical order. > > Signed-off-by: Stratos Karafotis > --- > drivers/cpufreq/intel_pstate.c | 17 ++--- > 1 file changed, 2 insertions(+), 15 deletions(-) > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > index 26a0262..d4f0518 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -10,26 +10,13 @@ > * of the License. > */ > > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > -#include > +#include > #include > #include > -#include > -#include > -#include > #include > -#include > +#include > #include > > -#include > -#include > #include As a rule, header files for all the symbols directly used by a file must be included directly by the file and must not depend on indirect inclusions. So even if it compiles, its the wrong thing to do. Though you can obviously remove the headers which aren't used. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/7] cpufreq: intel_pstate: Simplify code in intel_pstate_adjust_busy_pstate
On 10 June 2014 02:30, Stratos Karafotis wrote:
> Simplify the code by removing the inline functions
> pstate_increase and pstate_decrease and use directly the
> intel_pstate_set_pstate.
>
> Signed-off-by: Stratos Karafotis
> ---
> drivers/cpufreq/intel_pstate.c | 26 +++---
> 1 file changed, 3 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 3a49269..26a0262 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -588,21 +588,6 @@ static void intel_pstate_set_pstate(struct cpudata *cpu,
> int pstate)
> pstate_funcs.set(cpu, pstate);
> }
>
> -static inline void intel_pstate_pstate_increase(struct cpudata *cpu, int
> steps)
> -{
> - int target;
> - target = cpu->pstate.current_pstate + steps;
> -
> - intel_pstate_set_pstate(cpu, target);
> -}
> -
> -static inline void intel_pstate_pstate_decrease(struct cpudata *cpu, int
> steps)
> -{
> - int target;
> - target = cpu->pstate.current_pstate - steps;
> - intel_pstate_set_pstate(cpu, target);
> -}
> -
> static void intel_pstate_get_cpu_pstates(struct cpudata *cpu)
> {
> cpu->pstate.min_pstate = pstate_funcs.get_min();
> @@ -695,20 +680,15 @@ static inline void intel_pstate_calc_scaled_busy(struct
> cpudata *cpu)
> static inline void intel_pstate_adjust_busy_pstate(struct cpudata *cpu)
> {
> struct _pid *pid;
> - signed int ctl = 0;
> - int steps;
> + signed int ctl;
>
> pid = >pid;
> intel_pstate_calc_scaled_busy(cpu);
>
> ctl = pid_calc(pid, cpu->sample.busy_scaled);
>
> - steps = abs(ctl);
> -
> - if (ctl < 0)
> - intel_pstate_pstate_increase(cpu, steps);
> - else
> - intel_pstate_pstate_decrease(cpu, steps);
> + /* Negative values of ctl increase the pstate and vice versa */
> + intel_pstate_set_pstate(cpu, cpu->pstate.current_pstate - ctl);
> }
I am not very good at this driver but there is some obvious functional
change here. Earlier we used to pass
'cpu->pstate.current_pstate {-|+} steps' and now you are doing '-ctl' only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/16 v3] A new CPU load metric for power-efficient scheduler: CPU ConCurrency
On Mon, Jun 09, 2014 at 05:48:48PM +0100, Morten Rasmussen wrote:
Thanks, Morten.
> > 2) CC vs. CPU utilization. CC is runqueue-length-weighted CPU utilization.
> > If
> > we change: "a = sum(concurrency * time) / period" to "a' = sum(1 * time) /
> > period". Then a' is just about the CPU utilization. And the way we weight
> > runqueue-length is the simplest one (excluding the exponential decays, and
> > you
> > may have other ways).
>
> Isn't a' exactly to the rq runnable_avg_{sum, period} that you remove in
> patch 1? In that case it seems more obvious to repurpose them by
> multiplying the the contributions to the rq runnable_avg_sum by
> nr_running. AFAICT, that should give you the same metric.
>
Yes, essentially it is. Removing it is simply because rq runnable_avg_X is not
used.
And yes, by repurposing it, I can get CC, in that sense what I do is replacing
it
not just removing it, :)
> On the other hand, I don't see what this new metric gives us that can't
> be inferred from the existing load tracking metrics or through slight
> modifications of those. It came up recently in a different thread that
> the tracked task load is heavily influenced by other tasks running on
> the same cpu if they happen to overlap in time. IIUC, that exactly the
> information you are after. I think you could implement the same task
> packing behaviour based on an unweighted version of
> cfs.runnable_load_avg instead, which should be fairly straightforward to
> introduce (I think it will become useful for other purposes as well). I
> sort of hinted that in that thread already:
>
> https://lkml.org/lkml/2014/6/4/54
>
Yes, it seems an unweighted cfs.runnable_load_avg should be similar to what CC
is.
I have been thinking about and working on this.
My work in this regard is in the middle. One of my concerns is how sum and
period
accrue with time, and how contrib is calculated (for both entity and rq
runnable).
Resultingly, the period is "always" around 48000, and it takes sum a long time
to
reflect the latest activity (IIUC, you also pointed this out). For balancing,
this
might not be a problem, but for consolidating, we need much more sensitivity.
I don't know, but anyway, I will solve this/give a good reason (as is also
required by PeterZ).
>
> The potential worst case consolidated CC sum is:
>
> n * \sum{cpus}^{n} CC[n]
>
> So, the range in which the true consolidated CC lies grows
> proportionally to the number of cpus. We can't really say anything about
> how things will pan out if we consolidate on fewer cpus. However, if it
> turns out to be a bad mix of tasks the task runnable_avg_sum will go up
> and if we use cfs.runnable_load_avg as the indication of compute
> capacity requirements, we would eventually spread the load again.
> Clearly, we don't want an unstable situation, so it might be better to
> the consolidation partially and see where things are going.
>
No. The current load balancing is all done by pulling, and Workload
Consolidation
will prevent the pulling when consolidated, that said, the current load
balancing (effectively) can/will not act in the opposite direction of
Workload Consolidation at the same time.
Is that what you are concerned?
> > So, we uniformly use this condition for consolidation (suppose
> > we consolidate m CPUs to n CPUs, m > n):
> >
> > (CC[0] + CC[1] + ... + CC[m-2] + CC[m-1]) * (n + log(m-n)) >= > *
> > consolidating_coefficient
>
> Do you have a rationale behind this heuristic? It seems to be more and
> more pessimistic about how much load we can put on 'n' cpus as 'm'
> increases. Basically trying to factor in some of the error that be in
> the consolidated CC. Why the '(1 * n) * n...' and not just 'n * n * con...'?
>
The rationale is: the more CPUs, the less likely they are concurrently running
(coscheduled), especially when load is not high and transient (this is when we
want to consolidate). So we go toward more optimistic for large m to small n,
exponentially by log.
> Overall, IIUC, the aim of this patch set seems quite similar to the
> previous proposals for task packing.
>
Ok. So I did not do a weird thing, that is good, :) and help me do it together
since we all want it.
Thanks,
Yuyang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [for-next][PATCH 6/6] tracing: Fix leak of ring buffer data when new instances creation fails
On Fri, 06 Jun 2014 12:30:40 -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)"
>
> Yoshihiro Yunomae reported that the ring buffer data for a trace
> instance does not get properly cleaned up when it fails. He proposed
> a patch that manually cleaned the data up and addad a bunch of labels.
> The labels are not needed because all trace array is allocated with
> a kzalloc which initializes it to 0 and all kfree()s can take a NULL
> pointer and will ignore it.
>
> Adding a new helper function free_trace_buffers() that can also take
> null buffers to free the buffers that were allocated by
> allocate_trace_buffers().
>
> Link: http://lkml.kernel.org/r/20140605223522.32311.31664.stgit@yunodevel
>
> Reported-by: Yoshihiro YUNOMAE
> Signed-off-by: Steven Rostedt
> ---
> kernel/trace/trace.c | 22 --
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index e29edee1542a..26cfff38e2ab 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -6232,6 +6232,25 @@ static int allocate_trace_buffers(struct trace_array
> *tr, int size)
> return 0;
> }
>
> +static void free_trace_buffers(struct trace_array *tr)
> +{
> + if (!tr)
> + return;
> +
> + if (tr->trace_buffer.buffer) {
> + ring_buffer_free(tr->trace_buffer.buffer);
> + tr->trace_buffer.buffer = NULL;
> + free_percpu(tr->trace_buffer.data);
> + }
> +
> +#ifdef CONFIG_TRACER_MAX_TRACE
> + if (tr->max_buffer.buffer) {
> + ring_buffer_free(tr->max_buffer.buffer);
> + tr->max_buffer.buffer = NULL;
Hmm.. why doesn't it free tr->max_buffer.data here? And I think it's
better to reset *_buffer.data to NULL also - maybe by adding another
helper function free_trace_buffer()..
Thanks,
Namhyung
> + }
> +#endif
> +}
> +
> static int new_instance_create(const char *name)
> {
> struct trace_array *tr;
> @@ -6290,8 +6309,7 @@ static int new_instance_create(const char *name)
> return 0;
>
> out_free_tr:
> - if (tr->trace_buffer.buffer)
> - ring_buffer_free(tr->trace_buffer.buffer);
> + free_trace_buffers(tr);
> free_cpumask_var(tr->tracing_cpumask);
> kfree(tr->name);
> kfree(tr);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/16 v3] Init Workload Consolidation flags in sched_domain
On Mon, Jun 09, 2014 at 06:56:17PM +0100, Dietmar Eggemann wrote: Thanks, Dietmar. > I'm running these patches on my ARM TC2 on top of > kernel/git/torvalds/linux.git (v3.15-rc7-79-gfe45736f4134). There're > considerable changes in the area of sched domain setup since Vincent's > patchset 'rework sched_domain topology description' (destined for v3.16) > which you can find on kernel/git/tip/tip.git . > Yeah, PeterZ pointed it out. It was on top of mainline not tip. > Why did you make SD_WORKLOAD_CONSOLIDATION controllable via sysctl? All > the other SD flags are set during setup. > I don't understand. Any flag or parameter in sched_domain can be modified on-the-fly after booting via sysctl. The SD_XXX_INIT is a template to make the sched_domain initialization easier, IIUC. Yes, I should not unconditionally enable SD_WORKLOAD_CONSOLIDATION in MC and CPU domain (pointed out by PeterZ), but I did so for the purpose of testing this patchset at this moment. Eventually, this flag should not be turned on for any domain by default for many reasons, not to mention CPU topology is getting more diverse/complex. I just checked Vincent's "rework sched_domain topology description". The general picture for init sched_domain does not change. If you work on top of tip tree, you can simply skip this patch (0007), and after booting enable SD_WORKLOAD_CONSOLIDATION by: sysctl -w kernel.sched_domain.cpuX.domainY.flags += 0x8000 sysctl -w kernel.sched_domain.cpu0.domain1.consolidating_coeff=180 sysctl -w kernel.sched_cc_wakeup_threshold=80 > Your top_flag_domain() function > takes care of figuring out what is the highest sd level this is set on > during load-balance but I can't find any good reason to do it this way > other then for testing purposes? Any flag is used for testing whether it is set on or not when encountering it, including the flags in sched_domain for load balancing, this is why flag is called flag. My flag is any excpetion? Thanks, Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/7] cpufreq: intel_pstate: Remove duplicate CPU ID check
On 10 June 2014 02:30, Stratos Karafotis wrote:
> We check the CPU ID during driver init. There is no need
> to do it again per logical CPU initialization.
>
> So, remove the duplicate check.
>
> Signed-off-by: Stratos Karafotis
> ---
> drivers/cpufreq/intel_pstate.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index aebd457..4e7f492 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -691,14 +691,8 @@ MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids);
>
> static int intel_pstate_init_cpu(unsigned int cpunum)
> {
> -
> - const struct x86_cpu_id *id;
> struct cpudata *cpu;
>
> - id = x86_match_cpu(intel_pstate_cpu_ids);
> - if (!id)
> - return -ENODEV;
> -
> all_cpu_data[cpunum] = kzalloc(sizeof(struct cpudata), GFP_KERNEL);
> if (!all_cpu_data[cpunum])
> return -ENOMEM;
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [for-next][PATCH 4/6] tracing: Return error if ftrace_trace_arrays list is empty
On Fri, 06 Jun 2014 12:30:38 -0400, Steven Rostedt wrote:
> From: Yoshihiro YUNOMAE
>
> ftrace_trace_arrays links global_trace.list. However, global_trace
> is not added to ftrace_trace_arrays if trace_alloc_buffers() failed.
> As the result, ftrace_trace_arrays becomes an empty list. If
> ftrace_trace_arrays is an empty list, current top_trace_array() returns
> an invalid pointer. As the result, the kernel can induce memory corruption
> or panic.
>
> Current implementation does not check whether ftrace_trace_arrays is empty
> list or not. So, in this patch, if ftrace_trace_arrays is empty list,
> top_trace_array() returns NULL. Moreover, this patch makes all functions
> calling top_trace_array() handle it appropriately.
[SNIP]
> @@ -252,6 +252,9 @@ static inline struct trace_array *top_trace_array(void)
> {
> struct trace_array *tr;
>
> + if (list_empty(ftrace_trace_arrays.prev))
> + return NULL;
It looks weird to me.. why not checking "list_empty(_trace_arrays)"?
Thanks,
Namhyung
> +
> tr = list_entry(ftrace_trace_arrays.prev,
> typeof(*tr), list);
> WARN_ON(!(tr->flags & TRACE_ARRAY_FL_GLOBAL));
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Change in security maintainer for a few weeks
On Thu, 5 Jun 2014, Greg KH wrote: > Hi all, > > James has had to step back from doing kernel work for a few weeks, so > I've offered to step up and handle the security patches to get shuttled > to Linus for merging for a while. > > I'll take his git tree on kernel.org and push those to Linus for > 3.16-rc1, as those look like they have had proper testing in linux-next. > > But there only seems to be 14 patches in there. Are there pending > patches that people have been sending and need to get in besides those? > Thanks for stepping up. I had to take urgent leave and was unable to access email until this week. We really should have a co-maintainer for the security subsystem -- please feel free to nominate someone. There are several good candidates, including Serge, Kees and Paul Moore. - James -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [for-next][PATCH 3/6] tracing: Only calculate stats of tracepoint benchmarks for 2^32 times
Hi Steve,
On Fri, 06 Jun 2014 12:30:37 -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)"
>
> When calculating the average and standard deviation, it is required that
> the count be less than UINT_MAX, otherwise the do_div() will get
> undefined results. After 2^32 counts of data, the average and standard
> deviation should pretty much be set anyway.
[SNIP]
> if (bm_cnt > 1) {
> /*
>* Apply Welford's method to calculate standard deviation:
>* s^2 = 1 / (n * (n-1)) * (n * \Sum (x_i)^2 - (\Sum x_i)^2)
>*/
> stddev = (u64)bm_cnt * bm_totalsq - bm_total * bm_total;
> - do_div(stddev, bm_cnt);
> - do_div(stddev, bm_cnt - 1);
> + do_div(stddev, (u32)bm_cnt);
> + do_div(stddev, (u32)bm_cnt - 1);
> } else
> stddev = 0;
I also think that this if-else can go as it checks bm_cnt == 1 above.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 Resend] cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATOR
cpufreq-cpu0 uses thermal framework to register a cooling device, but doesn't depend on it as there are dummy calls provided by thermal layer when CONFIG_THERMAL=n. And when these calls fail, the driver is still usable. Similar explanation is valid for regulators as well. We do have dummy calls available for regulator APIs and the driver can work even when those calls fail. So, we don't really need to mention thermal and regulators as a dependency for cpufreq-cpu0 in Kconfig as platforms without support for thermal/regulator can also use this driver. Remove this dependency. Signed-off-by: Viresh Kumar --- Rafael, The dependency patches from regulators core are already pushed to Linus's tree and so this patch can go in now. drivers/cpufreq/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 1fbe11f..e473d65 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -185,7 +185,7 @@ config CPU_FREQ_GOV_CONSERVATIVE config GENERIC_CPUFREQ_CPU0 tristate "Generic CPU0 cpufreq driver" - depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL + depends on HAVE_CLK && OF select PM_OPP help This adds a generic cpufreq driver for CPU0 frequency management. -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 15/15] perf tools: Support spark lines in perf stat
* Jiri Olsa wrote: > From: Andi Kleen > > perf stat -rX prints the stddev for multiple measurements. Call it "--repeat X", that's how most people know it. > Just looking at the stddev for judging the quality of the data > is a bit dangerous The simplest sanity check is to just look "Dangerous?". Unexplained FUD. Also a missing perid. > at a simple plot. This patchs add a sparkline to the end > of the measurements to make it simple to judge the data. Should explain what a 'sparkline' is when it's first mentioned, not 2 sentences later. > The sparkline only uses UTF-8, so should be readable > in all modern tools and terminals. > > The sparkline is between the minimum and maximum of the data, > so it's mainly a indicator of variance. To keep the code > simple and make the output not too wide only the first > 8 values are printed. If more values are there it adds '..' > > The code is inspired by Zach Holman's spark shell script. Zach Holman should be on Cc:. > Example output (view in non-proportial font): > > Performance counter stats for 'true' (10 runs): > > 0.175672 task-clock (msec) #0.555 CPUs utilized > ( +- 1.77% ) █▄▁▁.. > 0 context-switches #0.000 K/sec > 0 cpu-migrations#0.000 K/sec >114 page-faults #0.647 M/sec > ( +- 0.14% ) ▁█▁▁.. >520,798 cycles#2.965 GHz > ( +- 1.75% ) █▄▁▁.. >433,525 instructions #0.83 insns per cycle > ( +- 0.28% ) ▅▇▅▄▇█▁▆.. > 83,012 branches # 472.537 M/sec > ( +- 0.31% ) ▅▇▆▄▇█▁▆.. > 3,157 branch-misses #3.80% of all branches > ( +- 2.55% ) ▇█▃▅▁▃▁▂.. > >0.000316660 seconds time elapsed >( +- 1.78% ) █▅▁▁.. The noise data is not aligned vertically in the changelog - is it in the real code? It should be. > As you can see even in the most simple run there are quite > interesting patterns. The time sparkline suggests it would be also > useful to have an option to throw the first measurement away. First two should be thrown away, probably, to reduce the resulting stddev. > Known issues: > - Makes the perf stat output wider. Could be adjust by shrinking > some white space. Not done so far. > - No output for -A/--per-socket/--per-core with -rX. This code > is missing the basic noise detection code. Once it's added there > sparklines could be shown too. The feauture looks useful, but at minimum the second shortcoming should be fixed first in a separate patch, before applying new features and further complicating the code. > Signed-off-by: Andi Kleen > Link: > http://lkml.kernel.org/r/1401838086-17750-1-git-send-email-a...@firstfloor.org > Signed-off-by: Jiri Olsa > --- > tools/perf/Documentation/perf-stat.txt | 4 > tools/perf/Makefile.perf | 1 + > tools/perf/builtin-stat.c | 12 > tools/perf/util/spark.c| 31 +++ > tools/perf/util/spark.h| 4 > tools/perf/util/stat.c | 34 > ++ > tools/perf/util/stat.h | 10 ++ > 7 files changed, 96 insertions(+) > create mode 100644 tools/perf/util/spark.c > create mode 100644 tools/perf/util/spark.h > > diff --git a/tools/perf/Documentation/perf-stat.txt > b/tools/perf/Documentation/perf-stat.txt > index 29ee857..840c1db 100644 > --- a/tools/perf/Documentation/perf-stat.txt > +++ b/tools/perf/Documentation/perf-stat.txt > @@ -53,6 +53,10 @@ OPTIONS > -r:: > --repeat=:: > repeat command and print average + stddev (max: 100). 0 means forever. > + In addition it prints a spark line (when not in CSV mode), which > visualizes the > + variance between minimum and maximum of the measurements. This allows a > simple sanity > + check of the measurements. Only 8 values are printed, when more are > available > + it adds .. > > -B:: > --big-num:: > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf > index 9670a16..90b3aa7 100644 > --- a/tools/perf/Makefile.perf > +++ b/tools/perf/Makefile.perf > @@ -359,6 +359,7 @@ LIB_OBJS += $(OUTPUT)util/trace-event-scripting.o > LIB_OBJS += $(OUTPUT)util/trace-event.o > LIB_OBJS += $(OUTPUT)util/svghelper.o > LIB_OBJS += $(OUTPUT)util/sort.o > +LIB_OBJS += $(OUTPUT)util/spark.o > LIB_OBJS += $(OUTPUT)util/hist.o > LIB_OBJS += $(OUTPUT)util/probe-event.o > LIB_OBJS += $(OUTPUT)util/util.o > diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c > index 65a151e..cb0f7c5 100644 > --- a/tools/perf/builtin-stat.c > +++ b/tools/perf/builtin-stat.c > @@ -1176,6 +1176,9 @@ static void
Re: [PATCHv4 00/13] perf tools: Speedup DWARF unwind
Hi Jiri, On Wed, 4 Jun 2014 16:36:49 +0200, Jiri Olsa wrote: > hi, > trying to speedup DWARF unwind report code by factoring > related code: > - caching sample's registers access > - keep dso data file descriptor open for the > life of the dso object > - replace dso cache code by mapping dso data file > directly for the life of the dso object > > The speedup is mainly for libunwind unwind. The libdw will benefit > mainly from cached registers access, because it handles dso data > accesses by itself.. and anyway it's still faster ;-). > > On ~11GB perf data file with dwarf unwind data I've got > around 30% speed up. > > I've also got possitive test feedback from Jean Pihet: > > https://wiki.linaro.org/LEG/Engineering/TOOLS/perf-callstack-unwinding#Speed_improvement For the series, Acked-by: Namhyung Kim Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
MESSAGE FROM JAZMIN FOX FIN AID
-- Are you in need of a personal loan? or you are in need of a business loan? We offer loans from the range individual and cooperate bodies in need of financial support are application? only about 18 years for the applicant available. contact us by e-mail, though. onto a fast and easy loan interested in a low and affordable interest rate of 3% Interested applicants are required to this form below and send it back to us: Full Name: .. Consumption: . Loan Terms / Duration: ... Country: State: Occupation: .. Gender: Address: . Phone Number: We hope to hear from you soon so that we can send you the Credit Terms and repayment schedule. Be assured that the possibility of a loan from our company is extremely Guaranteed. Regards Jazmin Fox Fin Aid jazminfoxfin...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH Resend] cpufreq: tegra: update comment for clarity
Tegra's driver got updated a bit (00917dd cpufreq: Tegra: implement intermediate frequency callbacks) and implements new 'intermediate freq' infrastructure of core. Above commit updated comments about when to call clk_prepare_enable(pll_x_clk) and Doug wasn't satisfied with those comments and said this: > The "Though when target-freq is intermediate freq, we don't need to > take this reference." makes me think that this function is actually > called when target-freq is intermediate freq. I don't think it is, > right? For better clarity just make that comment more explicit about when we call tegra_target_intermediate(). Reviewed-by: Stephen Warren Reported-and-reviewed-by: Doug Anderson Signed-off-by: Viresh Kumar --- Resend: Improved comment as suggested by Stephen. drivers/cpufreq/tegra-cpufreq.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra-cpufreq.c index a5fbc0a..8084c7f 100644 --- a/drivers/cpufreq/tegra-cpufreq.c +++ b/drivers/cpufreq/tegra-cpufreq.c @@ -71,9 +71,12 @@ static int tegra_target_intermediate(struct cpufreq_policy *policy, /* * Take an extra reference to the main pll so it doesn't turn * off when we move the cpu off of it as enabling it again while we -* switch to it from tegra_target() would take additional time. Though -* when target-freq is intermediate freq, we don't need to take this -* reference. +* switch to it from tegra_target() would take additional time. +* +* When target-freq is equal to intermediate freq we don't need to +* switch to an intermediate freq and so this routine isn't called. +* Also, we wouldn't be using pll_x anymore and must not take extra +* reference to it, as it can be disabled now to save some power. */ clk_prepare_enable(pll_x_clk); -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] blk-mq: kick requeue list in blk_mq_requeue_request()
blk_mq_requeue_request() should kick off the requeue list so that the request can be scheduled to queue finally. In nvme conversion patch, blk_mq_requeue_request() is called to requeue failed request from completion handler, this patch fixes the issue and makes the block API working as expected. Cc: Matias Bjørling Cc: Christoph Hellwig Signed-off-by: Ming Lei --- block/blk-mq.c |1 + 1 file changed, 1 insertion(+) diff --git a/block/blk-mq.c b/block/blk-mq.c index cb4c785..4c78539 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -462,6 +462,7 @@ void blk_mq_requeue_request(struct request *rq) BUG_ON(blk_queued_rq(rq)); blk_mq_add_to_requeue_list(rq, true); + blk_mq_kick_requeue_list(rq->q); } EXPORT_SYMBOL(blk_mq_requeue_request); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] watchdog: dw_wdt: Remove the un-necessary check after platform_get_resource()
devm_ioremap_resource() checks for valid resource. Remove the un-necessary check after platform_get_resource(). Signed-off-by: George Cherian --- drivers/watchdog/dw_wdt.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c index ee4f86b..9f21029 100644 --- a/drivers/watchdog/dw_wdt.c +++ b/drivers/watchdog/dw_wdt.c @@ -296,9 +296,6 @@ static int dw_wdt_drv_probe(struct platform_device *pdev) int ret; struct resource *mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!mem) - return -EINVAL; - dw_wdt.regs = devm_ioremap_resource(>dev, mem); if (IS_ERR(dw_wdt.regs)) return PTR_ERR(dw_wdt.regs); -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] watchdog: shwdt: Remove the unnecessary check of resource after platform_get_resource()
devm_ioremap_resource check for a valid resource. Remove the unnecessary check. Also group platform_get_resource and devm_ioremap_resource together for better readability. Signed-off-by: George Cherian --- drivers/watchdog/shwdt.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/watchdog/shwdt.c b/drivers/watchdog/shwdt.c index d04d02b..08205d7 100644 --- a/drivers/watchdog/shwdt.c +++ b/drivers/watchdog/shwdt.c @@ -230,10 +230,6 @@ static int sh_wdt_probe(struct platform_device *pdev) if (pdev->id != -1) return -EINVAL; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (unlikely(!res)) - return -EINVAL; - wdt = devm_kzalloc(>dev, sizeof(struct sh_wdt), GFP_KERNEL); if (unlikely(!wdt)) return -ENOMEM; @@ -249,6 +245,7 @@ static int sh_wdt_probe(struct platform_device *pdev) wdt->clk = NULL; } + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); wdt->base = devm_ioremap_resource(wdt->dev, res); if (IS_ERR(wdt->base)) return PTR_ERR(wdt->base); -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] watchdog: lantiq_wdt: Remove the un-necessary check of resource after platform_get_resource()
devm_ioremap_resource() checks for valid resource.
Remove the un-necessary check after platform_get_resource().
Signed-off-by: George Cherian
---
drivers/watchdog/lantiq_wdt.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/watchdog/lantiq_wdt.c b/drivers/watchdog/lantiq_wdt.c
index 3b3148c..021e84e 100644
--- a/drivers/watchdog/lantiq_wdt.c
+++ b/drivers/watchdog/lantiq_wdt.c
@@ -192,11 +192,6 @@ ltq_wdt_probe(struct platform_device *pdev)
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
struct clk *clk;
- if (!res) {
- dev_err(>dev, "cannot obtain I/O memory region");
- return -ENOENT;
- }
-
ltq_wdt_membase = devm_ioremap_resource(>dev, res);
if (IS_ERR(ltq_wdt_membase))
return PTR_ERR(ltq_wdt_membase);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mm,x86: warning at arch/x86/mm/pat.c:781 untrack_pfn+0x65/0xb0()
On Sat, 7 Jun 2014, Sasha Levin wrote: > On 04/11/2014 08:50 AM, Sasha Levin wrote: > > Hi all, > > > > While fuzzing with trinity inside a KVM tools guest running the latest -next > > kernel I've stumbled on the following: > > Ping? Still happening (rarely on -next): > > [ 5818.038245] WARNING: CPU: 4 PID: 22726 at arch/x86/mm/pat.c:781 > untrack_pfn+0x65/0xb0() > [ 5818.044203] Modules linked in: > [ 5818.045172] CPU: 4 PID: 22726 Comm: trinity-c239 Tainted: GW > 3.15.0-rc8-next-20140606-sasha-00021-ga9d3a0b-dirty #596 > [ 5818.048317] 0009 8800024d3be8 9e50fe6b > 0001 > [ 5818.050516] 8800024d3c28 9b15f96c > 8800024d3c38 > [ 5818.052567] 88000203f400 8800024d3d68 > 8800024d3d68 > [ 5818.053785] Call Trace: > [ 5818.054483] dump_stack (lib/dump_stack.c:52) > [ 5818.055586] warn_slowpath_common (kernel/panic.c:430) > [ 5818.056763] warn_slowpath_null (kernel/panic.c:465) > [ 5818.057789] untrack_pfn (arch/x86/mm/pat.c:781 (discriminator 3)) > [ 5818.059412] unmap_single_vma (mm/memory.c:1327) > [ 5818.061530] ? pagevec_lru_move_fn (include/linux/pagevec.h:44 > mm/swap.c:435) > [ 5818.063412] unmap_vmas (mm/memory.c:1377 (discriminator 1)) > [ 5818.064610] unmap_region (mm/mmap.c:2363 (discriminator 3)) > [ 5818.065453] ? validate_mm_rb (mm/mmap.c:404) > [ 5818.066422] ? vma_rb_erase (mm/mmap.c:449 > include/linux/rbtree_augmented.h:219 include/linux/rbtree_augmented.h:227 > mm/mmap.c:488) > [ 5818.067316] do_munmap (mm/mmap.c:3359 mm/mmap.c:2561) > [ 5818.068126] move_vma (mm/mremap.c:313) > [ 5818.069000] SyS_mremap (mm/mremap.c:446 mm/mremap.c:508 mm/mremap.c:477) > [ 5818.069839] tracesys (arch/x86/kernel/entry_64.S:542) I could easily be wrong, but I think of this one as another manifestation of the filemap.c:202 BUG_ON(page_mapped(page)) bug, whatever that is. In each case, we have a BUG or WARNING at the point where we detect that there should have been a pte in a page table, but it somehow disappeared. VM_PFNMAP in this case, an ordinary file mapping in the other case; and nothing to show in the anonymous case, there the page would just leak. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: mm: NULL ptr deref in remove_migration_pte
On Tue, 27 May 2014, Sasha Levin wrote: > On 05/26/2014 04:05 PM, Hugh Dickins wrote: > > On Fri, 23 May 2014, Sasha Levin wrote: > > > >> Ping? > >> > >> On 05/05/2014 11:51 AM, Sasha Levin wrote: > >>> Did anyone have a chance to look at it? I still see it in -next. > >>> > >>> > >>> Thanks, > >>> Sasha > >>> > >>> On 04/16/2014 10:59 AM, Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running latest -next > kernel I've stumbled on the following: > > [ 2552.313602] BUG: unable to handle kernel NULL pointer dereference at > 0018 > [ 2552.315878] IP: __lock_acquire (kernel/locking/lockdep.c:3070 > (discriminator 1)) > [ 2552.315878] PGD 465836067 PUD 465837067 PMD 0 > [ 2552.315878] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 2552.315878] Dumping ftrace buffer: > [ 2552.315878](ftrace buffer empty) > [ 2552.315878] Modules linked in: > [ 2552.315878] CPU: 6 PID: 16173 Comm: trinity-c364 Tainted: GW > 3.15.0-rc1-next-20140415-sasha-00020-gaa90d09 #398 > [ 2552.315878] task: 88046548b000 ti: 88044e532000 task.ti: > 88044e532000 > [ 2552.320286] RIP: __lock_acquire (kernel/locking/lockdep.c:3070 > (discriminator 1)) > [ 2552.320286] RSP: 0018:88044e5339c8 EFLAGS: 00010002 > [ 2552.320286] RAX: 0082 RBX: 88046548b000 RCX: > > [ 2552.320286] RDX: RSI: RDI: > 0018 > [ 2552.320286] RBP: 88044e533ab8 R08: 0001 R09: > > [ 2552.320286] R10: 88046548b000 R11: 0001 R12: > > [ 2552.320286] R13: 0018 R14: R15: > > [ 2552.320286] FS: 7fd286a9a700() GS:88018b00() > knlGS: > [ 2552.320286] CS: 0010 DS: ES: CR0: 8005003b > [ 2552.320286] CR2: 0018 CR3: 000442c17000 CR4: > 06a0 > [ 2552.320286] DR0: 00695000 DR1: DR2: > > [ 2552.320286] DR3: DR6: 0ff0 DR7: > 0600 > [ 2552.320286] Stack: > [ 2552.320286] 88044e5339e8 9f56e761 > 880315c13000 > [ 2552.320286] 88044e533a38 9c193f0d 9c193e34 > 8804654e8000 > [ 2552.320286] 8804654e8000 0001 88046548b000 > 0007 > [ 2552.320286] Call Trace: > [ 2552.320286] ? _raw_spin_unlock_irq (arch/x86/include/asm/preempt.h:98 > include/linux/spinlock_api_smp.h:169 kernel/locking/spinlock.c:199) > [ 2552.320286] ? finish_task_switch (include/linux/tick.h:206 > kernel/sched/core.c:2163) > [ 2552.320286] ? finish_task_switch (arch/x86/include/asm/current.h:14 > kernel/sched/sched.h:993 kernel/sched/core.c:2145) > [ 2552.320286] ? retint_restore_args (arch/x86/kernel/entry_64.S:1040) > [ 2552.320286] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63) > [ 2552.320286] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2557 > kernel/locking/lockdep.c:2599) > [ 2552.320286] lock_acquire (arch/x86/include/asm/current.h:14 > kernel/locking/lockdep.c:3602) > [ 2552.320286] ? remove_migration_pte (mm/migrate.c:137) > [ 2552.320286] ? retint_restore_args (arch/x86/kernel/entry_64.S:1040) > [ 2552.320286] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 > kernel/locking/spinlock.c:151) > [ 2552.320286] ? remove_migration_pte (mm/migrate.c:137) > [ 2552.320286] remove_migration_pte (mm/migrate.c:137) > [ 2552.320286] rmap_walk (mm/rmap.c:1628 mm/rmap.c:1699) > [ 2552.320286] remove_migration_ptes (mm/migrate.c:224) > [ 2552.320286] ? new_page_node (mm/migrate.c:107) > [ 2552.320286] ? remove_migration_pte (mm/migrate.c:195) > [ 2552.320286] migrate_pages (mm/migrate.c:922 mm/migrate.c:960 > mm/migrate.c:1126) > [ 2552.320286] ? perf_trace_mm_numa_migrate_ratelimit (mm/migrate.c:1574) > [ 2552.320286] migrate_misplaced_page (mm/migrate.c:1733) > [ 2552.320286] __handle_mm_fault (mm/memory.c:3762 mm/memory.c:3812 > mm/memory.c:3925) > [ 2552.320286] ? __const_udelay (arch/x86/lib/delay.c:126) > [ 2552.320286] ? __rcu_read_unlock (kernel/rcu/update.c:97) > [ 2552.320286] handle_mm_fault (mm/memory.c:3948) > [ 2552.320286] __get_user_pages (mm/memory.c:1851) > [ 2552.320286] ? preempt_count_sub (kernel/sched/core.c:2527) > [ 2552.320286] __mlock_vma_pages_range (mm/mlock.c:255) > [ 2552.320286] __mm_populate (mm/mlock.c:711) > [ 2552.320286] SyS_mlockall (include/linux/mm.h:1799 mm/mlock.c:817 > mm/mlock.c:791) > [
[PATCH v2 1/1] platform/chrome: Probe multiple i2c adapters of the same name
The chromeos_laptop module probes the first i2c adapter with a specific
name for expected hardware. However, the Acer C720 Chromebook has two i2c
adapters with the same name. This patch probes each i2c adapter with a
specific name in turn, until locating the expected hardware.
Thanks to Mika Westerberg for identifying the need for unique bus
addresses within each set of identically-named adapters.
Signed-off-by: Scot Doyle
CC: Benson Leung
CC: Mika Westerberg
---
diff --git a/drivers/platform/chrome/chromeos_laptop.c
b/drivers/platform/chrome/chromeos_laptop.c
index 7f3aad0..8382315 100644
--- a/drivers/platform/chrome/chromeos_laptop.c
+++ b/drivers/platform/chrome/chromeos_laptop.c
@@ -29,6 +29,8 @@
#include
#include
+/* Note: Bus addresses must be unique within each set of identically-named
+adapters on a board, otherwise device probing may fail. */
#define ATMEL_TP_I2C_ADDR 0x4b
#define ATMEL_TP_I2C_BL_ADDR 0x25
#define ATMEL_TS_I2C_ADDR 0x4a
@@ -173,7 +175,7 @@ static struct i2c_client *__add_probed_i2c_device(
/* add the i2c device */
client = i2c_new_probed_device(adapter, info, addrs, NULL);
if (!client)
- pr_err("%s failed to register device %d-%02x\n",
+ pr_debug("%s did not add i2c device %d-%02x\n",
__func__, bus, info->addr);
else
pr_debug("%s added i2c device %d-%02x\n",
@@ -194,13 +196,14 @@ static int __find_i2c_adap(struct device *dev, void *data)
return (strncmp(adapter->name, name, strlen(name)) == 0);
}
-static int find_i2c_adapter_num(enum i2c_adapter_type type)
+static int find_i2c_next_adapter_num(enum i2c_adapter_type type,
+struct device *start)
{
struct device *dev = NULL;
struct i2c_adapter *adapter;
const char *name = i2c_adapter_names[type];
- /* find the adapter by name */
- dev = bus_find_device(_bus_type, NULL, (void *)name,
+ /* find the next adapter by name */
+ dev = bus_find_device(_bus_type, start, (void *)name,
__find_i2c_adap);
if (!dev) {
/* Adapters may appear later. Deferred probing will retry */
@@ -226,10 +229,17 @@ static struct i2c_client *add_probed_i2c_device(
struct i2c_board_info *info,
const unsigned short *addrs)
{
- return __add_probed_i2c_device(name,
- find_i2c_adapter_num(type),
- info,
- addrs);
+ struct i2c_client *client = NULL;
+ struct device *start = NULL;
+ int adapter_num = 0;
+ while (!client && adapter_num > -1) {
+ adapter_num = find_i2c_next_adapter_num(type, start);
+ client = __add_probed_i2c_device(name,
+adapter_num,
+info,
+addrs);
+ }
+ return client;
}
/*
@@ -242,10 +252,10 @@ static struct i2c_client *add_i2c_device(const char *name,
struct i2c_board_info *info)
{
const unsigned short addr_list[] = { info->addr, I2C_CLIENT_END };
- return __add_probed_i2c_device(name,
- find_i2c_adapter_num(type),
- info,
- addr_list);
+ return add_probed_i2c_device(name,
+type,
+info,
+addr_list);
}
static int setup_cyapa_tp(enum i2c_adapter_type type)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] auditsc: audit_krule mask accesses need bounds checking
On Mon, Jun 09, 2014 at 09:04:16PM -0700, Andy Lutomirski wrote: > On Mon, Jun 9, 2014 at 7:57 PM, Greg KH wrote: > > On Mon, Jun 09, 2014 at 05:51:37PM -0700, Andy Lutomirski wrote: > >> [cc list trimmed, security@ added] > >> > >> On Mon, Jun 9, 2014 at 5:31 PM, Greg KH wrote: > >> > On Mon, Jun 09, 2014 at 07:35:57PM -0400, Josh Boyer wrote: > >> >> On Mon, Jun 9, 2014 at 6:46 PM, Greg KH > >> >> wrote: > >> >> > > >> >> > But yes, having something "real" might be good if the load gets > >> >> > higher, > >> >> > right now it's so low that my "sweep pending security patches" task > >> >> > usually catches anything pending, which is rare. > >> >> > >> >> How does one get added to the security@ alias? We've been carrying > >> >> this patch in Fedora for a bit now. I'd be happy to help track things > >> >> given we get distro security bug reports and such. > >> > > >> > Just ask on the security@ alias to be added and we can take it from > >> > there. > >> > > >> > >> Would it make sense for there to be someone on the security list who > >> can assign CVE numbers? > > > > I'm pretty sure we have that already. > > Let me rephrase the question: > > Would it make sense for someone on the security list to assign CVE numbers? If we cared about CVE numbers, maybe :) Seriously, there are people on the security alias that can get CVE numbers assigned if needed, so that should not be an issue. It's happened in the past from what I can recall. 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/
linux-next: build failure after merge of the vhost tree
Hi Michael,
After merging the vhost tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/vhost/scsi.c: In function 'vhost_scsi_handle_vq':
drivers/vhost/scsi.c:1043:14: error: 'struct vhost_dev' has no member named
'acked_features'
if (vs->dev.acked_features & VIRTIO_SCSI_F_T10_PI) {
^
Commit 95e7c4341b8e ("vhost/scsi: Enable T10 PI IOV -> SGL memory
mapping") from the target-updates tree interacting with commit
10350a292160 ("vhost: move acked_features to VQs") from the vhost tree.
I applied the following patch which seems right, but may not be.
From: Stephen Rothwell
Date: Tue, 10 Jun 2014 14:08:21 +1000
Subject: [PATCH] vhost/scsi: fixup for acked_features move
Signed-off-by: Stephen Rothwell
---
drivers/vhost/scsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 78ff1f64d759..6d7dd85365fe 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1040,7 +1040,7 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
vhost_virtqueue *vq)
break;
}
- if (vs->dev.acked_features & VIRTIO_SCSI_F_T10_PI) {
+ if (vhost_has_feature(vq, VIRTIO_SCSI_F_T10_PI)) {
req = _req_pi;
lunp = _req_pi.lun[0];
target = _req_pi.lun[1];
--
2.0.0
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH 1/1] platform/chrome: Probe multiple i2c adapters of the same name
That's a good point, I'll submit a new patch which documents this requirement. If this isn't a sufficiently robust solution, I understand. On Mon, 9 Jun 2014, Mika Westerberg wrote: On Fri, Jun 06, 2014 at 11:25:14PM +0100, Scot Doyle wrote: The chromeos_laptop module probes the first i2c adapter with a specific name for expected hardware. However, the Acer C720 Chromebook has two i2c adapters with the same name. This patch probes each i2c adapter with a specific name in turn, until locating the expected hardware. Signed-off-by: Scot Doyle CC: Benson Leung CC: Mika Westerberg I don't have anything against this approach. One comment though, if you happen to have two devices with the same address but in different buses this can go wrong. Not sure how likely that will happen. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] auditsc: audit_krule mask accesses need bounds checking
On Mon, Jun 9, 2014 at 7:57 PM, Greg KH wrote: > On Mon, Jun 09, 2014 at 05:51:37PM -0700, Andy Lutomirski wrote: >> [cc list trimmed, security@ added] >> >> On Mon, Jun 9, 2014 at 5:31 PM, Greg KH wrote: >> > On Mon, Jun 09, 2014 at 07:35:57PM -0400, Josh Boyer wrote: >> >> On Mon, Jun 9, 2014 at 6:46 PM, Greg KH >> >> wrote: >> >> > >> >> > But yes, having something "real" might be good if the load gets higher, >> >> > right now it's so low that my "sweep pending security patches" task >> >> > usually catches anything pending, which is rare. >> >> >> >> How does one get added to the security@ alias? We've been carrying >> >> this patch in Fedora for a bit now. I'd be happy to help track things >> >> given we get distro security bug reports and such. >> > >> > Just ask on the security@ alias to be added and we can take it from >> > there. >> > >> >> Would it make sense for there to be someone on the security list who >> can assign CVE numbers? > > I'm pretty sure we have that already. Let me rephrase the question: Would it make sense for someone on the security list to assign CVE numbers? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 5/7] rtmutex: Confine deadlock logic to futex
On 06/10/2014 08:59 AM, Steven Rostedt wrote:
> On Mon, 09 Jun 2014 20:28:09 -
> Thomas Gleixner wrote:
>
>> +/*
>> + * Futex variant to allow full deadlock detection.
>> + */
>> +int __rt_mutex_timed_lock(struct rt_mutex *lock,
>> + struct hrtimer_sleeper *timeout)
>> +{
>> +might_sleep();
>> +
>> +return rt_mutex_timed_fastlock(lock, TASK_INTERRUPTIBLE, timeout, 0,
>> + rt_mutex_slowlock);
>> +}
This futex variant one is not used until next patch, it should not be
introduced in this patch.
>> +
>> /**
>> * rt_mutex_timed_lock - lock a rt_mutex interruptible
>> * the timeout structure is provided
>> * by the caller
>> *
>> - * @lock: the rt_mutex to be locked
>> + * @lock: the rt_mutex to be locked
>> * @timeout:timeout structure or NULL (no timeout)
>> - * @detect_deadlock:deadlock detection on/off
>> *
>> * Returns:
>> - * 0 on success
>> - * -EINTR when interrupted by a signal
>> + * 0 on success
>> + * -EINTR when interrupted by a signal
>> * -ETIMEDOUT when the timeout expired
>> - * -EDEADLK when the lock would deadlock (when deadlock detection is on)
>> */
>> int
>> -rt_mutex_timed_lock(struct rt_mutex *lock, struct hrtimer_sleeper *timeout,
>> -int detect_deadlock)
>> +rt_mutex_timed_lock(struct rt_mutex *lock, struct hrtimer_sleeper *timeout)
>> {
>> might_sleep();
>>
>> -return rt_mutex_timed_fastlock(lock, TASK_INTERRUPTIBLE, timeout,
>> - detect_deadlock, rt_mutex_slowlock);
>> +return rt_mutex_timed_fastlock(lock, TASK_INTERRUPTIBLE, timeout, 0,
>> + rt_mutex_slowlock);
>> }
>> EXPORT_SYMBOL_GPL(rt_mutex_timed_lock);
>>
>
> I must be missing something. What's the difference between the above
> and the futex variant one? They both do the exact same thing:
>
It will use RT_MUTEX_*FULL*_CHAINWALK for the futex variant one while
rt_mutex_timed_lock() will use RT_MUTEX_*MIN*_CHAINWALK
>
> int foo(struct rt_mutex *lock, struct hrtimer_sleeper *timeout)
> {
> might_sleep();
>
> return rt_mutex_timed_fastlock(lock, TASK_INTERRUPTIBLE, timout,
> 0, rt_mutex_slowlock);
> }
>
>
> ??
>
> -- Steve
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: phy: realtek: register/unregister multiple drivers properly
Using phy_drivers_register/_unregister functions is proper way to
handle multiple PHY drivers registration. For Realtek PHY drivers
module, it fixes incomplete current error-handlings up and adds
missed unregistration for the RTL8201CP driver.
Signed-off-by: Jongsung Kim
---
drivers/net/phy/realtek.c | 88 +++--
1 files changed, 37 insertions(+), 51 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index fa1d69a..45483fd 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -64,65 +64,51 @@ static int rtl8211e_config_intr(struct phy_device *phydev)
return err;
}
-/* RTL8201CP */
-static struct phy_driver rtl8201cp_driver = {
- .phy_id = 0x8201,
- .name = "RTL8201CP Ethernet",
- .phy_id_mask= 0x,
- .features = PHY_BASIC_FEATURES,
- .flags = PHY_HAS_INTERRUPT,
- .config_aneg= _config_aneg,
- .read_status= _read_status,
- .driver = { .owner = THIS_MODULE,},
-};
-
-/* RTL8211B */
-static struct phy_driver rtl8211b_driver = {
- .phy_id = 0x001cc912,
- .name = "RTL8211B Gigabit Ethernet",
- .phy_id_mask= 0x001f,
- .features = PHY_GBIT_FEATURES,
- .flags = PHY_HAS_INTERRUPT,
- .config_aneg= _config_aneg,
- .read_status= _read_status,
- .ack_interrupt = _ack_interrupt,
- .config_intr= _config_intr,
- .driver = { .owner = THIS_MODULE,},
-};
-
-/* RTL8211E */
-static struct phy_driver rtl8211e_driver = {
- .phy_id = 0x001cc915,
- .name = "RTL8211E Gigabit Ethernet",
- .phy_id_mask= 0x001f,
- .features = PHY_GBIT_FEATURES,
- .flags = PHY_HAS_INTERRUPT,
- .config_aneg= _config_aneg,
- .read_status= _read_status,
- .ack_interrupt = _ack_interrupt,
- .config_intr= _config_intr,
- .suspend= genphy_suspend,
- .resume = genphy_resume,
- .driver = { .owner = THIS_MODULE,},
+static struct phy_driver realtek_drvs[] = {
+ {
+ .phy_id = 0x8201,
+ .name = "RTL8201CP Ethernet",
+ .phy_id_mask= 0x,
+ .features = PHY_BASIC_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_aneg= _config_aneg,
+ .read_status= _read_status,
+ .driver = { .owner = THIS_MODULE,},
+ }, {
+ .phy_id = 0x001cc912,
+ .name = "RTL8211B Gigabit Ethernet",
+ .phy_id_mask= 0x001f,
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_aneg= _config_aneg,
+ .read_status= _read_status,
+ .ack_interrupt = _ack_interrupt,
+ .config_intr= _config_intr,
+ .driver = { .owner = THIS_MODULE,},
+ }, {
+ .phy_id = 0x001cc915,
+ .name = "RTL8211E Gigabit Ethernet",
+ .phy_id_mask= 0x001f,
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_aneg= _config_aneg,
+ .read_status= _read_status,
+ .ack_interrupt = _ack_interrupt,
+ .config_intr= _config_intr,
+ .suspend= genphy_suspend,
+ .resume = genphy_resume,
+ .driver = { .owner = THIS_MODULE,},
+ },
};
static int __init realtek_init(void)
{
- int ret;
-
- ret = phy_driver_register(_driver);
- if (ret < 0)
- return -ENODEV;
- ret = phy_driver_register(_driver);
- if (ret < 0)
- return -ENODEV;
- return phy_driver_register(_driver);
+ return phy_drivers_register(realtek_drvs, ARRAY_SIZE(realtek_drvs));
}
static void __exit realtek_exit(void)
{
- phy_driver_unregister(_driver);
- phy_driver_unregister(_driver);
+ phy_drivers_unregister(realtek_drvs, ARRAY_SIZE(realtek_drvs));
}
module_init(realtek_init);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch V3 7/7] rtmutex: Avoid pointless requeueing in the deadlock detection chain walk
On Mon, Jun 9, 2014 at 6:20 PM, Steven Rostedt wrote:
> On Mon, 09 Jun 2014 20:28:10 -
> Thomas Gleixner wrote:
>
>> In case the dead lock detector is enabled we follow the lock chain to
>> the end in rt_mutex_adjust_prio_chain, even if we could stop earlier
>> due to the priority/waiter constellation.
>>
>> But once we are not longer the top priority waiter in a certain step
>> or the task holding the lock has already the same priority then there
>> is no point in dequeing and enqueing along the lock chain as there is
>> no change at all.
>>
>> So stop the requeueing at this point.
>>
>> Signed-off-by: Thomas Gleixner
>> ---
>> kernel/locking/rtmutex.c | 61
>> +--
>> 1 file changed, 54 insertions(+), 7 deletions(-)
>>
>> Index: tip/kernel/locking/rtmutex.c
>> ===
>> --- tip.orig/kernel/locking/rtmutex.c
>> +++ tip/kernel/locking/rtmutex.c
>> @@ -359,6 +359,7 @@ static int rt_mutex_adjust_prio_chain(st
>> struct rt_mutex *lock;
>> bool detect_deadlock;
>> unsigned long flags;
>> + bool requeue = true;
>>
>> detect_deadlock = rt_mutex_cond_detect_deadlock(orig_waiter, chwalk);
>>
>> @@ -436,18 +437,31 @@ static int rt_mutex_adjust_prio_chain(st
>> goto out_unlock_pi;
>> /*
>>* If deadlock detection is off, we stop here if we
>> - * are not the top pi waiter of the task.
>> + * are not the top pi waiter of the task. If deadlock
>> + * detection is enabled we continue, but stop the
>> + * requeueing in the chain walk.
>>*/
>> - if (!detect_deadlock && top_waiter != task_top_pi_waiter(task))
>> - goto out_unlock_pi;
>> + if (top_waiter != task_top_pi_waiter(task)) {
>> + if (!detect_deadlock)
>> + goto out_unlock_pi;
>> + else
>> + requeue = false;
>> + }
>> }
>>
>> /*
>> - * When deadlock detection is off then we check, if further
>> - * priority adjustment is necessary.
>> + * If the waiter priority is the same as the task priority
>> + * then there is no further priority adjustment necessary. If
>> + * deadlock detection is off, we stop the chain walk. If its
>> + * enabled we continue, but stop the requeueing in the chain
>> + * walk.
>>*/
>> - if (!detect_deadlock && waiter->prio == task->prio)
>> - goto out_unlock_pi;
>> + if (waiter->prio == task->prio) {
>> + if (!detect_deadlock)
>> + goto out_unlock_pi;
>> + else
>> + requeue = false;
>> + }
>>
>> /*
>>* We need to trylock here as we are holding task->pi_lock,
>> @@ -475,6 +489,39 @@ static int rt_mutex_adjust_prio_chain(st
>> }
>>
>> /*
>> + * If we just follow the lock chain for deadlock detection, no
>> + * need to do all the requeue operations. We avoid a truckload
>
> s/We/To/
>
>
>> + * of conditinals around the various places below and just do
>
> s/ and/, /
And s/conditinals/conditionals/
>> + * the minimum chain walk checks here.
>> + */
>> + if (!requeue) {
>> + /* Release the task */
>> + raw_spin_unlock_irqrestore(>pi_lock, flags);
>> + put_task_struct(task);
>> +
>> + /* If there is no owner of the lock, end of chain. */
>> + if (!rt_mutex_owner(lock)) {
>> + raw_spin_unlock(>wait_lock);
>> + return 0;
>> + }
>> +
>> + /* Grab the next task, i.e. owner of @lock */
>> + task = rt_mutex_owner(lock);
>> + get_task_struct(task);
>> + raw_spin_lock_irqsave(>pi_lock, flags);
>> +
>> + /* Store whether owner is blocked itself and drop locks */
>> + next_lock = task_blocked_on(task);
>> + raw_spin_unlock_irqrestore(>pi_lock, flags);
>> + raw_spin_unlock(>wait_lock);
>> +
>> + /* If owner is not blocked, end of chain. */
>> + if (!next_lock)
>> + goto out_put_task;
>
> On the loop back around, have something like:
>
> if (top_waiter) {
> if (!task_has_pi_waiters(task))
> goto out_unlock_pi;
>
> if (!requeue &&
> top_waiter != task_top_pi_waiter(task)) {
> if (!detect_deadlock)
> goto out_unlock_pi;
> else
> requeue = false;
> }
> }
>
> ??
>
>
>> + goto again;
>> + }
>> +
>> + /*
>>* Store the current top waiter before doing the requeue
>>
Re: [patch V3 1/7] rtmutex: Deobfuscate chain walk
On 06/10/2014 04:59 AM, Steven Rostedt wrote: > On Mon, 09 Jun 2014 20:28:06 - > Thomas Gleixner wrote: > >> There is no point to keep the task ref across the check for lock >> owner. Drop the ref before that, so the protection context is clear. >> >> Found while documenting the chain walk. > > This looks fine, I just hate the subject. I don't see how it is > 'deobfuscating" the chain walk. How about: > > rtmutex: No need to keep task ref when checking lock ownership > > Reviewed-by: Steven Rostedt Reviewed-by: Lai Jiangshan Thanks, Lai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH V2] rt/aio: fix rcu garbage collection might_sleep() splat
On Mon, 2014-06-09 at 10:08 +0800, Lai Jiangshan wrote:
> Hi, rt-people
>
> I don't think it is the correct direction.
> Softirq (including local_bh_disable()) in RT kernel should be preemptible.
How about the below then?
I was sorely tempted to post a tiny variant that dropped taking ctx_lock
in free_ioctx_users() entirely, as someone diddling with no reference
didn't make sense. Cc Ben, he would know.
[ 172.743098] BUG: sleeping function called from invalid context at
kernel/locking/rtmutex.c:768
[ 172.743116] in_atomic(): 1, irqs_disabled(): 0, pid: 26, name: rcuos/2
[ 172.743117] 2 locks held by rcuos/2/26:
[ 172.743128] #0: (rcu_callback){.+.+..}, at: []
rcu_nocb_kthread+0x1e2/0x380
[ 172.743135] #1: (rcu_read_lock_sched){.+.+..}, at: []
percpu_ref_kill_rcu+0xa6/0x1c0
[ 172.743138] Preemption disabled at:[]
rcu_nocb_kthread+0x263/0x380
[ 172.743138]
[ 172.743142] CPU: 0 PID: 26 Comm: rcuos/2 Not tainted 3.14.4-rt5 #31
[ 172.743143] Hardware name: MEDIONPC MS-7502/MS-7502, BIOS 6.00 PG 12/26/2007
[ 172.743148] 8802231aa190 8802231a5d08 81582e9e
[ 172.743151] 8802231a5d28 81077aeb 880209f68140
880209f681c0
[ 172.743154] 8802231a5d48 81589304 880209f68000
880209f68000
[ 172.743155] Call Trace:
[ 172.743160] [] dump_stack+0x4e/0x9c
[ 172.743163] [] __might_sleep+0xfb/0x170
[ 172.743167] [] rt_spin_lock+0x24/0x70
[ 172.743171] [] free_ioctx_users+0x30/0x130
[ 172.743174] [] percpu_ref_kill_rcu+0x1b4/0x1c0
[ 172.743177] [] ? percpu_ref_kill_rcu+0xa6/0x1c0
[ 172.743180] [] ? percpu_ref_kill_and_confirm+0x70/0x70
[ 172.743183] [] rcu_nocb_kthread+0x263/0x380
[ 172.743185] [] ? rcu_nocb_kthread+0x1e2/0x380
[ 172.743189] [] ? rcu_report_exp_rnp.isra.52+0xc0/0xc0
[ 172.743192] [] kthread+0xd6/0xf0
[ 172.743194] [] ? _raw_spin_unlock_irq+0x2c/0x70
[ 172.743197] [] ? __kthread_parkme+0x70/0x70
[ 172.743200] [] ret_from_fork+0x7c/0xb0
[ 172.743203] [] ? __kthread_parkme+0x70/0x70
crash> gdb list *percpu_ref_kill_rcu+0x1b4
0x812ace34 is in percpu_ref_kill_rcu
(include/linux/percpu-refcount.h:169).
164 pcpu_count = ACCESS_ONCE(ref->pcpu_count);
165
166 if (likely(REF_STATUS(pcpu_count) == PCPU_REF_PTR))
167 __this_cpu_dec(*pcpu_count);
168 else if (unlikely(atomic_dec_and_test(>count)))
169 ref->release(ref);
170
171 rcu_read_unlock_sched();
172 }
173
ref->release() path can't take sleeping locks, but in an rt kernel it does.
Defer ->release() work via call_rcu() to move sleeping locks out from under
rcu_read_lock_sched().
Signed-off-by: Mike Galbraith
---
fs/aio.c | 38 +-
1 file changed, 25 insertions(+), 13 deletions(-)
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -110,8 +110,6 @@ struct kioctx {
struct page **ring_pages;
longnr_pages;
- struct work_struct free_work;
-
struct {
/*
* This counts the number of available slots in the ringbuffer,
@@ -143,6 +141,7 @@ struct kioctx {
struct file *aio_ring_file;
unsignedid;
+ struct rcu_head rcu;
};
/*-- sysctl variables*/
@@ -493,9 +492,9 @@ static int kiocb_cancel(struct kioctx *c
return cancel(kiocb);
}
-static void free_ioctx(struct work_struct *work)
+static void free_ioctx_rcu(struct rcu_head *rcu)
{
- struct kioctx *ctx = container_of(work, struct kioctx, free_work);
+ struct kioctx *ctx = container_of(rcu, struct kioctx, rcu);
pr_debug("freeing %p\n", ctx);
@@ -508,18 +507,12 @@ static void free_ioctx_reqs(struct percp
{
struct kioctx *ctx = container_of(ref, struct kioctx, reqs);
- INIT_WORK(>free_work, free_ioctx);
- schedule_work(>free_work);
+ call_rcu(>rcu, free_ioctx_rcu);
}
-/*
- * When this function runs, the kioctx has been removed from the "hash table"
- * and ctx->users has dropped to 0, so we know no more kiocbs can be submitted
-
- * now it's safe to cancel any that need to be.
- */
-static void free_ioctx_users(struct percpu_ref *ref)
+static void free_ioctx_users_rcu(struct rcu_head *rcu)
{
- struct kioctx *ctx = container_of(ref, struct kioctx, users);
+ struct kioctx *ctx = container_of(rcu, struct kioctx, rcu);
struct kiocb *req;
spin_lock_irq(>ctx_lock);
@@ -538,6 +531,25 @@ static void free_ioctx_users(struct perc
percpu_ref_put(>reqs);
}
+/*
+ * When this function runs, the kioctx has been removed from the "hash table"
+ * and ctx->users has dropped to 0, so we know no more kiocbs can be submitted
-
+ * now it's safe to cancel any that need to be.
+ *
+ * NOTE: -rt must defer this to avoid taking sleeping ctx_lock while under
+ * rcu_real_lock_sched() during ->release().
+ */
+static void
Re: [patch V3 3/7] rtmutex: Document pi chain walk
On 06/10/2014 08:45 AM, Steven Rostedt wrote:
> On Mon, 09 Jun 2014 20:28:08 -
> Thomas Gleixner wrote:
>
>> Add commentry to document the chain walk and the protection mechanisms
>> and their scope.
>>
>> Signed-off-by: Thomas Gleixner
>> ---
>> kernel/locking/rtmutex.c | 52
>> +++
>> 1 file changed, 52 insertions(+)
>>
>> Index: tip/kernel/locking/rtmutex.c
>> ===
>> --- tip.orig/kernel/locking/rtmutex.c
>> +++ tip/kernel/locking/rtmutex.c
>> @@ -285,6 +285,47 @@ static inline struct rt_mutex *task_bloc
>> * @top_task: the current top waiter
>> *
>> * Returns 0 or -EDEADLK.
>> + *
>> + * Chain walk basics and protection scope
>> + *
>> + * [A] refcount on task
>> + * [B] task->pi_lock held
>> + * [C] rtmutex->lock held
>
> A,B, C is rather meaningless, and requires constant looking back up at
> the key. Perhaps [R],[P] and [L]
>
> [R] refcount on task (get_task_struct)
> [P] task->pi_lock held
> [L] rtmutex->lock held
>
>
> That way we can associate R being refcount, P being pi_lock and L being
> lock. Easier to remember.
>
>
>> + *
>> + * call() Protected by
>
> "call()"?
>
>> + * @task [A]
>> + * @orig_lock if != NULL @top_task is blocked on it
>> + * @next_lock Unprotected. Cannot be
>> + * dereferenced. Only used for
>> + * comparison.
>> + * @orig_waiter if != NULL @top_task is blocked on it
>> + * @top_task current, or in case of proxy
>> + * locking protected by calling
>> + * code
>> + * again:
>> + * loop_sanity_check();
>> + * retry:
>> + * lock(task->pi_lock);[A] acquire [B]
>> + * waiter = task->pi_blocked_on; [B]
>> + * check_exit_conditions();[B]
>> + * lock = waiter->lock;[B]
>> + * if (!try_lock(lock->wait_lock)) { [B] try to acquire [C]
>> + * unlock(task->pi_lock); drop [B]
>> + * goto retry;
>> + * }
>> + * check_exit_conditions();[B] + [C]
>> + * requeue_lock_waiter(lock, waiter); [B] + [C]
>> + * unlock(task->pi_lock); drop [B]
>> + * drop_task_ref(task);drop [A]
>
> Maybe just state "put_task_struct()", less abstractions.
>
>> + * check_exit_conditions();[C]
>> + * task = owner(lock); [C]
>> + * get_task_ref(task); [C] acquire [A]
>
> get_task_struct()
>
> -- Steve
>
>> + * lock(task->pi_lock);[C] acquire [B]
>> + * requeue_pi_waiter(task, waiters(lock)); [B] + [C]
>> + * check_exit_conditions();[B] + [C]
>> + * unlock(task->pi_lock); drop [B]
>> + * unlock(lock->wait_lock);drop [C]
>> + * goto again;
>> */
There are four check_exit_conditions()s with the same name but with different
locking.
I don't think it is a good a idea to copy the code to the comment of
the function description, we will need to always keep them coincident forever.
I prefer to comment them in the function body or comment them
in higher level abstraction.
>> static int rt_mutex_adjust_prio_chain(struct task_struct *task,
>>int deadlock_detect,
>> @@ -326,6 +367,12 @@ static int rt_mutex_adjust_prio_chain(st
>>
>> return -EDEADLK;
>> }
>> +
>> +/*
>> + * We are fully preemptible here and only hold the refcount on
>> + * @task. So everything can have changed under us since the
>> + * caller or our own code below (goto retry) dropped all locks.
>> + */
>> retry:
>> /*
>> * Task can not go away as we did a get_task() before !
>> @@ -383,6 +430,11 @@ static int rt_mutex_adjust_prio_chain(st
>> if (!detect_deadlock && waiter->prio == task->prio)
>> goto out_unlock_pi;
>>
>> +/*
>> + * We need to trylock here as we are holding task->pi_lock,
>> + * which is the reverse lock order versus the other rtmutex
>> + * operations.
>> + */
>> lock = waiter->lock;
>> if (!raw_spin_trylock(>wait_lock)) {
>> raw_spin_unlock_irqrestore(>pi_lock, flags);
>>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch V3 4/7] rtmutex: Siplify remove_waiter()
On Mon, Jun 9, 2014 at 5:53 PM, Steven Rostedt wrote:
> On Mon, 09 Jun 2014 20:28:08 -
> Thomas Gleixner wrote:
>
>> Exit right away, when the removed waiter was not the top prioriy
>> waiter on the lock. Get rid of the extra indent level.
>>
>> Signed-off-by: Thomas Gleixner
>> ---
>> kernel/locking/rtmutex.c | 26 ++
>> 1 file changed, 10 insertions(+), 16 deletions(-)
>>
>> Index: tip/kernel/locking/rtmutex.c
>> ===
>> --- tip.orig/kernel/locking/rtmutex.c
>> +++ tip/kernel/locking/rtmutex.c
>> @@ -780,7 +780,7 @@ static void remove_waiter(struct rt_mute
>> {
>> int first = (waiter == rt_mutex_top_waiter(lock));
>> struct task_struct *owner = rt_mutex_owner(lock);
>> - struct rt_mutex *next_lock = NULL;
>> + struct rt_mutex *next_lock;
>> unsigned long flags;
>>
>> raw_spin_lock_irqsave(>pi_lock, flags);
>> @@ -788,28 +788,22 @@ static void remove_waiter(struct rt_mute
>> current->pi_blocked_on = NULL;
>> raw_spin_unlock_irqrestore(>pi_lock, flags);
>>
>
> Add comment here, something like...
>
> /*
> * Only update priority if this task was the highest priority
> * task waiting on the lock, and there is an owner to update.
> */
Would it also make it clearer if we were to change "first" to something
such as "bool is_top_waiter"?
> Rest looks good.
>
> Reviewed-by: Steven Rostedt
Reviewed-by: Jason Low
> -- Steve
>
>
>> - if (!owner)
>> + if (!owner || !first)
>> return;
>>
>> - if (first) {
>> + raw_spin_lock_irqsave(>pi_lock, flags);
>>
>> - raw_spin_lock_irqsave(>pi_lock, flags);
>> + rt_mutex_dequeue_pi(owner, waiter);
>>
>> - rt_mutex_dequeue_pi(owner, waiter);
>> + if (rt_mutex_has_waiters(lock))
>> + rt_mutex_enqueue_pi(owner, rt_mutex_top_waiter(lock));
>>
>> - if (rt_mutex_has_waiters(lock)) {
>> - struct rt_mutex_waiter *next;
>> + __rt_mutex_adjust_prio(owner);
>>
>> - next = rt_mutex_top_waiter(lock);
>> - rt_mutex_enqueue_pi(owner, next);
>> - }
>> - __rt_mutex_adjust_prio(owner);
>> + /* Store the lock on which owner is blocked or NULL */
>> + next_lock = task_blocked_on_lock(owner);
>>
>> - /* Store the lock on which owner is blocked or NULL */
>> - next_lock = task_blocked_on_lock(owner);
>> -
>> - raw_spin_unlock_irqrestore(>pi_lock, flags);
>> - }
>> + raw_spin_unlock_irqrestore(>pi_lock, flags);
>>
>> if (!next_lock)
>> return;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch V3 4/7] rtmutex: Siplify remove_waiter()
On 06/10/2014 08:53 AM, Steven Rostedt wrote:
> On Mon, 09 Jun 2014 20:28:08 -
> Thomas Gleixner wrote:
>
>> Exit right away, when the removed waiter was not the top prioriy
>> waiter on the lock. Get rid of the extra indent level.
>>
>> Signed-off-by: Thomas Gleixner
>> ---
>> kernel/locking/rtmutex.c | 26 ++
>> 1 file changed, 10 insertions(+), 16 deletions(-)
>>
>> Index: tip/kernel/locking/rtmutex.c
>> ===
>> --- tip.orig/kernel/locking/rtmutex.c
>> +++ tip/kernel/locking/rtmutex.c
>> @@ -780,7 +780,7 @@ static void remove_waiter(struct rt_mute
>> {
>> int first = (waiter == rt_mutex_top_waiter(lock));
>> struct task_struct *owner = rt_mutex_owner(lock);
>> -struct rt_mutex *next_lock = NULL;
>> +struct rt_mutex *next_lock;
>> unsigned long flags;
>>
>> raw_spin_lock_irqsave(>pi_lock, flags);
>> @@ -788,28 +788,22 @@ static void remove_waiter(struct rt_mute
>> current->pi_blocked_on = NULL;
>> raw_spin_unlock_irqrestore(>pi_lock, flags);
>>
>
> Add comment here, something like...
>
> /*
>* Only update priority if this task was the highest priority
>* task waiting on the lock, and there is an owner to update.
>*/
>
> Rest looks good.
>
> Reviewed-by: Steven Rostedt
Reviewed-by: Lai Jiangshan
Thanks,
Lai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] block: make nr_requests tunable for loop
On 06/10/2014 11:12 AM, Jens Axboe wrote:
> On 2014-06-09 20:50, Junxiao Bi wrote:
>> On 06/10/2014 10:41 AM, Jens Axboe wrote:
>>> On 2014-06-09 20:31, Junxiao Bi wrote:
commit 7b5a3522 (loop: Limit the number of requests in the bio list)
limit
the request number in loop queue to not over 128. Since the
"request_fn" of
loop device is null, the requests number is not allowed tuned. Make
it tunable
from sysfs can improve performance.
The following test is done on a machine with 512M memory. The
backend of
/dev/loop1 is a nfs file.
[root@bijx mnt]# cat /sys/block/loop0/queue/nr_requests
128
[root@bijx mnt]# dd if=/dev/zero of=/dev/loop0 bs=1M count=5000
5000+0 records in
5000+0 records out
524288 bytes (5.2 GB) copied, 501.572 s, 10.5 MB/s
[root@bijx mnt]#
[root@bijx mnt]# echo 1024 > /sys/block/loop0/queue/nr_requests
[root@bijx mnt]# cat /sys/block/loop0/queue/nr_requests
1024
[root@bijx mnt]# dd if=/dev/zero of=/dev/loop0 bs=1M count=5000
5000+0 records in
5000+0 records out
524288 bytes (5.2 GB) copied, 464.481 s, 11.3 MB/s
Signed-off-by: Junxiao Bi
---
block/blk-core.c |6 ++
block/blk-sysfs.c |9 +++--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 40d6548..58c4bd4 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -851,6 +851,12 @@ int blk_update_nr_requests(struct request_queue
*q, unsigned int nr)
q->nr_requests = nr;
blk_queue_congestion_threshold(q);
+/* for loop device, return after set its nr_requests */
+if (!q->request_fn) {
+spin_unlock_irq(q->queue_lock);
+return 0;
+}
>>>
>>> It'd be prettier to split this differently - something ala:
>>>
>>> if (request_fn)
>>> blk_update_congestion_thresholds(q);
>> The congestion threshholds is needed in commit 7b5a3522 (loop: Limit the
>> number of requests in the bio list). So I think it needs be set even
>> request_fn is null.
>
> I mean the request list thresholds, the part below where you currently
> just exit.
>
>>> But I think you have a larger issue here... For the request lists, we
>>> update the congestion thresholds and wakeup anyone waiting, if we need
>>> to. There's no way to do that for loop, since the waitqueue is
>>> internal to loop.
>> Loop do the congestion control by itself, in loop_make_request() /
>> loop_thread().
>
> Yes, that is my point! You update nr_congestion_off, but you don't
> wake anyone currently sitting in wait_event_lock_irq() on that value.
> See what the code below where you just exit does for request list
> based devices.
Ah, i see. It can't be wake up once nr_congestion_off is updated. But
after a little delay, loop_thread will consume the requests in list and
wake up it. Is this OK?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] rtmutex: Clarify the boost/deboost part
On Mon, Jun 9, 2014 at 1:28 PM, Thomas Gleixner wrote: > Add a separate local variable for the boost/deboost logic to make the > code more readable. Add comments where appropriate. > > Signed-off-by: Thomas Gleixner Reviewed-by: Jason Low -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/7] rtmutex: Deobfuscate chain walk
On Mon, Jun 9, 2014 at 1:28 PM, Thomas Gleixner wrote: > There is no point to keep the task ref across the check for lock > owner. Drop the ref before that, so the protection context is clear. > > Found while documenting the chain walk. > > Signed-off-by: Thomas Gleixner Reviewed-by: Jason Low -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 11/42] x86, ioapic: kill unused global variable timer_through_8259
On 2014/6/9 22:41, Maciej W. Rozycki wrote:
> On Mon, 9 Jun 2014, Jiang Liu wrote:
>
>> index d4aba16e6bbf..94a56c233e87 100644
>> --- a/arch/x86/kernel/apic/io_apic.c
>> +++ b/arch/x86/kernel/apic/io_apic.c
>> @@ -2638,8 +2638,6 @@ static int __init disable_timer_pin_setup(char *arg)
>> }
>> early_param("disable_timer_pin_1", disable_timer_pin_setup);
>>
>> -int timer_through_8259 __initdata;
>> -
>> /*
>> * This code may look a bit paranoid, but it's supposed to cooperate with
>> * a wide range of boards and BIOS bugs. Fortunately only the timer IRQ
>> @@ -2744,7 +2742,6 @@ static inline void __init check_timer(void)
>> legacy_pic->unmask(0);
>> if (timer_irq_works()) {
>> apic_printk(APIC_QUIET, KERN_INFO "... works.\n");
>> -timer_through_8259 = 1;
>> goto out;
>> }
>> /*
>
> So how does the new NMI watchdog handle systems that use this '8259A
> Virtual Wire' mode, pretty common on pre-P6 computers?
Hi Maciej,
We just kill the useless variable "timer_through_8259", 8259 virtual
wire mode is still supported.
Thanks!
Gerry
>
> Maciej
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: rb_erase oops.
On Mon, Jun 09, 2014 at 04:09:38PM -0700, David Rientjes wrote: > On Mon, 9 Jun 2014, Dave Jones wrote: > > > Kernel based on v3.15-7257-g963649d735c8 > > > > Dave > > > > Oops: [#1] PREEMPT SMP > > Modules linked in: dlci 8021q garp snd_seq_dummy bnep llc2 af_key bridge > > stp fuse tun scsi_transport_iscsi ipt_ULOG nfnetlink rfcomm can_raw hidp > > can_bcm nfc caif_socket caif af_802154 ieee802154 phonet af_rxrpc can pppoe > > pppox ppp_generic slhc irda crc_ccitt rds rose x25 atm netrom appletalk ipx > > p8023 psnap p8022 llc ax25 coretemp cfg80211 hwmon x86_pkg_temp_thermal > > kvm_intel kvm snd_hda_codec_hdmi snd_hda_codec_realtek > > snd_hda_codec_generic btusb bluetooth snd_hda_intel xfs snd_hda_controller > > snd_hda_codec snd_hwdep snd_seq e1000e snd_seq_device crct10dif_pclmul > > crc32c_intel ghash_clmulni_intel snd_pcm snd_timer snd 6lowpan_iphc > > usb_debug rfkill libcrc32c ptp pps_core microcode shpchp pcspkr serio_raw > > soundcore > > CPU: 3 PID: 2049 Comm: kworker/3:1 Not tainted 3.15.0+ #231 > > Workqueue: events free_work > > task: 880100944260 ti: 88009ed9c000 task.ti: 88009ed9c000 > > RIP: 0010:[] [] rb_erase+0xb9/0x380 > > RSP: :88009ed9fcc0 EFLAGS: 00010202 > > RAX: 8802396b0018 RBX: 88024176b008 RCX: > > RDX: c90010fe1bf0 RSI: 8afb3178 RDI: 0001 > > RBP: 88009ed9fcc0 R08: 88023b122e58 R09: 88024176ae58 > > R10: R11: 880245801dc0 R12: 88024176b020 > > R13: 88009ed9fd80 R14: 88009ed9fd88 R15: 88024e397100 > > FS: () GS:88024e38() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 0001 CR3: 0ac1 CR4: 001407e0 > > DR0: 024cc000 DR1: 024c2000 DR2: > > DR3: DR6: fffe0ff0 DR7: 0600 > > Stack: > > 88009ed9fce0 8a195674 88024176ae40 8ac64260 > > 88009ed9fd70 8a19631d 88009ed9fd88 88009ed9fd80 > > 88009ed9fd10 880244b93750 880244b93750 > > Call Trace: > > [] __free_vmap_area+0x54/0xf0 > > [] __purge_vmap_area_lazy+0x15d/0x4a0 > > [] free_vmap_area_noflush+0x81/0x90 > > [] remove_vm_area+0x5e/0x70 > > [] __vunmap+0x2e/0x100 > > [] free_work+0x2d/0x40 > > [] process_one_work+0x171/0x4d0 > > [] worker_thread+0x12c/0x3d0 > > [] ? complete+0x42/0x50 > > [] ? manage_workers.isra.25+0x2d0/0x2d0 > > [] kthread+0xff/0x120 > > [] ? kthread_create_on_node+0x1c0/0x1c0 > > [] ret_from_fork+0x7c/0xb0 > > [] ? kthread_create_on_node+0x1c0/0x1c0 > > Code: 85 d2 74 0e 48 83 c8 01 48 89 0a 49 89 02 5d c3 66 90 48 8b 3a 48 89 > > 0a 83 e7 01 74 f1 31 c9 eb 40 90 48 8b 7a 08 48 85 ff 74 09 07 01 0f > > 84 a3 01 00 00 48 8b 4a 10 48 85 c9 74 09 f6 01 01 > > RIP [] rb_erase+0xb9/0x380 > > RSP > > > > Adding Joonsoo to the cc. > > I haven't looked very closely, and it may be unrelated, but perhaps this > is a race because of a failed radix_tree_preload() in new_vmap_block() and > this happens in low on memory conditions (and would be tough to reproduce > because of a race with the rcu-protected vmap_area_list iteration in > __purge_vmap_area_lazy() and the actual freeing of the vmap_area under > vmap_area_lock). Hello, David. I think that the race you mentioned is impossible. When radix_tree_preload() is failed in new_vmap_block(), flag of that vmap_area would be 0, so __purge_vmap_area_lazy() would not try to purge that vmap_area. Anyway, I have no idea what causes this problem now. 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] x86: numa: drop ZONE_ALIGN
On Mon, 9 Jun 2014 14:57:16 -0700 (PDT) David Rientjes wrote: > On Mon, 9 Jun 2014, Luiz Capitulino wrote: > > > > > diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h > > > > index 4064aca..01b493e 100644 > > > > --- a/arch/x86/include/asm/numa.h > > > > +++ b/arch/x86/include/asm/numa.h > > > > @@ -9,7 +9,6 @@ > > > > #ifdef CONFIG_NUMA > > > > > > > > #define NR_NODE_MEMBLKS(MAX_NUMNODES*2) > > > > -#define ZONE_ALIGN (1UL << (MAX_ORDER+PAGE_SHIFT)) > > > > > > > > /* > > > > * Too small node sizes may confuse the VM badly. Usually they > > > > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c > > > > index 1d045f9..69f6362 100644 > > > > --- a/arch/x86/mm/numa.c > > > > +++ b/arch/x86/mm/numa.c > > > > @@ -200,8 +200,6 @@ static void __init setup_node_data(int nid, u64 > > > > start, u64 end) > > > > if (end && (end - start) < NODE_MIN_SIZE) > > > > return; > > > > > > > > - start = roundup(start, ZONE_ALIGN); > > > > - > > > > printk(KERN_INFO "Initmem setup node %d [mem > > > > %#010Lx-%#010Lx]\n", > > > >nid, start, end - 1); > > > > > > > > > > What ensures this start address is page aligned from the BIOS? > > > > To which start address do you refer to? > > The start address displayed in the dmesg is not page aligned anymore with > your change, correct? I have to check that but I don't expect this to happen because my understanding of the code is that what's rounded up here is just discarded in free_area_init_node(). Am I wrong? > acpi_parse_memory_affinity() does no > transformations on the table, the base address is coming strictly from the > SRAT and there is no page alignment requirement in the ACPI specification. > NODE_DATA(nid)->node_start_pfn will be correct because it does the shift > for you, but it still seems you want to at least align to PAGE_SIZE here. I do agree we need to align to PAGE_SIZE, but I'm not sure where we should do it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Skrzynka Pocztowa Zostala Tymczasowo Zawieszona !!!
Szanowny uzytkowniku Niedawno wykryto nietypowe dzialania z konta e-mail, wiec skrzynka pocztowa zostala czasowo zawieszona przez administratora systemu, nalezy odzyskac swoje konto, klikajac na ponizszy link lub skopiuj do przegladarki: http://itadminhelpdeskccenter.yolasite.com/admin.php W wyniku tego, moze pojawic sie ten komunikat w folderze spamu, prosimy przejsc do skrzynki odbiorczej i kliknij link. Przepraszamy za niedogodnosci. HELP DESK IT ADMIN --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] block: make nr_requests tunable for loop
On 2014-06-09 20:50, Junxiao Bi wrote:
On 06/10/2014 10:41 AM, Jens Axboe wrote:
On 2014-06-09 20:31, Junxiao Bi wrote:
commit 7b5a3522 (loop: Limit the number of requests in the bio list)
limit
the request number in loop queue to not over 128. Since the
"request_fn" of
loop device is null, the requests number is not allowed tuned. Make
it tunable
from sysfs can improve performance.
The following test is done on a machine with 512M memory. The backend of
/dev/loop1 is a nfs file.
[root@bijx mnt]# cat /sys/block/loop0/queue/nr_requests
128
[root@bijx mnt]# dd if=/dev/zero of=/dev/loop0 bs=1M count=5000
5000+0 records in
5000+0 records out
524288 bytes (5.2 GB) copied, 501.572 s, 10.5 MB/s
[root@bijx mnt]#
[root@bijx mnt]# echo 1024 > /sys/block/loop0/queue/nr_requests
[root@bijx mnt]# cat /sys/block/loop0/queue/nr_requests
1024
[root@bijx mnt]# dd if=/dev/zero of=/dev/loop0 bs=1M count=5000
5000+0 records in
5000+0 records out
524288 bytes (5.2 GB) copied, 464.481 s, 11.3 MB/s
Signed-off-by: Junxiao Bi
---
block/blk-core.c |6 ++
block/blk-sysfs.c |9 +++--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 40d6548..58c4bd4 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -851,6 +851,12 @@ int blk_update_nr_requests(struct request_queue
*q, unsigned int nr)
q->nr_requests = nr;
blk_queue_congestion_threshold(q);
+/* for loop device, return after set its nr_requests */
+if (!q->request_fn) {
+spin_unlock_irq(q->queue_lock);
+return 0;
+}
It'd be prettier to split this differently - something ala:
if (request_fn)
blk_update_congestion_thresholds(q);
The congestion threshholds is needed in commit 7b5a3522 (loop: Limit the
number of requests in the bio list). So I think it needs be set even
request_fn is null.
I mean the request list thresholds, the part below where you currently
just exit.
But I think you have a larger issue here... For the request lists, we
update the congestion thresholds and wakeup anyone waiting, if we need
to. There's no way to do that for loop, since the waitqueue is
internal to loop.
Loop do the congestion control by itself, in loop_make_request() /
loop_thread().
Yes, that is my point! You update nr_congestion_off, but you don't wake
anyone currently sitting in wait_event_lock_irq() on that value. See
what the code below where you just exit does for request list based devices.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: drivers/char/random.c: more ruminations
>> I have an idea for a patch to change _xfer_secondary_pool >> to use extract_buf rather than extract_entropy; is all that >> FIPS stuff needed for purely internal transfers? > That's not the part of extract_entropy() which is critical. What's > critical is the control over only transfering entropy when there is at > least a certain minimum amount of entropy. This provides the > Yarrow-like avalanche property which is required to provide recovery > after the internal state of the entropy pools have been exposed. I do understand the importance of catastrophic reseeding, but I don't see that implemented in extract_entropy(). Extract_entropy() itself contains a call to xfer_secondary_pool, but that is a no-op in the case I'm considering (when it's called from _xfer_secondary_pool) because in that case, r is the the input_pool, which doesn't have an r->pull pool. The number of bytes transferred is adjusted by account(), but it's only adjusted downward. (If it were adjusted up, that would be a buffer overrun.) Normal reads seem to ask for a reseed equal in size to read itself, which is "ctastrophic" enough. The only *minimum* reseed transfer size I can see is enforced in _xfer_secondary_pool and push_to_pool, which use random_read_wakeup_bits (default 64) as a minimum reseed. (Prehaps increase this?) standards, IMHO.) Now, having said all that, I'll try to avoid embarrassing myself in public again and ask... what am I missing? On other matters... If I play around with getting the entropy locking right, do you have a strong preference for the single-lock or two-lock design? I can't decide which to start with. The latter is an extensive core code change, but I can easily convince myself there are no deadlock issues. That's the one I described with separate adder and extractor locks and code paths, two "amount of entropy ever added" variables, ane one "amont of entropy ever removed". The single-lock design is hopefully less code, but (to me, at least) less obviously deadlock-free. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/mempolicy: fix sleeping function called from invalid context
On 2014/6/9 17:13, David Rientjes wrote: > On Mon, 9 Jun 2014, Gu Zheng wrote: > >>> I think your patch addresses the problem that you're reporting but misses >>> the larger problem with cpuset.mems rebinding on fork(). When the >>> forker's task_struct is duplicated (which includes ->mems_allowed) and it >>> races with an update to cpuset_being_rebound in update_tasks_nodemask() >>> then the task's mems_allowed doesn't get updated. >> >> Yes, you are right, this patch just wants to address the bug reported above. >> The race condition you mentioned above inherently exists there, but it is yet >> another issue, the rcu lock here makes no sense to it, and I think we need >> additional sync-mechanisms if want to fix it. > > Yes, the rcu lock is not providing protection for any critical section > here that requires (1) the forker's cpuset to be stored in > cpuset_being_rebound or (2) the forked thread's cpuset to be rebound by > the cpuset nodemask update, and no race involving the two. > Yes, this is a long-standing issue. Besides the race you described, the child task's mems_allowed can be wrong if the cpuset's nodemask changes before the child has been added to the cgroup's tasklist. I remember Tejun once said he wanted to disallow task migration between cgroups during fork, and that should fix this problem. >> But thinking more, though the current implementation has flaw, but I worry >> about the negative effect if we really want to fix it. Or maybe the fear >> is unnecessary.:) >> > > It needs to be slightly rewritten to work properly without negatively > impacting the latency of fork(). Do you have the cycles to do it? > Sounds you have other idea? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] auditsc: audit_krule mask accesses need bounds checking
On Mon, Jun 09, 2014 at 05:51:37PM -0700, Andy Lutomirski wrote: > [cc list trimmed, security@ added] > > On Mon, Jun 9, 2014 at 5:31 PM, Greg KH wrote: > > On Mon, Jun 09, 2014 at 07:35:57PM -0400, Josh Boyer wrote: > >> On Mon, Jun 9, 2014 at 6:46 PM, Greg KH wrote: > >> > > >> > But yes, having something "real" might be good if the load gets higher, > >> > right now it's so low that my "sweep pending security patches" task > >> > usually catches anything pending, which is rare. > >> > >> How does one get added to the security@ alias? We've been carrying > >> this patch in Fedora for a bit now. I'd be happy to help track things > >> given we get distro security bug reports and such. > > > > Just ask on the security@ alias to be added and we can take it from > > there. > > > > Would it make sense for there to be someone on the security list who > can assign CVE numbers? I'm pretty sure we have that already. 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: [RFC PATCH 1/3] CMA: generalize CMA reserved area management functionality
On Thu, Jun 05, 2014 at 11:09:05PM +0530, Aneesh Kumar K.V wrote:
> Joonsoo Kim writes:
>
> > Currently, there are two users on CMA functionality, one is the DMA
> > subsystem and the other is the kvm on powerpc. They have their own code
> > to manage CMA reserved area even if they looks really similar.
> > From my guess, it is caused by some needs on bitmap management. Kvm side
> > wants to maintain bitmap not for 1 page, but for more size. Eventually it
> > use bitmap where one bit represents 64 pages.
> >
> > When I implement CMA related patches, I should change those two places
> > to apply my change and it seem to be painful to me. I want to change
> > this situation and reduce future code management overhead through
> > this patch.
> >
> > This change could also help developer who want to use CMA in their
> > new feature development, since they can use CMA easily without
> > copying & pasting this reserved area management code.
> >
> > Signed-off-by: Joonsoo Kim
>
>
> The way patches are split makes it difficult to review. Will it be
> possible to make changes against one implementation and them move that
> to generic code. That helps in finding out what exactly changed.
>
Hello,
You are right! I will respin this patchset as the form you
recommended.
> >
> > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> > index 00e13ce..b3fe1cc 100644
> > --- a/drivers/base/Kconfig
> > +++ b/drivers/base/Kconfig
> > @@ -283,7 +283,7 @@ config CMA_ALIGNMENT
> >
> > If unsure, leave the default value "8".
> >
> > -config CMA_AREAS
> > +config DMA_CMA_AREAS
> > int "Maximum count of the CMA device-private areas"
> > default 7
> > help
>
> for ex: The above can be a seperate patch along with further DMA related
> cleanups .
Okay.
>
> > diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
> > index 83969f8..48cdac8 100644
> > --- a/drivers/base/dma-contiguous.c
> > +++ b/drivers/base/dma-contiguous.c
> > @@ -186,7 +186,7 @@ static int __init cma_activate_area(struct cma *cma)
> > return 0;
> > }
> >
> > -static struct cma cma_areas[MAX_CMA_AREAS];
> > +static struct cma cma_areas[MAX_DMA_CMA_AREAS];
> > static unsigned cma_area_count;
> >
> > static int __init cma_init_reserved_areas(void)
> > diff --git a/include/linux/cma.h b/include/linux/cma.h
> > new file mode 100644
> > index 000..60ba06f
> > --- /dev/null
> > +++ b/include/linux/cma.h
> > @@ -0,0 +1,28 @@
> > +/*
> > + * Contiguous Memory Allocator
> > + *
> > + * Copyright LG Electronics Inc., 2014
> > + * Written by:
> > + * Joonsoo Kim
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of the
> > + * License or (at your optional) any later version of the license.
> > + *
> > + */
> > +
> > +#ifndef __CMA_H__
> > +#define __CMA_H__
> > +
> > +struct cma;
> > +
> > +extern struct page *cma_alloc(struct cma *cma, unsigned long count,
> > + unsigned long align);
> > +extern bool cma_release(struct cma *cma, struct page *pages,
> > + unsigned long count);
> > +extern int __init cma_declare_contiguous(phys_addr_t size, phys_addr_t
> > base,
> > + phys_addr_t limit, phys_addr_t alignment,
> > + unsigned long bitmap_shift, bool fixed,
> > + struct cma **res_cma);
> > +#endif
> > diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
> > index 772eab5..dfb1dc9 100644
> > --- a/include/linux/dma-contiguous.h
> > +++ b/include/linux/dma-contiguous.h
> > @@ -63,7 +63,7 @@ struct device;
> > * There is always at least global CMA area and a few optional device
> > * private areas configured in kernel .config.
> > */
> > -#define MAX_CMA_AREAS (1 + CONFIG_CMA_AREAS)
> > +#define MAX_DMA_CMA_AREAS (1 + CONFIG_DMA_CMA_AREAS)
> >
> > extern struct cma *dma_contiguous_default_area;
> >
> > @@ -123,7 +123,7 @@ bool dma_release_from_contiguous(struct device *dev,
> > struct page *pages,
> >
> > #else
> >
> > -#define MAX_CMA_AREAS (0)
> > +#define MAX_DMA_CMA_AREAS (0)
> >
> > static inline struct cma *dev_get_cma_area(struct device *dev)
> > {
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index 7511b4a..0877ddc 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -515,6 +515,17 @@ config CMA_DEBUG
> > processing calls such as dma_alloc_from_contiguous().
> > This option does not affect warning and error messages.
> >
> > +config CMA_AREAS
> > + int "Maximum count of the CMA areas"
> > + depends on CMA
> > + default 7
> > + help
> > + CMA allows to create CMA areas for particular purpose, mainly,
> > + used as device private area. This parameter sets the maximum
> > + number of CMA area in the system.
> > +
> > + If unsure, leave
Re: [patch V3 0/7] rtmutex: Code clarification and optimization
On 06/10/2014 08:35 AM, Steven Rostedt wrote: > On Mon, 9 Jun 2014 20:27:13 -0400 > Steven Rostedt wrote: > > >> So what branch do these apply to? I tried latest Linus master and it >> didn't apply. > > OK, they seem to be on tip/locking/urgent. Not yet in mainline. Thank you for share it, I'm trying to review the patches. Lai > > -- Steve > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/42] x86, irq: update high address field when updating affinity for MSI IRQ
On 2014/6/10 7:46, Yinghai Lu wrote: > On Mon, Jun 9, 2014 at 1:19 AM, Jiang Liu wrote: >> If x2apic is enabled, the MSI high address field should also be aslo >> updated when setting affinity for MSI IRQ, otherwise the MSI IRQ may >> target wrong APIC IDs. > > Do you have any test case to reveal the problem? Just by code inspection. > >> >> Signed-off-by: Jiang Liu >> Cc: sta...@vger.kernel.org >> --- >> arch/x86/kernel/apic/io_apic.c |4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c >> index 9d0a9795a0f8..2de992501a1b 100644 >> --- a/arch/x86/kernel/apic/io_apic.c >> +++ b/arch/x86/kernel/apic/io_apic.c >> @@ -3007,6 +3007,10 @@ msi_set_affinity(struct irq_data *data, const struct >> cpumask *mask, bool force) >> >> __get_cached_msi_msg(data->msi_desc, ); >> >> + msg.address_hi = MSI_ADDR_BASE_HI; >> + if (x2apic_enabled()) >> + msg.address_hi |= MSI_ADDR_EXT_DEST_ID(dest); >> + >> msg.data &= ~MSI_DATA_VECTOR_MASK; >> msg.data |= MSI_DATA_VECTOR(cfg->vector); >> msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK; > > No. This change is not needed. > > When x2apic is used, and apicid > 255, irq remapping is used. > > msi_chip.irq_set_affinity will be changed from msi_set_affinity to > x86_io_apic_ops.set_affinity (aka intel_setup_ioapic_entry), via > irq_remap_modify_chip_defaults(). Thanks for explanation, will drop this patch. Gerry > > Thanks > > Yinghai > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] block: make nr_requests tunable for loop
On 06/10/2014 10:41 AM, Jens Axboe wrote:
> On 2014-06-09 20:31, Junxiao Bi wrote:
>> commit 7b5a3522 (loop: Limit the number of requests in the bio list)
>> limit
>> the request number in loop queue to not over 128. Since the
>> "request_fn" of
>> loop device is null, the requests number is not allowed tuned. Make
>> it tunable
>> from sysfs can improve performance.
>>
>> The following test is done on a machine with 512M memory. The backend of
>> /dev/loop1 is a nfs file.
>>
>> [root@bijx mnt]# cat /sys/block/loop0/queue/nr_requests
>> 128
>> [root@bijx mnt]# dd if=/dev/zero of=/dev/loop0 bs=1M count=5000
>> 5000+0 records in
>> 5000+0 records out
>> 524288 bytes (5.2 GB) copied, 501.572 s, 10.5 MB/s
>> [root@bijx mnt]#
>> [root@bijx mnt]# echo 1024 > /sys/block/loop0/queue/nr_requests
>> [root@bijx mnt]# cat /sys/block/loop0/queue/nr_requests
>> 1024
>> [root@bijx mnt]# dd if=/dev/zero of=/dev/loop0 bs=1M count=5000
>> 5000+0 records in
>> 5000+0 records out
>> 524288 bytes (5.2 GB) copied, 464.481 s, 11.3 MB/s
>>
>> Signed-off-by: Junxiao Bi
>> ---
>> block/blk-core.c |6 ++
>> block/blk-sysfs.c |9 +++--
>> 2 files changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/block/blk-core.c b/block/blk-core.c
>> index 40d6548..58c4bd4 100644
>> --- a/block/blk-core.c
>> +++ b/block/blk-core.c
>> @@ -851,6 +851,12 @@ int blk_update_nr_requests(struct request_queue
>> *q, unsigned int nr)
>> q->nr_requests = nr;
>> blk_queue_congestion_threshold(q);
>>
>> +/* for loop device, return after set its nr_requests */
>> +if (!q->request_fn) {
>> +spin_unlock_irq(q->queue_lock);
>> +return 0;
>> +}
>
> It'd be prettier to split this differently - something ala:
>
> if (request_fn)
> blk_update_congestion_thresholds(q);
The congestion threshholds is needed in commit 7b5a3522 (loop: Limit the
number of requests in the bio list). So I think it needs be set even
request_fn is null.
>
> But I think you have a larger issue here... For the request lists, we
> update the congestion thresholds and wakeup anyone waiting, if we need
> to. There's no way to do that for loop, since the waitqueue is
> internal to loop.
Loop do the congestion control by itself, in loop_make_request() /
loop_thread().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpc925_edac: Use module_platform_driver()
On 2014/6/9 22:40, Kefeng Wang wrote:
> Move edac_op_state assignment operations to probe, then convert to
> module_platform_drive() to eliminate boilerplate code, and use
module_platform_driver() ;-)
> cpc925_printk instead of printk.
>
> Signed-off-by: Kefeng Wang
> ---
> drivers/edac/cpc925_edac.c | 33 +++--
> 1 files changed, 7 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/edac/cpc925_edac.c b/drivers/edac/cpc925_edac.c
> index df6575f..8e3192a 100644
> --- a/drivers/edac/cpc925_edac.c
> +++ b/drivers/edac/cpc925_edac.c
> @@ -944,6 +944,12 @@ static int cpc925_probe(struct platform_device *pdev)
>
> edac_dbg(0, "%s platform device found!\n", pdev->name);
>
> + cpc925_printk(KERN_INFO, CPC925_EDAC_REVISION "\n");
> + cpc925_printk(KERN_INFO, "\t(c) 2008 Wind River Systems, Inc\n");
> +
> + /* Only support POLL mode so far */
> + edac_op_state = EDAC_OPSTATE_POLL;
> +
> if (!devres_open_group(>dev, cpc925_probe, GFP_KERNEL)) {
> res = -ENOMEM;
> goto out;
> @@ -1065,32 +1071,7 @@ static struct platform_driver cpc925_edac_driver = {
> }
> };
>
> -static int __init cpc925_edac_init(void)
> -{
> - int ret = 0;
> -
> - printk(KERN_INFO "IBM CPC925 EDAC driver " CPC925_EDAC_REVISION "\n");
> - printk(KERN_INFO "\t(c) 2008 Wind River Systems, Inc\n");
> -
> - /* Only support POLL mode so far */
> - edac_op_state = EDAC_OPSTATE_POLL;
> -
> - ret = platform_driver_register(_edac_driver);
> - if (ret) {
> - printk(KERN_WARNING "Failed to register %s\n",
> - CPC925_EDAC_MOD_STR);
> - }
> -
> - return ret;
> -}
> -
> -static void __exit cpc925_edac_exit(void)
> -{
> - platform_driver_unregister(_edac_driver);
> -}
> -
> -module_init(cpc925_edac_init);
> -module_exit(cpc925_edac_exit);
> +module_platform_driver(cpc925_edac_driver);
>
> MODULE_LICENSE("GPL");
> MODULE_AUTHOR("Cao Qingtao ");
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] DMA, CMA: use general CMA reserved area management framework
On Tue, Jun 03, 2014 at 09:00:48AM +0200, Michal Nazarewicz wrote: > On Tue, Jun 03 2014, Joonsoo Kim wrote: > > Now, we have general CMA reserved area management framework, > > so use it for future maintainabilty. There is no functional change. > > > > Signed-off-by: Joonsoo Kim > > Acked-by: Michal Nazarewicz > > > diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h > > index dfb1dc9..ecb85ac 100644 > > --- a/include/linux/dma-contiguous.h > > +++ b/include/linux/dma-contiguous.h > > @@ -53,9 +53,10 @@ > > > > #ifdef __KERNEL__ > > > > +#include > > + > > Why is this suddenly required? > > > struct cma; > > struct page; > > -struct device; > > > > #ifdef CONFIG_DMA_CMA > Without including device.h, build failure occurs. In dma-contiguous.h, we try to access to dev->cma_area, so we need device.h. In the past, we included it luckily by swap.h in drivers/base/dma-contiguous.c. Swap.h includes node.h and then node.h includes device.h, so we were happy. But, in this patch, I remove 'include ' so we need to include device.h explicitly. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] block: make nr_requests tunable for loop
On 2014-06-09 20:31, Junxiao Bi wrote:
commit 7b5a3522 (loop: Limit the number of requests in the bio list) limit
the request number in loop queue to not over 128. Since the "request_fn" of
loop device is null, the requests number is not allowed tuned. Make it tunable
from sysfs can improve performance.
The following test is done on a machine with 512M memory. The backend of
/dev/loop1 is a nfs file.
[root@bijx mnt]# cat /sys/block/loop0/queue/nr_requests
128
[root@bijx mnt]# dd if=/dev/zero of=/dev/loop0 bs=1M count=5000
5000+0 records in
5000+0 records out
524288 bytes (5.2 GB) copied, 501.572 s, 10.5 MB/s
[root@bijx mnt]#
[root@bijx mnt]# echo 1024 > /sys/block/loop0/queue/nr_requests
[root@bijx mnt]# cat /sys/block/loop0/queue/nr_requests
1024
[root@bijx mnt]# dd if=/dev/zero of=/dev/loop0 bs=1M count=5000
5000+0 records in
5000+0 records out
524288 bytes (5.2 GB) copied, 464.481 s, 11.3 MB/s
Signed-off-by: Junxiao Bi
---
block/blk-core.c |6 ++
block/blk-sysfs.c |9 +++--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 40d6548..58c4bd4 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -851,6 +851,12 @@ int blk_update_nr_requests(struct request_queue *q,
unsigned int nr)
q->nr_requests = nr;
blk_queue_congestion_threshold(q);
+ /* for loop device, return after set its nr_requests */
+ if (!q->request_fn) {
+ spin_unlock_irq(q->queue_lock);
+ return 0;
+ }
It'd be prettier to split this differently - something ala:
if (request_fn)
blk_update_congestion_thresholds(q);
But I think you have a larger issue here... For the request lists, we
update the congestion thresholds and wakeup anyone waiting, if we need
to. There's no way to do that for loop, since the waitqueue is internal
to loop.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] CMA: generalize CMA reserved area management functionality
On Tue, Jun 03, 2014 at 08:56:00AM +0200, Michal Nazarewicz wrote:
> On Tue, Jun 03 2014, Joonsoo Kim wrote:
> > Currently, there are two users on CMA functionality, one is the DMA
> > subsystem and the other is the kvm on powerpc. They have their own code
> > to manage CMA reserved area even if they looks really similar.
> > From my guess, it is caused by some needs on bitmap management. Kvm side
> > wants to maintain bitmap not for 1 page, but for more size. Eventually it
> > use bitmap where one bit represents 64 pages.
> >
> > When I implement CMA related patches, I should change those two places
> > to apply my change and it seem to be painful to me. I want to change
> > this situation and reduce future code management overhead through
> > this patch.
> >
> > This change could also help developer who want to use CMA in their
> > new feature development, since they can use CMA easily without
> > copying & pasting this reserved area management code.
> >
> > Signed-off-by: Joonsoo Kim
>
> Some small comments below, but in general
>
> Acked-by: Michal Nazarewicz
Hello, Michal.
Thanks!
>
> >
> > diff --git a/include/linux/cma.h b/include/linux/cma.h
> > new file mode 100644
> > index 000..60ba06f
> > --- /dev/null
> > +++ b/include/linux/cma.h
> > @@ -0,0 +1,28 @@
> > +/*
> > + * Contiguous Memory Allocator
> > + *
> > + * Copyright LG Electronics Inc., 2014
> > + * Written by:
> > + * Joonsoo Kim
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of the
> > + * License or (at your optional) any later version of the license.
> > + *
>
> Superfluous empty comment line.
>
> Also, I'm not certain whether this copyright notice is appropriate here,
> but that's another story.
Yeah, I will remove copyright notice in .h file.
>
> > + */
> > +
> > +#ifndef __CMA_H__
> > +#define __CMA_H__
> > +
> > +struct cma;
> > +
> > +extern struct page *cma_alloc(struct cma *cma, unsigned long count,
> > + unsigned long align);
> > +extern bool cma_release(struct cma *cma, struct page *pages,
> > + unsigned long count);
> > +extern int __init cma_declare_contiguous(phys_addr_t size, phys_addr_t
> > base,
> > + phys_addr_t limit, phys_addr_t alignment,
> > + unsigned long bitmap_shift, bool fixed,
> > + struct cma **res_cma);
> > +#endif
>
> > diff --git a/mm/cma.c b/mm/cma.c
> > new file mode 100644
> > index 000..0dae88d
> > --- /dev/null
> > +++ b/mm/cma.c
> > @@ -0,0 +1,329 @@
>
> > +static int __init cma_activate_area(struct cma *cma)
> > +{
> > + int max_bitmapno = cma_bitmap_max_no(cma);
> > + int bitmap_size = BITS_TO_LONGS(max_bitmapno) * sizeof(long);
> > + unsigned long base_pfn = cma->base_pfn, pfn = base_pfn;
> > + unsigned i = cma->count >> pageblock_order;
> > + struct zone *zone;
> > +
> > + pr_debug("%s()\n", __func__);
> > + if (!cma->count)
> > + return 0;
>
> Alternatively:
>
> + if (!i)
> + return 0;
I prefer cma->count than i, since it represents what it does itself.
> > +
> > + cma->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
> > + if (!cma->bitmap)
> > + return -ENOMEM;
> > +
> > + WARN_ON_ONCE(!pfn_valid(pfn));
> > + zone = page_zone(pfn_to_page(pfn));
> > +
> > + do {
> > + unsigned j;
> > +
> > + base_pfn = pfn;
> > + for (j = pageblock_nr_pages; j; --j, pfn++) {
> > + WARN_ON_ONCE(!pfn_valid(pfn));
> > + /*
> > +* alloc_contig_range requires the pfn range
> > +* specified to be in the same zone. Make this
> > +* simple by forcing the entire CMA resv range
> > +* to be in the same zone.
> > +*/
> > + if (page_zone(pfn_to_page(pfn)) != zone)
> > + goto err;
> > + }
> > + init_cma_reserved_pageblock(pfn_to_page(base_pfn));
> > + } while (--i);
> > +
> > + mutex_init(>lock);
> > + return 0;
> > +
> > +err:
> > + kfree(cma->bitmap);
> > + return -EINVAL;
> > +}
>
> > +static int __init cma_init_reserved_areas(void)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < cma_area_count; i++) {
> > + int ret = cma_activate_area(_areas[i]);
> > +
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
>
> Or even:
>
> static int __init cma_init_reserved_areas(void)
> {
> int i, ret = 0;
> for (i = 0; !ret && i < cma_area_count; ++i)
> ret = cma_activate_area(_areas[i]);
> return ret;
> }
I think that originial implementation is better, since it seems
more readable to me.
> > +int __init
[PATCH v2] pinctrl: sh-pfc: r8a7791: Add HSCIF pin support
Signed-off-by: Nobuhiro Iwamatsu
Acked-by: Laurent Pinchart
---
V2: - Add pin map for hscif2_data_d.
- Add Acked-by: Laurent Pinchart
drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 250 +++
1 file changed, 250 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
index 7868bf3..482a805 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
@@ -1807,6 +1807,192 @@ static const unsigned int eth_rmii_mux[] = {
ETH_RXD0_MARK, ETH_RXD1_MARK, ETH_RX_ER_MARK, ETH_CRS_DV_MARK,
ETH_TXD0_MARK, ETH_TXD1_MARK, ETH_TX_EN_MARK, ETH_REFCLK_MARK,
};
+
+/* - HSCIF0 -
*/
+static const unsigned int hscif0_data_pins[] = {
+ /* RX, TX */
+ RCAR_GP_PIN(7, 3), RCAR_GP_PIN(7, 4),
+};
+static const unsigned int hscif0_data_mux[] = {
+ HRX0_MARK, HTX0_MARK,
+};
+static const unsigned int hscif0_clk_pins[] = {
+ /* SCK */
+ RCAR_GP_PIN(7, 2),
+};
+static const unsigned int hscif0_clk_mux[] = {
+ HSCK0_MARK,
+};
+static const unsigned int hscif0_ctrl_pins[] = {
+ /* RTS, CTS */
+ RCAR_GP_PIN(7, 1), RCAR_GP_PIN(7, 0),
+};
+static const unsigned int hscif0_ctrl_mux[] = {
+ HRTS0_N_MARK, HCTS0_N_MARK,
+};
+static const unsigned int hscif0_data_b_pins[] = {
+ /* RX, TX */
+ RCAR_GP_PIN(3, 12), RCAR_GP_PIN(3, 15),
+};
+static const unsigned int hscif0_data_b_mux[] = {
+ HRX0_B_MARK, HTX0_B_MARK,
+};
+static const unsigned int hscif0_ctrl_b_pins[] = {
+ /* RTS, CTS */
+ RCAR_GP_PIN(3, 14), RCAR_GP_PIN(3, 13),
+};
+static const unsigned int hscif0_ctrl_b_mux[] = {
+ HRTS0_N_B_MARK, HCTS0_N_B_MARK,
+};
+static const unsigned int hscif0_data_c_pins[] = {
+ /* RX, TX */
+ RCAR_GP_PIN(2, 0), RCAR_GP_PIN(2, 1),
+};
+static const unsigned int hscif0_data_c_mux[] = {
+ HRX0_C_MARK, HTX0_C_MARK,
+};
+static const unsigned int hscif0_clk_c_pins[] = {
+ /* SCK */
+ RCAR_GP_PIN(5, 31),
+};
+static const unsigned int hscif0_clk_c_mux[] = {
+ HSCK0_C_MARK,
+};
+/* - HSCIF1 -
*/
+static const unsigned int hscif1_data_pins[] = {
+ /* RX, TX */
+ RCAR_GP_PIN(7, 5), RCAR_GP_PIN(7, 6),
+};
+static const unsigned int hscif1_data_mux[] = {
+ HRX1_MARK, HTX1_MARK,
+};
+static const unsigned int hscif1_clk_pins[] = {
+ /* SCK */
+ RCAR_GP_PIN(7, 7),
+};
+static const unsigned int hscif1_clk_mux[] = {
+ HSCK1_MARK,
+};
+static const unsigned int hscif1_ctrl_pins[] = {
+ /* RTS, CTS */
+ RCAR_GP_PIN(7, 9), RCAR_GP_PIN(7, 8),
+};
+static const unsigned int hscif1_ctrl_mux[] = {
+ HRTS1_N_MARK, HCTS1_N_MARK,
+};
+static const unsigned int hscif1_data_b_pins[] = {
+ /* RX, TX */
+ RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
+};
+static const unsigned int hscif1_data_b_mux[] = {
+ HRX1_B_MARK, HTX1_B_MARK,
+};
+static const unsigned int hscif1_data_c_pins[] = {
+ /* RX, TX */
+ RCAR_GP_PIN(7, 14), RCAR_GP_PIN(7, 15),
+};
+static const unsigned int hscif1_data_c_mux[] = {
+ HRX1_C_MARK, HTX1_C_MARK,
+};
+static const unsigned int hscif1_clk_c_pins[] = {
+ /* SCK */
+ RCAR_GP_PIN(7, 16),
+};
+static const unsigned int hscif1_clk_c_mux[] = {
+ HSCK1_C_MARK,
+};
+static const unsigned int hscif1_ctrl_c_pins[] = {
+ /* RTS, CTS */
+ RCAR_GP_PIN(7, 18), RCAR_GP_PIN(7, 17),
+};
+static const unsigned int hscif1_ctrl_c_mux[] = {
+ HRTS1_N_C_MARK, HCTS1_N_C_MARK,
+};
+static const unsigned int hscif1_data_d_pins[] = {
+ /* RX, TX */
+ RCAR_GP_PIN(4, 28), RCAR_GP_PIN(4, 18),
+};
+static const unsigned int hscif1_data_d_mux[] = {
+ HRX1_D_MARK, HTX1_D_MARK,
+};
+static const unsigned int hscif1_data_e_pins[] = {
+ /* RX, TX */
+ RCAR_GP_PIN(7, 14), RCAR_GP_PIN(7, 15),
+};
+static const unsigned int hscif1_data_e_mux[] = {
+ HRX1_C_MARK, HTX1_C_MARK,
+};
+static const unsigned int hscif1_clk_e_pins[] = {
+ /* SCK */
+ RCAR_GP_PIN(2, 6),
+};
+static const unsigned int hscif1_clk_e_mux[] = {
+ HSCK1_E_MARK,
+};
+static const unsigned int hscif1_ctrl_e_pins[] = {
+ /* RTS, CTS */
+ RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 7),
+};
+static const unsigned int hscif1_ctrl_e_mux[] = {
+ HRTS1_N_E_MARK, HCTS1_N_E_MARK,
+};
+/* - HSCIF2 -
*/
+static const unsigned int hscif2_data_pins[] = {
+ /* RX, TX */
+ RCAR_GP_PIN(4, 16), RCAR_GP_PIN(4, 17),
+};
+static const unsigned int hscif2_data_mux[] = {
+ HRX2_MARK, HTX2_MARK,
+};
+static const unsigned int hscif2_clk_pins[] = {
+ /* SCK */
+ RCAR_GP_PIN(4, 15),
+};
+static const unsigned int hscif2_clk_mux[] = {
+ HSCK2_MARK,
+};
+static const unsigned int
RE: [REGRESSION] 3.15: Seems to turbo mode Intel Sandybridge Dual Core without need, overheating CPU
On 2014.06.08 14:42 Martin Steigerwald wrote: > Its not just me: > Please change intel_pstate default to disable > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647 That bug report is old, and made some sense at the time it was entered. Recent entries are all calling for it to be enabled by default again. For my part of it, I was merely suggesting caution. ... 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] pinctrl: sh-pfc: r8a7791: Add HSCIF pin support
Hi,
2014-06-09 20:25 GMT+09:00 Laurent Pinchart :
> Hi Iwamatsu-san,
>
> Thank you for the patch.
>
> On Thursday 29 May 2014 09:52:09 Nobuhiro Iwamatsu wrote:
>
> A commit message would be nice. You're also missing hscif2_data_d. That could
> be added later though, so
I will add hscif2_data_d and resend.
>
> Acked-by: Laurent Pinchart
>
Thanks!
Nobuhiro
>> Signed-off-by: Nobuhiro Iwamatsu
>> ---
>> drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 241
>> 1 file changed, 241 insertions(+)
>>
>> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
>> b/drivers/pinctrl/sh-pfc/pfc-r8a7791.c index 2e688dc..bb32514 100644
>> --- a/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
>> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
>> @@ -1867,6 +1867,185 @@ static const unsigned int eth_rmii_mux[] = {
>> ETH_RXD0_MARK, ETH_RXD1_MARK, ETH_RX_ER_MARK, ETH_CRS_DV_MARK,
>> ETH_TXD0_MARK, ETH_TXD1_MARK, ETH_TX_EN_MARK, ETH_REFCLK_MARK,
>> };
>> +
>> +/* - HSCIF0
>> - */
>> +static const unsigned int hscif0_data_pins[] = {
>> + /* RX, TX */
>> + RCAR_GP_PIN(7, 3), RCAR_GP_PIN(7, 4),
>> +};
>> +static const unsigned int hscif0_data_mux[] = {
>> + HRX0_MARK, HTX0_MARK,
>> +};
>> +static const unsigned int hscif0_clk_pins[] = {
>> + /* SCK */
>> + RCAR_GP_PIN(7, 2),
>> +};
>> +static const unsigned int hscif0_clk_mux[] = {
>> + HSCK0_MARK,
>> +};
>> +static const unsigned int hscif0_ctrl_pins[] = {
>> + /* RTS, CTS */
>> + RCAR_GP_PIN(7, 1), RCAR_GP_PIN(7, 0),
>> +};
>> +static const unsigned int hscif0_ctrl_mux[] = {
>> + HRTS0_N_MARK, HCTS0_N_MARK,
>> +};
>> +static const unsigned int hscif0_data_b_pins[] = {
>> + /* RX, TX */
>> + RCAR_GP_PIN(3, 12), RCAR_GP_PIN(3, 15),
>> +};
>> +static const unsigned int hscif0_data_b_mux[] = {
>> + HRX0_B_MARK, HTX0_B_MARK,
>> +};
>> +static const unsigned int hscif0_ctrl_b_pins[] = {
>> + /* RTS, CTS */
>> + RCAR_GP_PIN(3, 14), RCAR_GP_PIN(3, 13),
>> +};
>> +static const unsigned int hscif0_ctrl_b_mux[] = {
>> + HRTS0_N_B_MARK, HCTS0_N_B_MARK,
>> +};
>> +static const unsigned int hscif0_data_c_pins[] = {
>> + /* RX, TX */
>> + RCAR_GP_PIN(2, 0), RCAR_GP_PIN(2, 1),
>> +};
>> +static const unsigned int hscif0_data_c_mux[] = {
>> + HRX0_C_MARK, HTX0_C_MARK,
>> +};
>> +static const unsigned int hscif0_clk_c_pins[] = {
>> + /* SCK */
>> + RCAR_GP_PIN(5, 31),
>> +};
>> +static const unsigned int hscif0_clk_c_mux[] = {
>> + HSCK0_C_MARK,
>> +};
>> +/* - HSCIF1
>> - */
>> +static const unsigned int hscif1_data_pins[] = {
>> + /* RX, TX */
>> + RCAR_GP_PIN(7, 5), RCAR_GP_PIN(7, 6),
>> +};
>> +static const unsigned int hscif1_data_mux[] = {
>> + HRX1_MARK, HTX1_MARK,
>> +};
>> +static const unsigned int hscif1_clk_pins[] = {
>> + /* SCK */
>> + RCAR_GP_PIN(7, 7),
>> +};
>> +static const unsigned int hscif1_clk_mux[] = {
>> + HSCK1_MARK,
>> +};
>> +static const unsigned int hscif1_ctrl_pins[] = {
>> + /* RTS, CTS */
>> + RCAR_GP_PIN(7, 9), RCAR_GP_PIN(7, 8),
>> +};
>> +static const unsigned int hscif1_ctrl_mux[] = {
>> + HRTS1_N_MARK, HCTS1_N_MARK,
>> +};
>> +static const unsigned int hscif1_data_b_pins[] = {
>> + /* RX, TX */
>> + RCAR_GP_PIN(1, 17), RCAR_GP_PIN(1, 18),
>> +};
>> +static const unsigned int hscif1_data_b_mux[] = {
>> + HRX1_B_MARK, HTX1_B_MARK,
>> +};
>> +static const unsigned int hscif1_data_c_pins[] = {
>> + /* RX, TX */
>> + RCAR_GP_PIN(7, 14), RCAR_GP_PIN(7, 15),
>> +};
>> +static const unsigned int hscif1_data_c_mux[] = {
>> + HRX1_C_MARK, HTX1_C_MARK,
>> +};
>> +static const unsigned int hscif1_clk_c_pins[] = {
>> + /* SCK */
>> + RCAR_GP_PIN(7, 16),
>> +};
>> +static const unsigned int hscif1_clk_c_mux[] = {
>> + HSCK1_C_MARK,
>> +};
>> +static const unsigned int hscif1_ctrl_c_pins[] = {
>> + /* RTS, CTS */
>> + RCAR_GP_PIN(7, 18), RCAR_GP_PIN(7, 17),
>> +};
>> +static const unsigned int hscif1_ctrl_c_mux[] = {
>> + HRTS1_N_C_MARK, HCTS1_N_C_MARK,
>> +};
>> +static const unsigned int hscif1_data_d_pins[] = {
>> + /* RX, TX */
>> + RCAR_GP_PIN(4, 28), RCAR_GP_PIN(4, 18),
>> +};
>> +static const unsigned int hscif1_data_d_mux[] = {
>> + HRX1_D_MARK, HTX1_D_MARK,
>> +};
>> +static const unsigned int hscif1_data_e_pins[] = {
>> + /* RX, TX */
>> + RCAR_GP_PIN(7, 14), RCAR_GP_PIN(7, 15),
>> +};
>> +static const unsigned int hscif1_data_e_mux[] = {
>> + HRX1_C_MARK, HTX1_C_MARK,
>> +};
>> +static const unsigned int hscif1_clk_e_pins[] = {
>> + /* SCK */
>> + RCAR_GP_PIN(2, 6),
>> +};
>> +static const unsigned int hscif1_clk_e_mux[] = {
>> + HSCK1_E_MARK,
>> +};
>> +static const unsigned int hscif1_ctrl_e_pins[] = {
>> + /* RTS, CTS */
>> + RCAR_GP_PIN(2, 8), RCAR_GP_PIN(2, 7),
>> +};
>> +static const unsigned int
[PATCH V2] block: make nr_requests tunable for loop
commit 7b5a3522 (loop: Limit the number of requests in the bio list) limit
the request number in loop queue to not over 128. Since the "request_fn" of
loop device is null, the requests number is not allowed tuned. Make it tunable
from sysfs can improve performance.
The following test is done on a machine with 512M memory. The backend of
/dev/loop1 is a nfs file.
[root@bijx mnt]# cat /sys/block/loop0/queue/nr_requests
128
[root@bijx mnt]# dd if=/dev/zero of=/dev/loop0 bs=1M count=5000
5000+0 records in
5000+0 records out
524288 bytes (5.2 GB) copied, 501.572 s, 10.5 MB/s
[root@bijx mnt]#
[root@bijx mnt]# echo 1024 > /sys/block/loop0/queue/nr_requests
[root@bijx mnt]# cat /sys/block/loop0/queue/nr_requests
1024
[root@bijx mnt]# dd if=/dev/zero of=/dev/loop0 bs=1M count=5000
5000+0 records in
5000+0 records out
524288 bytes (5.2 GB) copied, 464.481 s, 11.3 MB/s
Signed-off-by: Junxiao Bi
---
block/blk-core.c |6 ++
block/blk-sysfs.c |9 +++--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 40d6548..58c4bd4 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -851,6 +851,12 @@ int blk_update_nr_requests(struct request_queue *q,
unsigned int nr)
q->nr_requests = nr;
blk_queue_congestion_threshold(q);
+ /* for loop device, return after set its nr_requests */
+ if (!q->request_fn) {
+ spin_unlock_irq(q->queue_lock);
+ return 0;
+ }
+
/* congestion isn't cgroup aware and follows root blkcg for now */
rl = >root_rl;
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index 23321fb..c5456a5 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -51,9 +51,6 @@ queue_requests_store(struct request_queue *q, const char
*page, size_t count)
unsigned long nr;
int ret, err;
- if (!q->request_fn && !q->mq_ops)
- return -EINVAL;
-
ret = queue_var_store(, page, count);
if (ret < 0)
return ret;
@@ -61,10 +58,10 @@ queue_requests_store(struct request_queue *q, const char
*page, size_t count)
if (nr < BLKDEV_MIN_RQ)
nr = BLKDEV_MIN_RQ;
- if (q->request_fn)
- err = blk_update_nr_requests(q, nr);
- else
+ if (q->mq_ops)
err = blk_mq_update_nr_requests(q, nr);
+ else
+ err = blk_update_nr_requests(q, nr);
if (err)
return err;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpc925_eadc: Use devm_ioremap_resource()
Convert to devm_ioremap_resource() to simplify code.
Signed-off-by: Kefeng Wang
---
drivers/edac/cpc925_edac.c | 30 ++
1 files changed, 6 insertions(+), 24 deletions(-)
diff --git a/drivers/edac/cpc925_edac.c b/drivers/edac/cpc925_edac.c
index df6575f..b335c14 100644
--- a/drivers/edac/cpc925_edac.c
+++ b/drivers/edac/cpc925_edac.c
@@ -950,28 +950,12 @@ static int cpc925_probe(struct platform_device *pdev)
}
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!r) {
- cpc925_printk(KERN_ERR, "Unable to get resource\n");
- res = -ENOENT;
+ vbase = devm_ioremap_resource(>dev, r);
+ if (IS_ERR(vbase)) {
+ res = PTR_ERR(vbase);
goto err1;
}
- if (!devm_request_mem_region(>dev,
-r->start,
-resource_size(r),
-pdev->name)) {
- cpc925_printk(KERN_ERR, "Unable to request mem region\n");
- res = -EBUSY;
- goto err1;
- }
-
- vbase = devm_ioremap(>dev, r->start, resource_size(r));
- if (!vbase) {
- cpc925_printk(KERN_ERR, "Unable to ioremap device\n");
- res = -ENOMEM;
- goto err2;
- }
-
nr_channels = cpc925_mc_get_channels(vbase) + 1;
layers[0].type = EDAC_MC_LAYER_CHIP_SELECT;
@@ -985,7 +969,7 @@ static int cpc925_probe(struct platform_device *pdev)
if (!mci) {
cpc925_printk(KERN_ERR, "No memory for mem_ctl_info\n");
res = -ENOMEM;
- goto err2;
+ goto err1;
}
pdata = mci->pvt_info;
@@ -1018,7 +1002,7 @@ static int cpc925_probe(struct platform_device *pdev)
if (edac_mc_add_mc(mci) > 0) {
cpc925_mc_printk(mci, KERN_ERR, "Failed edac_mc_add_mc()\n");
- goto err3;
+ goto err2;
}
cpc925_add_edac_devices(vbase);
@@ -1029,11 +1013,9 @@ static int cpc925_probe(struct platform_device *pdev)
res = 0;
goto out;
-err3:
+err2:
cpc925_mc_exit(mci);
edac_mc_free(mci);
-err2:
- devm_release_mem_region(>dev, r->start, resource_size(r));
err1:
devres_release_group(>dev, cpc925_probe);
out:
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: make nr_requests tunable for loop
On 2014-06-09 19:35, Junxiao Bi wrote: On 06/09/2014 11:53 PM, Jens Axboe wrote: On 2014-06-09 01:29, Andreas Mohr wrote: Hi, having had a look at current mainline sources, frankly I've (well, initially...) got trouble understanding what this patch is doing. It's replacing an aggressive error-type bail-out (-EINVAL) for NULL request_fn with an inoccuous-looking "return ret;", yet that ret content currently *implicitly* is a >= 0 value (resulting from processing by earlier code which may or may not get incomprehensibly rewritten in future). I don't understand the reasons for this huge change in return value handling (since it's now not assigning a specific return value for this modified bail-out case). OK, well... you could say that since all this function ever was interested in is the result value of queue_var_store() (except for error bail-out cases), doing an interim "return ret;" (which is exactly what the function tail is also doing) is exactly right. But still simple textual appearance of the resulting patch hunks seems strangely asymmetric which may easily be a canary for structurally wrong layering of this function. Not to mention the now required extra spin_unlock_irq() in interim return handler... Well, after further analysis I would come to the conclusion that in general queue_requests_store() does a LOT more than it should - since blk-sysfs.c's only (expected!) purpose is to do parameterization of request_queue behaviour as gathered from sysfs attribute space, all that function should ever be concerned with is parsing that sysfs value and then calling a blk helper for configuration of that very attribute value which would *internally* do all the strange internal queue magic that is currently being updated *open-coded* at this supposedly *sysfs*-specific place. Ugh. Main question here: what would one do if one decided to rip out sysfs and use something entirely different for parameterization? Yeah indeed - thought so... So yeah, I'd definitely say that that function is lacking some cleanup which would possibly then even lead (or: would have led ;) to a much more nicely symmetric textual appearance of the patch hunk of the small but quite likely useful change that you currently intend to have here. If you are done ranting, look at the current tree where it has been split out. There was no reason to have it split before, since the sysfs entry point was the only place where we updated nr_requests. If that code has been duplicated, there would have been a justified reason for writing two pages about it. Yes, agree, this is the only place updating nr_requests, we can split it as a separated function if it needs updating at some other places in future. Please look at the current tree... It is already split up. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/05] staging: Emma Mobile USB driver and KZM9D board code V3
On Mon, Jun 09, 2014 at 02:14:38PM +0900, Magnus Damm wrote: > On Sat, Jun 7, 2014 at 12:39 AM, Greg KH wrote: > > On Fri, Jun 06, 2014 at 07:44:08PM +0900, Magnus Damm wrote: > >> staging: Emma Mobile USB driver and KZM9D board code V3 > >> > >> [PATCH v3 01/05] staging: emxx_udc: Add Emma Mobile USB Gadget driver > >> [PATCH v3 02/05] staging: emxx_udc: I/O memory and IRQ resource support > >> [PATCH v3 03/05] staging: emxx_udc: Add TODO file > >> [PATCH v3 04/05] staging: board: Initial board staging support > >> [PATCH v3 05/05] staging: board: kzm9d: Board staging support for emxx_udc > >> > >> This patch series is V3 of the old USB Gadget driver for Emma Mobile > >> that gets slightly adjusted to make use of the platform device interface > >> which in turn is used to add USB Gadget support to the KZM9D board. > >> > >> Two separate staging components are included in this series: > >> 1) the emxx_udc driver - from out-of-tree Android 2.6.35.7 > >> 2) board staging support for KZM9D - platform device for DT-only KZM9D > >> > >> The two components above will be used to continously improve the driver > >> and board integration code until the driver can be moved out of staging > >> and/or DT bindings are available so the board staging platform device code > >> can be replaced with a DT node. > >> > >> Changes since V2: > >> - Added CONFIG_OF_ADDRESS dependency for the board staging bits > >> > >> Changes since V1: > >> - Added TODO file for emxx_udc > >> - Broke out board staging base support, included TODO file > >> - Added code to avoid registering platform device if DT node exists > >> - Modified KZM9D board code build condition to use SoC Kconfig entry > >> > >> Many thanks to Dan Carpenter, Geert Uytterhoeven, Greg KH and > >> Paul Bolle for feedback! > >> > >> Please let me know if you would like me to rebase this code somehow. > > > > At quick glance, this looks good. I'll queue it up after 3.16-rc1 is > > out as it's too late for this merge window. > > Thanks, Greg! This sounds perfect to me! FWIW, Acked-by: Simon Horman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 04/05] staging: board: Initial board staging support
On Fri, Jun 06, 2014 at 09:07:44PM +0900, Magnus Damm wrote: > On Fri, May 30, 2014 at 8:10 AM, Simon Horman wrote: > > On Thu, May 29, 2014 at 10:27:30PM +0900, Magnus Damm wrote: > >> Hi Dan, > >> > >> On Thu, May 29, 2014 at 10:20 PM, Dan Carpenter > >> wrote: > >> > On Thu, May 29, 2014 at 10:17:32PM +0900, Magnus Damm wrote: > >> >> --- /dev/null > >> >> +++ work/drivers/staging/board/Kconfig2014-05-29 > >> >> 21:40:41.0 +0900 > >> >> @@ -0,0 +1,7 @@ > >> >> +config STAGING_BOARD > >> >> + boolean "Staging Board Support" > >> >> + help > >> >> + Select to enable per-board staging support code. > >> >> + > >> >> + If in doubt, say N here. > >> >> + > >> > > >> > Actually, you're probably going to need to add a bunch of dependencies > >> > here or it will break "make randconfig" right away. Sorry that I forgot > >> > about this in the first review. > >> > >> Good point, thanks for checking. I will have a look at this and add > >> dependencies to make sure it builds on a wide range of platforms. > > > > Hi Magnus, > > > > let me know if you would like me to perform some build-testing. > > Hey Simon, > > Thanks for the offer. When you have time, can you please feed V3 into > your build test setup? > > [PATCH v3 00/05] staging: Emma Mobile USB driver and KZM9D board code V3 > [PATCH v3 01/05] staging: emxx_udc: Add Emma Mobile USB Gadget driver > [PATCH v3 02/05] staging: emxx_udc: I/O memory and IRQ resource support > [PATCH v3 03/05] staging: emxx_udc: Add TODO file > [PATCH v3 04/05] staging: board: Initial board staging support > [PATCH v3 05/05] staging: board: kzm9d: Board staging support for emxx_udc Hi Magnus, my test was less exciting as I had hoped as STAGING is not widely enabled in defconfigs. I compiled v3.15-rc8 with the patches above applied using the defconfigs and allmodconfigs for a wide range of architectures. The result was that all of the configs that built for v3.15-rc8 also built with your patches applied. In other words, I did not find a 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 for-next 00/15] Bug fixes for ocrdma driver
> -Original Message- > From: Or Gerlitz [mailto:or.gerl...@gmail.com] > Sent: Tuesday, June 10, 2014 1:15 AM > To: Roland Dreier; Selvin Xavier > Cc: Steve Wise; linux-r...@vger.kernel.org; linux-kernel > Subject: Re: [PATCH for-next 00/15] Bug fixes for ocrdma driver > > On Wed, Jun 4, 2014 at 8:06 PM, Roland Dreier wrote: > > On Wed, Jun 4, 2014 at 9:37 AM, Steve Wise > wrote: > >> Seems like the subject lines in each patch are getting truncated? > > Yes, truncated in patchwork too -- for example: > > https://patchwork.kernel.org/patch/4292461/ > > > > Please fix and resend. > > Roland, from quick looking on this series of fifteen patches, only 1/3 of them > (4/5/12/14) have non-empty change-log. I would expect kernel work which > goes upstream through linux-rdma to use a bit of higher standards, agree? > > Selvin, can you sit down and come up with change-logs to your driver > updates? > > Or. Or, Sure, I will post v1 patch set with proper change-logs. Thanks, Selvin Xavier
Re: [PATCH] block: make nr_requests tunable for loop
On 06/09/2014 11:53 PM, Jens Axboe wrote: > On 2014-06-09 01:29, Andreas Mohr wrote: >> Hi, >> >> having had a look at current mainline sources, >> frankly I've (well, initially...) got trouble understanding >> what this patch is doing. >> >> It's replacing an aggressive error-type bail-out (-EINVAL) for NULL >> request_fn >> with an inoccuous-looking "return ret;", yet that ret content currently >> *implicitly* is a >= 0 value (resulting from processing by earlier code >> which may or may not get incomprehensibly rewritten in future). >> I don't understand the reasons for this huge change in return value >> handling >> (since it's now not assigning a specific return value >> for this modified bail-out case). >> >> OK, well... you could say that since all this function ever was >> interested in is the result value of queue_var_store() >> (except for error bail-out cases), doing an interim "return ret;" >> (which is exactly what the function tail is also doing) >> is exactly right. >> >> But still simple textual appearance of the resulting patch hunks >> seems strangely asymmetric >> which may easily be a canary for structurally wrong layering of this >> function. >> Not to mention the now required extra spin_unlock_irq() >> in interim return handler... >> >> >> Well, after further analysis I would come to the conclusion >> that in general queue_requests_store() does a LOT more than it should - >> since blk-sysfs.c's only (expected!) purpose is >> to do parameterization of request_queue behaviour as gathered >> from sysfs attribute space, >> all that function should ever be concerned with is parsing that sysfs >> value >> and then calling a blk helper for configuration of that very >> attribute value >> which would *internally* do all the strange internal queue magic >> that is currently being updated *open-coded* >> at this supposedly *sysfs*-specific place. Ugh. >> Main question here: what would one do if one decided to rip out sysfs >> and use something entirely different for parameterization? >> Yeah indeed - thought so... >> >> >> So yeah, I'd definitely say that that function is lacking some cleanup >> which would possibly then even lead (or: would have led ;) >> to a much more nicely symmetric textual appearance >> of the patch hunk of the small but quite likely useful change >> that you currently intend to have here. > > If you are done ranting, look at the current tree where it has been > split out. There was no reason to have it split before, since the > sysfs entry point was the only place where we updated nr_requests. If > that code has been duplicated, there would have been a justified > reason for writing two pages about it. Yes, agree, this is the only place updating nr_requests, we can split it as a separated function if it needs updating at some other places in future. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 02/12] clk: mmp: add spin lock for clk-frac
From: Chao Xie
The register used by clk-frac may be shared with
other clocks.
So it needs to use spin lock to protect the register
access.
Signed-off-by: Chao Xie
---
drivers/clk/mmp/clk-frac.c | 11 ++-
drivers/clk/mmp/clk-mmp2.c | 2 +-
drivers/clk/mmp/clk-pxa168.c | 2 +-
drivers/clk/mmp/clk-pxa910.c | 2 +-
drivers/clk/mmp/clk.h| 3 ++-
5 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index 3fbc9ca..e29d006 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -29,6 +29,7 @@ struct mmp_clk_factor {
struct mmp_clk_factor_masks *masks;
struct mmp_clk_factor_tbl *ftbl;
unsigned intftbl_cnt;
+ spinlock_t *lock;
};
static long clk_factor_round_rate(struct clk_hw *hw, unsigned long drate,
@@ -86,6 +87,7 @@ static int clk_factor_set_rate(struct clk_hw *hw, unsigned
long drate,
int i;
unsigned long val;
unsigned long prev_rate, rate = 0;
+ unsigned long flags = 0;
for (i = 0; i < factor->ftbl_cnt; i++) {
prev_rate = rate;
@@ -97,6 +99,9 @@ static int clk_factor_set_rate(struct clk_hw *hw, unsigned
long drate,
if (i > 0)
i--;
+ if (factor->lock)
+ spin_lock_irqsave(factor->lock, flags);
+
val = readl_relaxed(factor->base);
val &= ~(masks->num_mask << masks->num_shift);
@@ -107,6 +112,9 @@ static int clk_factor_set_rate(struct clk_hw *hw, unsigned
long drate,
writel_relaxed(val, factor->base);
+ if (factor->lock)
+ spin_unlock_irqrestore(factor->lock, flags);
+
return 0;
}
@@ -120,7 +128,7 @@ struct clk *mmp_clk_register_factor(const char *name, const
char *parent_name,
unsigned long flags, void __iomem *base,
struct mmp_clk_factor_masks *masks,
struct mmp_clk_factor_tbl *ftbl,
- unsigned int ftbl_cnt)
+ unsigned int ftbl_cnt, spinlock_t *lock)
{
struct mmp_clk_factor *factor;
struct clk_init_data init;
@@ -143,6 +151,7 @@ struct clk *mmp_clk_register_factor(const char *name, const
char *parent_name,
factor->ftbl = ftbl;
factor->ftbl_cnt = ftbl_cnt;
factor->hw.init =
+ factor->lock = lock;
init.name = name;
init.ops = _factor_ops;
diff --git a/drivers/clk/mmp/clk-mmp2.c b/drivers/clk/mmp/clk-mmp2.c
index 7083f12..5c90a42 100644
--- a/drivers/clk/mmp/clk-mmp2.c
+++ b/drivers/clk/mmp/clk-mmp2.c
@@ -191,7 +191,7 @@ void __init mmp2_clk_init(void)
clk = mmp_clk_register_factor("uart_pll", "pll1_4", 0,
mpmu_base + MPMU_UART_PLL,
_factor_masks, uart_factor_tbl,
- ARRAY_SIZE(uart_factor_tbl));
+ ARRAY_SIZE(uart_factor_tbl), _lock);
clk_set_rate(clk, 14745600);
clk_register_clkdev(clk, "uart_pll", NULL);
diff --git a/drivers/clk/mmp/clk-pxa168.c b/drivers/clk/mmp/clk-pxa168.c
index 75266ac..93e967c 100644
--- a/drivers/clk/mmp/clk-pxa168.c
+++ b/drivers/clk/mmp/clk-pxa168.c
@@ -158,7 +158,7 @@ void __init pxa168_clk_init(void)
uart_pll = mmp_clk_register_factor("uart_pll", "pll1_4", 0,
mpmu_base + MPMU_UART_PLL,
_factor_masks, uart_factor_tbl,
- ARRAY_SIZE(uart_factor_tbl));
+ ARRAY_SIZE(uart_factor_tbl), _lock);
clk_set_rate(uart_pll, 14745600);
clk_register_clkdev(uart_pll, "uart_pll", NULL);
diff --git a/drivers/clk/mmp/clk-pxa910.c b/drivers/clk/mmp/clk-pxa910.c
index f817999..993abcd 100644
--- a/drivers/clk/mmp/clk-pxa910.c
+++ b/drivers/clk/mmp/clk-pxa910.c
@@ -163,7 +163,7 @@ void __init pxa910_clk_init(void)
uart_pll = mmp_clk_register_factor("uart_pll", "pll1_4", 0,
mpmu_base + MPMU_UART_PLL,
_factor_masks, uart_factor_tbl,
- ARRAY_SIZE(uart_factor_tbl));
+ ARRAY_SIZE(uart_factor_tbl), _lock);
clk_set_rate(uart_pll, 14745600);
clk_register_clkdev(uart_pll, "uart_pll", NULL);
diff --git a/drivers/clk/mmp/clk.h b/drivers/clk/mmp/clk.h
index 3fe92be..b71b717 100644
--- a/drivers/clk/mmp/clk.h
+++ b/drivers/clk/mmp/clk.h
@@ -31,5 +31,6 @@ extern struct clk *mmp_clk_register_apmu(const char *name,
extern struct clk *mmp_clk_register_factor(const char *name,
const char *parent_name, unsigned long flags,
void __iomem *base, struct mmp_clk_factor_masks *masks,
- struct mmp_clk_factor_tbl *ftbl, unsigned int ftbl_cnt);
+ struct mmp_clk_factor_tbl *ftbl, unsigned int ftbl_cnt,
+ spinlock_t *lock);
#endif
--
1.8.3.2
--
To
[PATCH 00/12] clk: mmp: clock device tree support
From: Chao Xie The patch set focuses at support device tree for clock. The first part of the patches clk: mmp: add prefix "mmp" for structures defined for clk-frac clk: mmp: add spin lock for clk-frac clk: mmp: add init callback for clk-frac clk: mmp: move definiton of mmp_clk_frac to clk.h It enhances the clk-frac. The second part of the patches clk: mmp: add clock type mix clk: mmp: add mmp private gate clock clk: mmp: add clock type composite for mix It add three new types of clocks. The third part of the patches clk: mmp: add clock type master clk: mmp: add spin lock automatic detection from device tree clk: mmp: add device tree support for composite type clock clk: mmp: add device tree support for clocks. It add the device tree support. The whole clock tree is not defined in .c file, but be parsed from the device tree file. The final part of the patches arm: mmp: support clock device tree for mmp platforms Change the mmp platform to use device tree to parse the clocks. Chao Xie (12): clk: mmp: add prefix "mmp" for structures defined for clk-frac clk: mmp: add spin lock for clk-frac clk: mmp: add init callback for clk-frac clk: mmp: move definiton of mmp_clk_frac to clk.h clk: mmp: add clock type mix clk: mmp: add mmp private gate clock clk: mmp: add clock type composite for mix clk: mmp: add clock type master clk: mmp: add spin lock automatic detection from device tree clk: mmp: add device tree support for composite type clock clk: mmp: add device tree support for clocks. arm: mmp: support clock device tree for mmp platforms .../devicetree/bindings/clock/mmp/clk-composite| 58 ++ .../devicetree/bindings/clock/mmp/clk-div | 28 + .../devicetree/bindings/clock/mmp/clk-factor | 28 + .../devicetree/bindings/clock/mmp/clk-gate | 41 ++ .../devicetree/bindings/clock/mmp/clk-master | 47 ++ .../devicetree/bindings/clock/mmp/clk-mix | 38 ++ .../devicetree/bindings/clock/mmp/clk-mux | 20 + Documentation/devicetree/bindings/clock/mmp/lock | 44 ++ arch/arm/boot/dts/mmp2-clock.dtsi | 575 + arch/arm/boot/dts/mmp2.dtsi| 11 + arch/arm/boot/dts/pxa168-clock.dtsi| 443 + arch/arm/boot/dts/pxa168.dtsi | 10 + arch/arm/boot/dts/pxa910-clock.dtsi| 388 arch/arm/boot/dts/pxa910.dtsi | 10 + arch/arm/mach-mmp/Kconfig | 7 +- arch/arm/mach-mmp/Makefile | 2 +- arch/arm/mach-mmp/common.h | 1 + arch/arm/mach-mmp/mmp-dt.c | 57 +- arch/arm/mach-mmp/mmp2-dt.c| 50 -- drivers/clk/mmp/Makefile | 7 +- drivers/clk/mmp/clk-frac.c | 74 ++- drivers/clk/mmp/clk-gate.c | 133 drivers/clk/mmp/clk-master-node.c | 195 ++ drivers/clk/mmp/clk-mix-composite.c| 195 ++ drivers/clk/mmp/clk-mix.c | 419 + drivers/clk/mmp/clk-mmp2.c | 6 +- drivers/clk/mmp/clk-of-composite.c | 253 drivers/clk/mmp/clk-of.c | 689 + drivers/clk/mmp/clk-pxa168.c | 6 +- drivers/clk/mmp/clk-pxa910.c | 6 +- drivers/clk/mmp/clk.h | 164 - drivers/clk/mmp/lock.c | 159 + 32 files changed, 4035 insertions(+), 129 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/mmp/clk-composite create mode 100644 Documentation/devicetree/bindings/clock/mmp/clk-div create mode 100644 Documentation/devicetree/bindings/clock/mmp/clk-factor create mode 100644 Documentation/devicetree/bindings/clock/mmp/clk-gate create mode 100644 Documentation/devicetree/bindings/clock/mmp/clk-master create mode 100644 Documentation/devicetree/bindings/clock/mmp/clk-mix create mode 100644 Documentation/devicetree/bindings/clock/mmp/clk-mux create mode 100644 Documentation/devicetree/bindings/clock/mmp/lock create mode 100644 arch/arm/boot/dts/mmp2-clock.dtsi create mode 100644 arch/arm/boot/dts/pxa168-clock.dtsi create mode 100644 arch/arm/boot/dts/pxa910-clock.dtsi delete mode 100644 arch/arm/mach-mmp/mmp2-dt.c create mode 100644 drivers/clk/mmp/clk-gate.c create mode 100644 drivers/clk/mmp/clk-master-node.c create mode 100644 drivers/clk/mmp/clk-mix-composite.c create mode 100644 drivers/clk/mmp/clk-mix.c create mode 100644 drivers/clk/mmp/clk-of-composite.c create mode 100644 drivers/clk/mmp/clk-of.c create mode 100644 drivers/clk/mmp/lock.c -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More
[PATCH 01/12] clk: mmp: add prefix "mmp" for structures defined for clk-frac
From: Chao Xie
The structures defined for clk-frac will be used out side
of clk-frac.c.
To avoid conflicts, add prefix "mmp" for these structures'
name.
Signed-off-by: Chao Xie
---
drivers/clk/mmp/clk-frac.c | 23 ---
drivers/clk/mmp/clk-mmp2.c | 4 ++--
drivers/clk/mmp/clk-pxa168.c | 4 ++--
drivers/clk/mmp/clk-pxa910.c | 4 ++--
drivers/clk/mmp/clk.h| 8
5 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index 23a56f5..3fbc9ca 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -22,19 +22,19 @@
* numerator/denominator = Fin / (Fout * factor)
*/
-#define to_clk_factor(hw) container_of(hw, struct clk_factor, hw)
-struct clk_factor {
+#define to_clk_factor(hw) container_of(hw, struct mmp_clk_factor, hw)
+struct mmp_clk_factor {
struct clk_hw hw;
void __iomem*base;
- struct clk_factor_masks *masks;
- struct clk_factor_tbl *ftbl;
+ struct mmp_clk_factor_masks *masks;
+ struct mmp_clk_factor_tbl *ftbl;
unsigned intftbl_cnt;
};
static long clk_factor_round_rate(struct clk_hw *hw, unsigned long drate,
unsigned long *prate)
{
- struct clk_factor *factor = to_clk_factor(hw);
+ struct mmp_clk_factor *factor = to_clk_factor(hw);
unsigned long rate = 0, prev_rate;
int i;
@@ -58,8 +58,8 @@ static long clk_factor_round_rate(struct clk_hw *hw, unsigned
long drate,
static unsigned long clk_factor_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
- struct clk_factor *factor = to_clk_factor(hw);
- struct clk_factor_masks *masks = factor->masks;
+ struct mmp_clk_factor *factor = to_clk_factor(hw);
+ struct mmp_clk_factor_masks *masks = factor->masks;
unsigned int val, num, den;
val = readl_relaxed(factor->base);
@@ -81,8 +81,8 @@ static unsigned long clk_factor_recalc_rate(struct clk_hw *hw,
static int clk_factor_set_rate(struct clk_hw *hw, unsigned long drate,
unsigned long prate)
{
- struct clk_factor *factor = to_clk_factor(hw);
- struct clk_factor_masks *masks = factor->masks;
+ struct mmp_clk_factor *factor = to_clk_factor(hw);
+ struct mmp_clk_factor_masks *masks = factor->masks;
int i;
unsigned long val;
unsigned long prev_rate, rate = 0;
@@ -118,10 +118,11 @@ static struct clk_ops clk_factor_ops = {
struct clk *mmp_clk_register_factor(const char *name, const char *parent_name,
unsigned long flags, void __iomem *base,
- struct clk_factor_masks *masks, struct clk_factor_tbl *ftbl,
+ struct mmp_clk_factor_masks *masks,
+ struct mmp_clk_factor_tbl *ftbl,
unsigned int ftbl_cnt)
{
- struct clk_factor *factor;
+ struct mmp_clk_factor *factor;
struct clk_init_data init;
struct clk *clk;
diff --git a/drivers/clk/mmp/clk-mmp2.c b/drivers/clk/mmp/clk-mmp2.c
index b2721ca..7083f12 100644
--- a/drivers/clk/mmp/clk-mmp2.c
+++ b/drivers/clk/mmp/clk-mmp2.c
@@ -54,7 +54,7 @@
static DEFINE_SPINLOCK(clk_lock);
-static struct clk_factor_masks uart_factor_masks = {
+static struct mmp_clk_factor_masks uart_factor_masks = {
.factor = 2,
.num_mask = 0x1fff,
.den_mask = 0x1fff,
@@ -62,7 +62,7 @@ static struct clk_factor_masks uart_factor_masks = {
.den_shift = 0,
};
-static struct clk_factor_tbl uart_factor_tbl[] = {
+static struct mmp_clk_factor_tbl uart_factor_tbl[] = {
{.num = 14634, .den = 2165},/*14.745MHZ */
{.num = 3521, .den = 689}, /*19.23MHZ */
{.num = 9679, .den = 5728}, /*58.9824MHZ */
diff --git a/drivers/clk/mmp/clk-pxa168.c b/drivers/clk/mmp/clk-pxa168.c
index 014396b..75266ac 100644
--- a/drivers/clk/mmp/clk-pxa168.c
+++ b/drivers/clk/mmp/clk-pxa168.c
@@ -47,7 +47,7 @@
static DEFINE_SPINLOCK(clk_lock);
-static struct clk_factor_masks uart_factor_masks = {
+static struct mmp_clk_factor_masks uart_factor_masks = {
.factor = 2,
.num_mask = 0x1fff,
.den_mask = 0x1fff,
@@ -55,7 +55,7 @@ static struct clk_factor_masks uart_factor_masks = {
.den_shift = 0,
};
-static struct clk_factor_tbl uart_factor_tbl[] = {
+static struct mmp_clk_factor_tbl uart_factor_tbl[] = {
{.num = 8125, .den = 1536}, /*14.745MHZ */
};
diff --git a/drivers/clk/mmp/clk-pxa910.c b/drivers/clk/mmp/clk-pxa910.c
index 9efc6a4..f817999 100644
--- a/drivers/clk/mmp/clk-pxa910.c
+++ b/drivers/clk/mmp/clk-pxa910.c
@@ -45,7 +45,7 @@
static DEFINE_SPINLOCK(clk_lock);
-static struct clk_factor_masks uart_factor_masks = {
+static struct mmp_clk_factor_masks uart_factor_masks = {
.factor = 2,
.num_mask = 0x1fff,
.den_mask = 0x1fff,
@@ -53,7 +53,7 @@ static struct
Re: [PATCHv3 2/3] regulator: s2mps11: Add support S2MPU02 regulator device
Hi Mark,
On 06/10/2014 04:55 AM, Mark Brown wrote:
> On Mon, Jun 09, 2014 at 03:15:47PM +0900, Chanwoo Choi wrote:
>> This patch add S2MPU02 regulator device to existing S2MPS11 device driver
>> because of little difference between S2MPS1x and S2MPU02. The S2MPU02
>> regulator device includes LDO[1-28] and BUCK[1-7].
>
> Acked-by: Mark Brown
>
> but a few nits:
>
>> +case S2MPS14X:
>> +switch (rdev_id) {
>> +case S2MPS14_LDO3:
>> +return 0;
>> +};
>
> Extra ; here, and a missing default case here and in the rest of the
> switches. The default cases have no effect but are better style.
>
OK, I'll add 'default' case statement.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/12] clk: mmp: add mmp private gate clock
From: Chao Xie
Some SOCes have this kind of the gate clock
1. There are some bits to control the gate not only one bit.
2. Some clocks has operations of "out of reset" and "enable".
To enable clock, we need do "out of reset" and "enable".
To disable clock, we may not need "set to reset". It depends
on the SOCes' design.
3. It is not always that "1" is to enable while "0" is to disable
when write register.
So we have to define the "mask", "enable_val", "disable_val" for
this kind of gate clock.
Signed-off-by: Chao Xie
---
drivers/clk/mmp/Makefile | 2 +-
drivers/clk/mmp/clk-gate.c | 133 +
drivers/clk/mmp/clk.h | 21 +++
3 files changed, 155 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/mmp/clk-gate.c
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 8bfee860..2855f7b 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -2,7 +2,7 @@
# Makefile for mmp specific clk
#
-obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o
+obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o clk-gate.o
obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
diff --git a/drivers/clk/mmp/clk-gate.c b/drivers/clk/mmp/clk-gate.c
new file mode 100644
index 000..adbd9d6
--- /dev/null
+++ b/drivers/clk/mmp/clk-gate.c
@@ -0,0 +1,133 @@
+/*
+ * mmp gate clock operation source file
+ *
+ * Copyright (C) 2014 Marvell
+ * Chao Xie
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+/*
+ * Some clocks will have mutiple bits to enable the clocks, and
+ * the bits to disable the clock is not same as enabling bits.
+ */
+
+#define to_clk_mmp_gate(hw)container_of(hw, struct mmp_clk_gate, hw)
+
+static int mmp_clk_gate_enable(struct clk_hw *hw)
+{
+ struct mmp_clk_gate *gate = to_clk_mmp_gate(hw);
+ struct clk *clk = hw->clk;
+ unsigned long flags = 0;
+ unsigned long rate;
+ u32 tmp;
+
+ if (gate->lock)
+ spin_lock_irqsave(gate->lock, flags);
+
+ tmp = readl(gate->reg);
+ tmp &= ~gate->mask;
+ tmp |= gate->val_enable;
+ writel(tmp, gate->reg);
+
+ if (gate->lock)
+ spin_unlock_irqrestore(gate->lock, flags);
+
+ if (gate->flags & MMP_CLK_GATE_NEED_DELAY) {
+ rate = __clk_get_rate(clk);
+ /* Need delay 2 cycles. */
+ udelay(200/rate);
+ }
+
+ return 0;
+}
+
+static void mmp_clk_gate_disable(struct clk_hw *hw)
+{
+ struct mmp_clk_gate *gate = to_clk_mmp_gate(hw);
+ unsigned long flags = 0;
+ u32 tmp;
+
+ if (gate->lock)
+ spin_lock_irqsave(gate->lock, flags);
+
+ tmp = readl(gate->reg);
+ tmp &= ~gate->mask;
+ tmp |= gate->val_disable;
+ writel(tmp, gate->reg);
+
+ if (gate->lock)
+ spin_unlock_irqrestore(gate->lock, flags);
+}
+
+static int mmp_clk_gate_is_enabled(struct clk_hw *hw)
+{
+ struct mmp_clk_gate *gate = to_clk_mmp_gate(hw);
+ unsigned long flags = 0;
+ u32 tmp;
+
+ if (gate->lock)
+ spin_lock_irqsave(gate->lock, flags);
+
+ tmp = readl(gate->reg);
+
+ if (gate->lock)
+ spin_unlock_irqrestore(gate->lock, flags);
+
+ return (tmp & gate->mask) == gate->val_enable;
+}
+
+const struct clk_ops mmp_clk_gate_ops = {
+ .enable = mmp_clk_gate_enable,
+ .disable = mmp_clk_gate_disable,
+ .is_enabled = mmp_clk_gate_is_enabled,
+};
+
+struct clk *mmp_clk_register_gate(struct device *dev, const char *name,
+ const char *parent_name, unsigned long flags,
+ void __iomem *reg, u32 mask, u32 val_enable, u32 val_disable,
+ unsigned int gate_flags, spinlock_t *lock)
+{
+ struct mmp_clk_gate *gate;
+ struct clk *clk;
+ struct clk_init_data init;
+
+ /* allocate the gate */
+ gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+ if (!gate) {
+ pr_err("%s:%s could not allocate gate clk\n", __func__, name);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ init.name = name;
+ init.ops = _clk_gate_ops;
+ init.flags = flags | CLK_IS_BASIC;
+ init.parent_names = (parent_name ? _name : NULL);
+ init.num_parents = (parent_name ? 1 : 0);
+
+ /* struct clk_gate assignments */
+ gate->reg = reg;
+ gate->mask = mask;
+ gate->val_enable = val_enable;
+ gate->val_disable = val_disable;
+ gate->flags = gate_flags;
+ gate->lock = lock;
+ gate->hw.init =
+
+ clk = clk_register(dev, >hw);
+
+ if (IS_ERR(clk))
+ kfree(gate);
+
+ return clk;
+}
diff --git
[PATCH 04/12] clk: mmp: move definiton of mmp_clk_frac to clk.h
From: Chao Xie
Move the definition of structure of mmp_clk_frac to
clk.h.
So device tree support can use this structure.
Signed-off-by: Chao Xie
---
drivers/clk/mmp/clk-frac.c | 8
drivers/clk/mmp/clk.h | 32 ++--
2 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index 1876d2c..eeba52c 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -23,14 +23,6 @@
*/
#define to_clk_factor(hw) container_of(hw, struct mmp_clk_factor, hw)
-struct mmp_clk_factor {
- struct clk_hw hw;
- void __iomem*base;
- struct mmp_clk_factor_masks *masks;
- struct mmp_clk_factor_tbl *ftbl;
- unsigned intftbl_cnt;
- spinlock_t *lock;
-};
static long clk_factor_round_rate(struct clk_hw *hw, unsigned long drate,
unsigned long *prate)
diff --git a/drivers/clk/mmp/clk.h b/drivers/clk/mmp/clk.h
index b71b717..d267639 100644
--- a/drivers/clk/mmp/clk.h
+++ b/drivers/clk/mmp/clk.h
@@ -7,12 +7,14 @@
#define APBC_NO_BUS_CTRL BIT(0)
#define APBC_POWER_CTRLBIT(1)
+
+/* Clock type "factor" */
struct mmp_clk_factor_masks {
- unsigned intfactor;
- unsigned intnum_mask;
- unsigned intden_mask;
- unsigned intnum_shift;
- unsigned intden_shift;
+ unsigned int factor;
+ unsigned int num_mask;
+ unsigned int den_mask;
+ unsigned int num_shift;
+ unsigned int den_shift;
};
struct mmp_clk_factor_tbl {
@@ -20,6 +22,21 @@ struct mmp_clk_factor_tbl {
unsigned int den;
};
+struct mmp_clk_factor {
+ struct clk_hw hw;
+ void __iomem *base;
+ struct mmp_clk_factor_masks *masks;
+ struct mmp_clk_factor_tbl *ftbl;
+ unsigned int ftbl_cnt;
+ spinlock_t *lock;
+};
+
+extern struct clk *mmp_clk_register_factor(const char *name,
+ const char *parent_name, unsigned long flags,
+ void __iomem *base, struct mmp_clk_factor_masks *masks,
+ struct mmp_clk_factor_tbl *ftbl, unsigned int ftbl_cnt,
+ spinlock_t *lock);
+
extern struct clk *mmp_clk_register_pll2(const char *name,
const char *parent_name, unsigned long flags);
extern struct clk *mmp_clk_register_apbc(const char *name,
@@ -28,9 +45,4 @@ extern struct clk *mmp_clk_register_apbc(const char *name,
extern struct clk *mmp_clk_register_apmu(const char *name,
const char *parent_name, void __iomem *base, u32 enable_mask,
spinlock_t *lock);
-extern struct clk *mmp_clk_register_factor(const char *name,
- const char *parent_name, unsigned long flags,
- void __iomem *base, struct mmp_clk_factor_masks *masks,
- struct mmp_clk_factor_tbl *ftbl, unsigned int ftbl_cnt,
- spinlock_t *lock);
#endif
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] dt-bindings: regulator: Add regulator suspend state for PM state
Hi Mark,
On 06/10/2014 04:16 AM, Mark Brown wrote:
> On Mon, Jun 09, 2014 at 07:29:40PM +0900, Chanwoo Choi wrote:
>
>> +- regulator-initial-state: initial state for suspend state
>> +- regulator-state-[standby/mem/disk] sub-root node for suspend state
>> +regulator-volt: voltage consumers may set in suspend state
>> +regulator-mode: voltage mode in suspend state
>> +regulator-on-in-suspend: regulator should be on in suspend state
>> +regulator-off-in-suspend: regulator should be off in suspend state
>
> These need to define what the states are in general terms - in
> particular it's very unclear what standby is and how it differs from
> suspend to RAM. You also need to define what happens if neither
> X-in-suspend property is set.
OK, I'll add more description.
>
>> +regulator-state-mem {
>> +regulator-volt = <100>;
>> +regulator-mode = <0x8>;
>> +regulator-off-in-suspend;
>> +};
>
> Probably best to remove mode from this.
>
OK, I'll remove it. (regulator-mode)
I modify description as following. Please review this description.
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -19,6 +19,24 @@ Optional properties:
design requires. This property describes the total system ramp time
required due to the combination of internal ramping of the regulator itself,
and board design issues such as trace capacitance and load on the supply.
+- regulator-initial-state: initial state for suspend state
+- regulator-state-standby sub-root node for Standby mode
+ : the device is in a power-saving state, but can also receive certain events,
+ specific behavior depends on the specific device.
+- regulator-state-mem sub-root node for Suspend-to-RAM mode
+ : suspend to memory, the device goes to sleep, but all data stored in memory,
+ only some external interrupt can wake the device.
+- regulator-state-disk sub-root node for Suspend-to-disk mode
+ : suspend to disk, this state operates similarly to Suspend-to-RAM,
+ but includes a final step of writing memory contents to disk.
+- regulator-state-[standby/mem/disk] node has following common properties:
+ - regulator-volt: voltage consumers may set in suspend state.
+ - regulator-mode: voltage mode in suspend state.
+ - regulator-on-in-suspend: regulator should be on in suspend state.
+ - regulator-off-in-suspend: regulator should be off in suspend state.
+ If node don't include regulator-[on/off]-in-suspend, can't change
+ regulator state in suspend mode and only should sustain the regulator
+ state of normal state.
Deprecated properties:
- regulator-compatible: If a regulator chip contains multiple
@@ -34,6 +52,11 @@ Example:
regulator-max-microvolt = <250>;
regulator-always-on;
vin-supply = <>;
+
+ regulator-state-mem {
+ regulator-volt = <100>;
+ regulator-off-in-suspend;
+ };
};
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/12] clk: mmp: add clock type mix
From: Chao Xie
The clock type mix is a kind of clock combines "div" and "mux".
This kind of clock can not allow to change div first then
mux or change mux first or div.
The reason is
1. Some clock has frequency change bit. Each time want to change
the frequency, there are some operations based on this bit, and
these operations are time-cost.
Seperating div and mux change will make the process longer, and
waste more time.
2. Seperting the div and mux may generate middle clock that the
peripharals do not support. It may make the peripharals hang.
There are three kinds of this type of clock in all SOCes.
1. The clock has bit to trigger the frequency change.
2. Same as #1, but the operations for the bit is different
3. Do not have frequency change bit.
So this type of clock has implemented the callbacks
->determine_rate
->set_rate_and_parent
These callbacks can help to change the div and mux together.
Signed-off-by: Chao Xie
---
drivers/clk/mmp/Makefile | 2 +-
drivers/clk/mmp/clk-mix.c | 419 ++
drivers/clk/mmp/clk.h | 62 +++
3 files changed, 482 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/mmp/clk-mix.c
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 392d780..8bfee860 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -2,7 +2,7 @@
# Makefile for mmp specific clk
#
-obj-y += clk-apbc.o clk-apmu.o clk-frac.o
+obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o
obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
diff --git a/drivers/clk/mmp/clk-mix.c b/drivers/clk/mmp/clk-mix.c
new file mode 100644
index 000..d2f6406
--- /dev/null
+++ b/drivers/clk/mmp/clk-mix.c
@@ -0,0 +1,419 @@
+/*
+ * mmp mix(div and mux) clock operation source file
+ *
+ * Copyright (C) 2014 Marvell
+ * Chao Xie
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+/*
+ * The mix clock is a clock combined mux and div type clock.
+ * Because the div field and mux field need to be set at same
+ * time, we can not divide it into 2 types of clock
+ */
+
+#define to_clk_mix(hw) container_of(hw, struct mmp_clk_mix, hw)
+
+static unsigned int _get_div(struct mmp_clk_mix *mix, unsigned int val)
+{
+ if (mix->div_flags & CLK_DIVIDER_ONE_BASED)
+ return val;
+ if (mix->div_flags & CLK_DIVIDER_POWER_OF_TWO)
+ return 1 << val;
+ return val + 1;
+}
+
+static unsigned int _get_val(struct mmp_clk_mix *mix, unsigned int div)
+{
+ if (mix->div_flags & CLK_DIVIDER_ONE_BASED)
+ return div;
+ if (mix->div_flags & CLK_DIVIDER_POWER_OF_TWO)
+ return __ffs(div);
+ return div - 1;
+}
+
+static void _filter_clk_table(struct mmp_clk_mix *mix,
+ struct mmp_clk_mix_clk_table *table,
+ unsigned int table_size)
+{
+ int i;
+ struct mmp_clk_mix_clk_table *item;
+ struct clk *parent, *clk;
+ unsigned long parent_rate;
+
+ clk = mix->hw.clk;
+
+ for (i = 0; i < table_size; i++) {
+ item = [i];
+ parent = clk_get_parent_by_index(clk, item->parent_index);
+ parent_rate = __clk_get_rate(parent);
+ if (parent_rate % item->rate) {
+ item->valid = 0;
+ } else {
+ item->divisor = parent_rate / item->rate;
+ item->valid = 1;
+ }
+ }
+}
+
+static int _set_rate(struct mmp_clk_mix *mix, u32 mux_val, u32 div_val,
+ unsigned int change_mux, unsigned int change_div)
+{
+ struct mmp_clk_mix_reg_info *ri = >reg_info;
+ u8 width, shift;
+ u32 mux_div, fc_req;
+ int ret, timeout = 50;
+ unsigned long flags = 0;
+
+ if (!change_mux && !change_div)
+ return -EINVAL;
+
+ if (mix->lock)
+ spin_lock_irqsave(mix->lock, flags);
+
+ if (mix->type == MMP_CLK_MIX_TYPE_V1
+ || mix->type == MMP_CLK_MIX_TYPE_V2)
+ mux_div = readl(ri->reg_clk_ctrl);
+ else
+ mux_div = readl(ri->reg_clk_sel);
+
+ if (change_div) {
+ width = ri->width_div;
+ shift = ri->shift_div;
+ mux_div &= ~MMP_CLK_BITS_MASK(width, shift);
+ mux_div |= MMP_CLK_BITS_SET_VAL(div_val, width, shift);
+ }
+
+ if (change_mux) {
+ width = ri->width_mux;
+ shift = ri->shift_mux;
+ mux_div &= ~MMP_CLK_BITS_MASK(width, shift);
+ mux_div |= MMP_CLK_BITS_SET_VAL(mux_val, width, shift);
+ }
+
+ if (mix->type == MMP_CLK_MIX_TYPE_V1) {
+
[PATCH 08/12] clk: mmp: add clock type master
From: Chao Xie
To support device tree for clock, we need pass the register
base and range to the clock.
There are many clock share same range of registers.
For example, clk1 has register as 0xd4210010 while clk2
has 0xd42100c0. If we map the register seperately. There
will waste some space. If there are many clocks like that,
the waste will be huge.
clock type "master node" will map the register for all clocks
that listed as its child in DT file. Each clock will invoke
the APIs provided by "master node" to get its register base.
The following is a exmaple of master clock usage in DT file
apmu_clocks {
compatible = "marvell,mmp-clk-master";
reg = <0xd421 0x1000>;
ck1 {
marvell,reg-offset = <0 0x10>;
};
clk2 {
marvell,reg-offset = <0 0xc0>;
};
}
Signed-off-by: Chao Xie
---
.../devicetree/bindings/clock/mmp/clk-master | 47 +
drivers/clk/mmp/Makefile | 4 +
drivers/clk/mmp/clk-master-node.c | 195 +
drivers/clk/mmp/clk.h | 7 +
4 files changed, 253 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/mmp/clk-master
create mode 100644 drivers/clk/mmp/clk-master-node.c
diff --git a/Documentation/devicetree/bindings/clock/mmp/clk-master
b/Documentation/devicetree/bindings/clock/mmp/clk-master
new file mode 100644
index 000..b6acde1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp/clk-master
@@ -0,0 +1,47 @@
+Binding for Marvell MMP series master clock.
+
+The MMP related device tree support for clock based on the clock type not clock
+controller. So specific SOC, user need define the DT file for the clock such as
+pxa910-clock.dtsi.
+
+Almost all types of clock will need parameter as "register", and it will map
the
+"register" before access it. If every clock map the "register" seperately,
there
+will be a lot of waste.
+
+A master clock is defined for this kind of situation. It will be responsible
for
+map the registers for all clocks that lists as its children in DT file.
+
+Required properties
+- compatible : It should be "marvell,mmp-clk-master".
+
+
+Optional properties:
+- reg : The register start and range the master clock covered.
+
+Optional properties for child node:
+- marvell,reg-offset : It is a two-values item - .
+ Master node will map the registers for all its children. So
+ for the child it need to pass the information about register
+ index and offset. "register_index" indicates which register
space
+ it from because master clock can have mutiple register
space in
+ "reg". "register_offset" indicates the offset in the
register
+ space.
+
+Examples
+There are two clocks, clk1 has register at 0xd4210010, and clk2 has register at
+0xd42100c0.
+
+apmu_clk {
+ compatible = "marvell,mmp-clk-master";
+ reg = <0xd421 0x1000>;
+
+ clk1 {
+ ...
+ marvell,reg-offset = <0 0x10>;
+ };
+
+ clk2 {
+ ...
+ marvell,reg-offset = <0 0xc0>;
+ };
+};
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 2cd7d94..518931e 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -5,6 +5,10 @@
obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o clk-gate.o \
clk-mix-composite.o
+ifneq ($(CONFIG_OF),)
+obj-y += clk-master-node.o
+endif
+
obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
obj-$(CONFIG_CPU_MMP2) += clk-mmp2.o
diff --git a/drivers/clk/mmp/clk-master-node.c
b/drivers/clk/mmp/clk-master-node.c
new file mode 100644
index 000..584f72f
--- /dev/null
+++ b/drivers/clk/mmp/clk-master-node.c
@@ -0,0 +1,195 @@
+/*
+ * mmp master clock source file
+ *
+ * Copyright (C) 2014 Marvell
+ * Chao Xie
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+#define MAX_REG8
+
+struct mmp_clk_master_node {
+ unsigned int reg_base[MAX_REG];
+ void __iomem *reg[MAX_REG];
+ struct device_node *np;
+ struct list_head node;
+};
+
+static LIST_HEAD(master_list);
+static DEFINE_MUTEX(master_mutex);
+
+static void mmp_clk_master_setup(struct device_node *np)
+{
+ struct mmp_clk_master_node *node;
+ struct resource res;
+ int i, ret;
+
+ node = kzalloc(sizeof(*node), GFP_KERNEL);
+ if (!node) {
+ pr_err("%s:%s failed to allocate master node.\n",
+ __func__, np->name);
+ return;
+ }
+
+ for (i = 0; i < MAX_REG; i++) {
+
[PATCH 10/12] clk: mmp: add device tree support for composite type clock
From: Chao Xie
To parse composite clock from device tree file, there are some
rules.
The clock to be composited will be the child of the composite
clock in device tree file.
It can support the composition of (mux,div,gate) clock defined
as common clock and (mix,gate) defined only for MMP series.
Signed-off-by: Chao Xie
Conflicts:
drivers/clk/mmp/Makefile
---
.../devicetree/bindings/clock/mmp/clk-composite| 58 +
drivers/clk/mmp/Makefile | 2 +-
drivers/clk/mmp/clk-of-composite.c | 253 +
drivers/clk/mmp/clk.h | 14 ++
4 files changed, 326 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/clock/mmp/clk-composite
create mode 100644 drivers/clk/mmp/clk-of-composite.c
diff --git a/Documentation/devicetree/bindings/clock/mmp/clk-composite
b/Documentation/devicetree/bindings/clock/mmp/clk-composite
new file mode 100644
index 000..224968c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp/clk-composite
@@ -0,0 +1,58 @@
+Binding for Marvell MMP series composite clock
+
+The common clock defines a general composite clock with div/mux/gate.
+Because MMP series has clock need combines the div/mux together, so
+there is a new type of clock "mix". The "mix" clock can also be
+composited with gate clock. In fact, many mix clocks and gate clocks
+share same registers.
+
+In the device tree file, the clock to be composited should be child
+of the composite clock.
+
+Required properties
+- compatible : It should be "marvell,mmp-clk-composite" for (mix, gate)
+ composition, or "marvell,mmp-clk-general-composite" for
+ (mux, div, gate) composition.
+
+
+Examples
+1. There are three clocks mux1, div1, gate1.
+
+apmu_clk {
+ compatible = "marvell,mmp-clk-master";
+ reg = <0xde21 0x1000>;
+
+ general_composite_clk {
+ compatible = "marvell,mmp-clk-general-composite";
+
+ mux1 {
+ ...
+ };
+ div1 {
+ ...
+ };
+ gate1 {
+ ...
+ };
+ };
+};
+
+2. There are two clocks mix1, gate2
+
+apmu_clk {
+ compatible = "marvell,mmp-clk-master";
+ reg = <0xde21 0x1000>;
+
+ composite_clk {
+ compatible = "marvell,mmp-clk-composite";
+
+ mix1 {
+ ...
+ };
+ gate2 {
+ ...
+ };
+ };
+};
+
+
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index e8810b6..84dce78 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -6,7 +6,7 @@ obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o clk-gate.o
\
clk-mix-composite.o
ifneq ($(CONFIG_OF),)
-obj-y += clk-master-node.o lock.o
+obj-y += clk-master-node.o lock.o clk-of-composite.o
endif
obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
diff --git a/drivers/clk/mmp/clk-of-composite.c
b/drivers/clk/mmp/clk-of-composite.c
new file mode 100644
index 000..403ebe2
--- /dev/null
+++ b/drivers/clk/mmp/clk-of-composite.c
@@ -0,0 +1,253 @@
+/*
+ * mmp mix(div and mux) clock operation source file
+ *
+ * Copyright (C) 2014 Marvell
+ * Chao Xie
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+struct mmp_clk_composite_member {
+ struct device_node *np;
+ struct clk_hw *hw;
+ const struct clk_ops *ops;
+ int num_parents;
+ const char **parent_names;
+};
+
+struct mmp_clk_composite_node {
+ struct device_node *np;
+ struct mmp_clk_composite_member *members[MMP_CLK_COMPOSITE_TYPE_MAX];
+ struct list_head node;
+};
+
+static LIST_HEAD(composite_list);
+static DEFINE_MUTEX(composite_mutex);
+
+int of_mmp_clk_composite_add_member(struct device_node *np, struct clk_hw *hw,
+ const struct clk_ops *ops, int type)
+{
+ struct device_node *parent_np;
+ struct mmp_clk_composite_node *node;
+ struct mmp_clk_composite_member *member;
+ unsigned int found = 0;
+ size_t size;
+ int i, ret;
+
+ mutex_lock(_mutex);
+
+ parent_np = of_get_next_parent(np);
+
+ list_for_each_entry(node, _list, node) {
+ if (node->np == parent_np) {
+ found = 1;
+ break;
+ }
+ }
+
+ if (!found) {
+ pr_err("%s:%s can not find member %s\n",
+ __func__, parent_np->name, np->name);
+ ret = -ENOENT;
+ goto out;
+ }
+
+ if (node->members[type]) {
+
[PATCH 03/12] clk: mmp: add init callback for clk-frac
From: Chao Xie
For the clk-frac, if it has table, we need to make
sure that the initial clock rate is one item of the
table.
If it is not, we use the first item in the table by default.
Signed-off-by: Chao Xie
---
drivers/clk/mmp/clk-frac.c | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index e29d006..1876d2c 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -118,10 +118,50 @@ static int clk_factor_set_rate(struct clk_hw *hw,
unsigned long drate,
return 0;
}
+void clk_factor_init(struct clk_hw *hw)
+{
+ struct mmp_clk_factor *factor = to_clk_factor(hw);
+ struct mmp_clk_factor_masks *masks = factor->masks;
+ u32 val, num, den;
+ int i;
+ unsigned long flags = 0;
+
+ if (factor->lock)
+ spin_lock_irqsave(factor->lock, flags);
+
+ val = readl(factor->base);
+
+ /* calculate numerator */
+ num = (val >> masks->num_shift) & masks->num_mask;
+
+ /* calculate denominator */
+ den = (val >> masks->den_shift) & masks->den_mask;
+
+ for (i = 0; i < factor->ftbl_cnt; i++)
+ if (den == factor->ftbl[i].den && num == factor->ftbl[i].num)
+ break;
+
+ if (i >= factor->ftbl_cnt) {
+ val &= ~(masks->num_mask << masks->num_shift);
+ val |= (factor->ftbl[0].num & masks->num_mask) <<
+ masks->num_shift;
+
+ val &= ~(masks->den_mask << masks->den_shift);
+ val |= (factor->ftbl[0].den & masks->den_mask) <<
+ masks->den_shift;
+
+ writel(val, factor->base);
+ }
+
+ if (factor->lock)
+ spin_unlock_irqrestore(factor->lock, flags);
+}
+
static struct clk_ops clk_factor_ops = {
.recalc_rate = clk_factor_recalc_rate,
.round_rate = clk_factor_round_rate,
.set_rate = clk_factor_set_rate,
+ .init = clk_factor_init,
};
struct clk *mmp_clk_register_factor(const char *name, const char *parent_name,
--
1.8.3.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 09/12] clk: mmp: add spin lock automatic detection from device tree
From: Chao Xie
For Marvell MMP series SOC, many clocks share same register.
In the operations of these clock, a spin lock is needed to avoid
confilicts.
When parse the clock from the device tree and register the clock,
we do not know whether it share the register with others.
So a common API is provided to get the spin lock for the clock based
on device tree support.
The general idea is record the node (clock device node, regsiter),
and before register a new clock, search the node list based on
register. If a node is found, return the shared spin lock, or create
a new.
Signed-off-by: Chao Xie
Conflicts:
drivers/clk/mmp/Makefile
---
Documentation/devicetree/bindings/clock/mmp/lock | 44 +++
drivers/clk/mmp/Makefile | 2 +-
drivers/clk/mmp/clk.h| 5 +
drivers/clk/mmp/lock.c | 159 +++
4 files changed, 209 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/clock/mmp/lock
create mode 100644 drivers/clk/mmp/lock.c
diff --git a/Documentation/devicetree/bindings/clock/mmp/lock
b/Documentation/devicetree/bindings/clock/mmp/lock
new file mode 100644
index 000..7e7b5bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp/lock
@@ -0,0 +1,44 @@
+Binding of spin lock support for Marvell MMP series clock
+
+Because some clocks share same register, spinlock need to be used to avoid
+conflicts.
+
+The spin lock sharing detection is based on regsiter address, and it is
+automatically. To support some clocks, the spin lock is not based on
+register address, some properies are provided.
+The properites are used as part of clock's properties in clock device tree
+files.
+
+Optional properties:
+marvell,mmp-clk-spinlock-new : Skip the automatic detection based on
+ register address. Direclty create a new
+ spin lock.
+marvell,mmp-clk-spinlock : It is handle. It points to the clock that share
+ same spin lock.
+
+Examples:
+
+Assume that clk1, clk2, clk3 share same spin lock.
+
+apmu_clk {
+ compatible = "marvell,mmp-clk-master";
+ ...
+
+ clk1 {
+ ...
+ marvell,mmp-clk-spinlock-new;
+ ...
+ };
+
+ clk2 {
+ ...
+ mmp-clk-spinlock = <>;
+ ...
+ };
+
+ clk3 {
+ ...
+ mmp-clk-spinlock = <>;
+ ...
+ };
+};
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 518931e..e8810b6 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -6,7 +6,7 @@ obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o clk-gate.o
\
clk-mix-composite.o
ifneq ($(CONFIG_OF),)
-obj-y += clk-master-node.o
+obj-y += clk-master-node.o lock.o
endif
obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
diff --git a/drivers/clk/mmp/clk.h b/drivers/clk/mmp/clk.h
index 6d8c3b3..e06a228 100644
--- a/drivers/clk/mmp/clk.h
+++ b/drivers/clk/mmp/clk.h
@@ -147,6 +147,11 @@ extern void __iomem *of_mmp_clk_get_reg(struct device_node
*np,
struct device_node *of_mmp_clk_master_init(struct device_node *from);
+/* spin lock sharing support. */
+extern spinlock_t *of_mmp_clk_get_spinlock(struct device_node *np,
+ unsigned int reg_base);
+
+
extern struct clk *mmp_clk_register_pll2(const char *name,
const char *parent_name, unsigned long flags);
extern struct clk *mmp_clk_register_apbc(const char *name,
diff --git a/drivers/clk/mmp/lock.c b/drivers/clk/mmp/lock.c
new file mode 100644
index 000..e2e246c
--- /dev/null
+++ b/drivers/clk/mmp/lock.c
@@ -0,0 +1,159 @@
+/*
+ * mmp mix(div and mux) clock operation source file
+ *
+ * Copyright (C) 2014 Marvell
+ * Chao Xie
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct mmp_clk_spinlock_node {
+ struct device_node *share;
+ struct list_head node;
+};
+
+struct mmp_clk_spinlock {
+ spinlock_t lock;
+ struct device_node *owner;
+ unsigned int reg_base;
+ struct list_head share_list;
+ struct list_head node;
+};
+
+static LIST_HEAD(lock_list);
+
+static DEFINE_MUTEX(lock_mutex);
+
+static struct mmp_clk_spinlock_node *create_lock_node(struct device_node *np)
+{
+ struct mmp_clk_spinlock_node *node;
+
+ node = kzalloc(sizeof(*node), GFP_KERNEL);
+ if (!node) {
+ pr_err("%s:%s failed to allocate spinlock node.\n",
+ __func__, np->name);
+ return NULL;
+ }
+
+ node->share = np;
+
+ return node;
+}
+
+static struct mmp_clk_spinlock *create_lock(struct device_node *np,
[PATCH 11/12] clk: mmp: add device tree support for clocks.
From: Chao Xie
For MMP series SOC, it will use some types of clock.
Add the device tree support for these kind of clocks.
It includes mux/div/mix/gate/factor clock.
Signed-off-by: Chao Xie
Conflicts:
drivers/clk/mmp/Makefile
---
.../devicetree/bindings/clock/mmp/clk-div | 28 +
.../devicetree/bindings/clock/mmp/clk-factor | 28 +
.../devicetree/bindings/clock/mmp/clk-gate | 41 ++
.../devicetree/bindings/clock/mmp/clk-mix | 38 ++
.../devicetree/bindings/clock/mmp/clk-mux | 20 +
drivers/clk/mmp/Makefile | 2 +-
drivers/clk/mmp/clk-of.c | 689 +
7 files changed, 845 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/clock/mmp/clk-div
create mode 100644 Documentation/devicetree/bindings/clock/mmp/clk-factor
create mode 100644 Documentation/devicetree/bindings/clock/mmp/clk-gate
create mode 100644 Documentation/devicetree/bindings/clock/mmp/clk-mix
create mode 100644 Documentation/devicetree/bindings/clock/mmp/clk-mux
create mode 100644 drivers/clk/mmp/clk-of.c
diff --git a/Documentation/devicetree/bindings/clock/mmp/clk-div
b/Documentation/devicetree/bindings/clock/mmp/clk-div
new file mode 100644
index 000..62eb7d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp/clk-div
@@ -0,0 +1,28 @@
+Binding for div type clock
+
+The div clock is defined as common clock.
+
+
+Required properties
+- compatible : It should be "marvell,mmp-clk-div".
+- clocks : The parents of the clock.
+- marvell,mmp-clk-bits-div : The width and shift of divider bits.
+
+Optional properties:
+- marvell,mmp-clk-div-power-of-two : The value of divider is a power of two.
+- marvell,mmp-clk-div-one-based : The value of divider starts from 1.
+- marvell,mmp-clk-div-table : The value of divider is not continous, and need
+ a table to record it.
+
+
+Examples
+apmu_clk {
+ compatible = "marvell,mmp-clk-master";
+ reg = <0xd4282800 0x1000>;
+ dsi_phy_slow_div: dsi_phy_slow_div {
+ compatible = "marvell,mmp-clk-div";
+ marvell,reg-offset = <0 0x44>;
+ clocks = <>;
+ marvell,mmp-clk-bits-div = <5 6>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/clock/mmp/clk-factor
b/Documentation/devicetree/bindings/clock/mmp/clk-factor
new file mode 100644
index 000..9e1816c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp/clk-factor
@@ -0,0 +1,28 @@
+Binding for Marvell MMP series factor clock
+
+The factor clock is calculated by
+ Fout = (Fin * (den / num)) / factor;
+
+Required properties
+- compatible : It should be "marvell,mmp-clk-factor";
+- clock: The parent of the clock.
+- marvell,mmp-clk-factor-factor : The "factor" of the clock.
+- marvell,mmp-clk-factor-bits-num : The width and shift of bits for "num".
+- marvell,mmp-clk-factor-bits-den : The width and shift of bits for "dev".
+- marvell,mmp-clk-factor-table : The table of (num, den) for the clock.
+
+Examples
+mpmu_clocks: mpmu_clocks {
+ compatible = "marvell,mmp-clk-master";
+ reg = <0xd405 0x1000>;
+ uart_pll: uart_pll {
+ compatible = "marvell,mmp-clk-factor";
+ clocks = <_4>;
+ marvell,reg-offset = <0 0x14>;
+ marvell,mmp-clk-factor-factor = <2>;
+ marvell,mmp-clk-factor-bits-den = <13 0>;
+ marvell,mmp-clk-factor-bits-num = <13 16>;
+ marvell,mmp-clk-factor-table = <8125 1536>;
+ };
+};
++
diff --git a/Documentation/devicetree/bindings/clock/mmp/clk-gate
b/Documentation/devicetree/bindings/clock/mmp/clk-gate
new file mode 100644
index 000..5da6c63
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mmp/clk-gate
@@ -0,0 +1,41 @@
+Binding for Marvell MMP series gate clock and common gate clock
+
+There two type of gate clock used by Marvell MMP series SOC.
+The common gate clock and the gate clock defined for MMP series SOC.
+
+For common gate clock
+
+Required properties
+- compatible : It should be "marvell,mmp-clk-general-gate";
+- clock : The parent of the clock.
+- marvell,mmp-clk-bit-gate : The offset of the bit control the gate.
+
+Examples
+apmu_clocks: apmu_clocks {
+ compatible = "marvell,mmp-clk-master";
+ reg = <0xd4282800 0x1000>;
+ pll1_416_gate: pll1_416_gate {
+ compatible = "marvell,mmp-clk-general-gate";
+ clocks = <_416m>;
+ marvell,reg-offset = <0 0x40>;
+ marvell,mmp-clk-bit-gate = <27>;
+ };
+};
+
+For MMP series gate clock
+
+Required properties
+- compatible : It should be "marvell,mmp-clk-gate";
+- clock : The parent of the clock.
+- marvell,mmp-clk-mask : The (mask, val_enable, val_disable) for the clock.
+
+Examples
+apmu_clocks: apmu_clocks {
+ compatible = "marvell,mmp-clk-master";
+ reg = <0xd4282800 0x1000>;
[PATCH 07/12] clk: mmp: add clock type composite for mix
From: Chao Xie
The general composite clock supports div/mux/gate.
marvell SOCes have many clocks that need change
div and mux together. So it need the composite
clock that supports mix/gate.
Signed-off-by: Chao Xie
---
drivers/clk/mmp/Makefile| 3 +-
drivers/clk/mmp/clk-mix-composite.c | 195
drivers/clk/mmp/clk.h | 20
3 files changed, 217 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/mmp/clk-mix-composite.c
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 2855f7b..2cd7d94 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -2,7 +2,8 @@
# Makefile for mmp specific clk
#
-obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o clk-gate.o
+obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o clk-gate.o \
+clk-mix-composite.o
obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
diff --git a/drivers/clk/mmp/clk-mix-composite.c
b/drivers/clk/mmp/clk-mix-composite.c
new file mode 100644
index 000..79d5286
--- /dev/null
+++ b/drivers/clk/mmp/clk-mix-composite.c
@@ -0,0 +1,195 @@
+/*
+ * mmp mix(div and mux) clock operation source file
+ *
+ * Copyright (C) 2014 Marvell
+ * Chao Xie
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+#define to_clk_composite(_hw) container_of(_hw, struct mmp_clk_composite, hw)
+
+static u8 mmp_clk_composite_get_parent(struct clk_hw *hw)
+{
+ struct mmp_clk_composite *composite = to_clk_composite(hw);
+ const struct clk_ops *mix_ops = composite->mix_ops;
+ struct clk_hw *mix_hw = composite->mix_hw;
+
+ mix_hw->clk = hw->clk;
+
+ return mix_ops->get_parent(mix_hw);
+}
+
+static int mmp_clk_composite_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct mmp_clk_composite *composite = to_clk_composite(hw);
+ const struct clk_ops *mix_ops = composite->mix_ops;
+ struct clk_hw *mix_hw = composite->mix_hw;
+
+ mix_hw->clk = hw->clk;
+
+ return mix_ops->set_parent(mix_hw, index);
+}
+
+static int mmp_clk_composite_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct mmp_clk_composite *composite = to_clk_composite(hw);
+ const struct clk_ops *mix_ops = composite->mix_ops;
+ struct clk_hw *mix_hw = composite->mix_hw;
+
+ mix_hw->clk = hw->clk;
+
+ return mix_ops->set_rate(mix_hw, rate, parent_rate);
+}
+
+static unsigned long mmp_clk_composite_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct mmp_clk_composite *composite = to_clk_composite(hw);
+ const struct clk_ops *mix_ops = composite->mix_ops;
+ struct clk_hw *mix_hw = composite->mix_hw;
+
+ mix_hw->clk = hw->clk;
+
+ return mix_ops->recalc_rate(mix_hw, parent_rate);
+}
+
+static long mmp_clk_composite_determine_rate(struct clk_hw *hw,
+ unsigned long rate,
+ unsigned long *best_parent_rate,
+ struct clk **best_parent_p)
+{
+ struct mmp_clk_composite *composite = to_clk_composite(hw);
+ const struct clk_ops *mix_ops = composite->mix_ops;
+ struct clk_hw *mix_hw = composite->mix_hw;
+
+ mix_hw->clk = hw->clk;
+
+ return mix_ops->determine_rate(mix_hw, rate, best_parent_rate,
+ best_parent_p);
+}
+
+static int mmp_clk_composite_set_rate_and_parent(struct clk_hw *hw,
+ unsigned long rate,
+ unsigned long parent_rate, u8 index)
+
+{
+ struct mmp_clk_composite *composite = to_clk_composite(hw);
+ const struct clk_ops *mix_ops = composite->mix_ops;
+ struct clk_hw *mix_hw = composite->mix_hw;
+
+ mix_hw->clk = hw->clk;
+
+ return mix_ops->set_rate_and_parent(mix_hw, rate, parent_rate, index);
+}
+
+static int mmp_clk_composite_is_enabled(struct clk_hw *hw)
+{
+ struct mmp_clk_composite *composite = to_clk_composite(hw);
+ const struct clk_ops *gate_ops = composite->gate_ops;
+ struct clk_hw *gate_hw = composite->gate_hw;
+
+ gate_hw->clk = hw->clk;
+
+ return gate_ops->is_enabled(gate_hw);
+}
+
+static int mmp_clk_composite_enable(struct clk_hw *hw)
+{
+ struct mmp_clk_composite *composite = to_clk_composite(hw);
+ const struct clk_ops *gate_ops = composite->gate_ops;
+ struct clk_hw *gate_hw = composite->gate_hw;
+
+ gate_hw->clk = hw->clk;
+
+ return gate_ops->enable(gate_hw);
+}
+
+static void mmp_clk_composite_disable(struct clk_hw *hw)
+{
+ struct
[PATCH 12/12] arm: mmp: support clock device tree for mmp platforms
From: Chao Xie
The platforms including pxa168/pxa910/mmp2.
After add clock device tree support. There is no need
to maintain mmp2-dt.c because it is same as mmp-dt.c now.
The file will be removed.
Compiling test for pxa168 because of lacking of platform.
The platform is too old.
Functonality test for pxa910 and mmp2.
Signed-off-by: Chao Xie
---
arch/arm/boot/dts/mmp2-clock.dtsi | 575
arch/arm/boot/dts/mmp2.dtsi | 11 +
arch/arm/boot/dts/pxa168-clock.dtsi | 443 +++
arch/arm/boot/dts/pxa168.dtsi | 10 +
arch/arm/boot/dts/pxa910-clock.dtsi | 388
arch/arm/boot/dts/pxa910.dtsi | 10 +
arch/arm/mach-mmp/Kconfig | 7 +-
arch/arm/mach-mmp/Makefile | 2 +-
arch/arm/mach-mmp/common.h | 1 +
arch/arm/mach-mmp/mmp-dt.c | 57 ++--
arch/arm/mach-mmp/mmp2-dt.c | 50
11 files changed, 1462 insertions(+), 92 deletions(-)
create mode 100644 arch/arm/boot/dts/mmp2-clock.dtsi
create mode 100644 arch/arm/boot/dts/pxa168-clock.dtsi
create mode 100644 arch/arm/boot/dts/pxa910-clock.dtsi
delete mode 100644 arch/arm/mach-mmp/mmp2-dt.c
diff --git a/arch/arm/boot/dts/mmp2-clock.dtsi
b/arch/arm/boot/dts/mmp2-clock.dtsi
new file mode 100644
index 000..89f2279
--- /dev/null
+++ b/arch/arm/boot/dts/mmp2-clock.dtsi
@@ -0,0 +1,575 @@
+_clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ fixed_clocks: fixed_clocks {
+ compatible = "marvell,mmp-clk-master";
+ clk32: clk32 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ };
+ vctcxo: vctcxo {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2600>;
+ };
+ vctcxo_2: vctcxo_2 {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ };
+ vctcxo_4: vctcxo_4 {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <_2>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ };
+ usb_pll: usb_pll {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <48000>;
+ };
+ pll1: pll1 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <62400>;
+ };
+ pll1_2: pll1_2 {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ };
+ pll1_4: pll1_4 {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <_2>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ };
+ pll1_8: pll1_8 {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <_4>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ };
+ pll1_16: pll1_16 {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <_8>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ };
+ pll1_20: pll1_20 {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <_4>;
+ clock-div = <5>;
+ clock-mult = <1>;
+ };
+ pll1_3: pll1_3 {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <>;
+ clock-div = <3>;
+ clock-mult = <1>;
+ };
+ pll1_6: pll1_6 {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <_3>;
+ clock-div = <3>;
+ clock-mult = <1>;
+ };
+ pll1_12: pll1_12 {
+ #clock-cells = <0>;
+
linux-next: manual merge of the vfs tree with the f2fs tree
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in
fs/f2fs/data.c between commit b6fe5873cb42 ("f2fs: fix to recover data
written by dio") from the f2fs tree and commits d8d3d94b80aa ("pass
iov_iter to ->direct_IO()") and 31b140398ce5 ("switch
{__,}blockdev_direct_IO() to iov_iter") from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/f2fs/data.c
index c1fb6dd10911,1d2e7e9624d2..
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@@ -1044,14 -1018,11 +1043,14 @@@ static ssize_t f2fs_direct_IO(int rw, s
if (f2fs_has_inline_data(inode))
return 0;
- if (check_direct_IO(inode, rw, iov, offset, nr_segs))
+ if (check_direct_IO(inode, rw, iter, offset))
return 0;
+ /* clear fsync mark to recover these blocks */
+ fsync_mark_clear(F2FS_SB(inode->i_sb), inode->i_ino);
+
- return blockdev_direct_IO(rw, iocb, inode, iov, offset, nr_segs,
- get_data_block);
+ return blockdev_direct_IO(rw, iocb, inode, iter, offset,
+ get_data_block);
}
static void f2fs_invalidate_data_page(struct page *page, unsigned int offset,
signature.asc
Description: PGP signature
Re: [PATCH 3.4 47/88] mm: add kmap_to_page()
On Mon, 2014-06-09 at 18:15 -0700, Hugh Dickins wrote:
> On Mon, 9 Jun 2014, Greg Kroah-Hartman wrote:
>
> > 3.4-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Ben Hutchings
> >
> > commit fcb8996728fb59eddf84678df7cb213b2c9a2e26 upstream.
> >
> > This is extracted from Mel Gorman's commit 5a178119b0fb ('mm: add
> > support for direct_IO to highmem pages') upstream.
> >
> > Required to backport commit b9cdc88df8e6 ('virtio: 9p: correctly pass
> > physical address to userspace for high pages').
> >
> > Cc: Mel Gorman
> > Cc: Rik van Riel
> > Cc: Andrew Morton
> > Signed-off-by: Ben Hutchings
> > Cc: Yijing Wang
> > Signed-off-by: Greg Kroah-Hartman
> >
> > ---
> > include/linux/highmem.h |7 +++
> > mm/highmem.c| 12
> > 2 files changed, 19 insertions(+)
> >
> > --- a/include/linux/highmem.h
> > +++ b/include/linux/highmem.h
> > @@ -39,10 +39,17 @@ extern unsigned long totalhigh_pages;
> >
> > void kmap_flush_unused(void);
> >
> > +struct page *kmap_to_page(void *addr);
> > +
> > #else /* CONFIG_HIGHMEM */
> >
> > static inline unsigned int nr_free_highpages(void) { return 0; }
> >
> > +static inline struct page *kmap_to_page(void *addr)
> > +{
> > + return virt_to_page(addr);
> > +}
> > +
> > #define totalhigh_pages 0UL
> >
> > #ifndef ARCH_HAS_KMAP
> > --- a/mm/highmem.c
> > +++ b/mm/highmem.c
> > @@ -94,6 +94,18 @@ static DECLARE_WAIT_QUEUE_HEAD(pkmap_map
> > do { spin_unlock(_lock); (void)(flags); } while (0)
> > #endif
> >
> > +struct page *kmap_to_page(void *vaddr)
> > +{
> > + unsigned long addr = (unsigned long)vaddr;
> > +
> > + if (addr >= PKMAP_ADDR(0) && addr <= PKMAP_ADDR(LAST_PKMAP)) {
> > + int i = (addr - PKMAP_ADDR(0)) >> PAGE_SHIFT;
> > + return pte_page(pkmap_page_table[i]);
> > + }
> > +
> > + return virt_to_page(addr);
> > +}
> > +
> > static void flush_all_zero_pkmaps(void)
> > {
> > int i;
>
> I think this needs the following on top:
>
> commit 498c2280212327858e521e9d21345d4cc2637f54
> Author: Will Deacon
> Date: Fri Nov 16 14:15:00 2012 -0800
>
> mm: highmem: don't treat PKMAP_ADDR(LAST_PKMAP) as a highmem address
[...]
Thanks Hugh, I've queued this up for 3.2 (where I previously added
kmap_to_page()).
Ben.
--
Ben Hutchings
signature.asc
Description: This is a digitally signed message part
Re: drivers/char/random.c: more ruminations
On Mon, Jun 09, 2014 at 08:20:57PM -0400, George Spelvin wrote: > > I have an idea for a patch to change _xfer_secondary_pool > to use extract_buf rather than extract_entropy; is all that > FIPS stuff needed for purely internal transfers? That's not the part of extract_entropy() which is critical. What's critical is the control over only transfering entropy when there is at least a certain minimum amount of entropy. This provides the Yarrow-like avalanche property which is required to provide recovery after the internal state of the entropy pools have been exposed. > Also, shouldn't the r->last_pulled holdoff in xfer_secondary_pool be > really limited to actual transfers? I.e. reorder the conditions as... Yes, that makes sense. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] serial: core: Don't drop DTR if system console
On 06/09/2014 09:08 AM, One Thousand Gnomes wrote: On Wed, 4 Jun 2014 10:16:10 -0400 Peter Hurley wrote: If a tty is opened on a serial console, don't drop DTR on last tty close, on tty hangup, or when resetting port hardware via TIOCSSERIAL and TIOCSERCONFIG ioctls. Signed-off-by: Peter Hurley NAK This introduces a security flaw. If you have a system with a remote console you dial into then with this patch applied a modem drop eg from a bad line will no longer drop any live session and ensure a login is required as it was before. There's no security flaw here. The situation you're referring to above is managed by the CLOCAL termios setting (which by default does _not_ hangup the tty on carrier loss). This patch only affects the line state if the last tty reference is closed or the tty is hung up by software (like on controlling process exit). In this case, any login session is already dying, and it would not be possible to hijack a live session. A successful re-login is still required. That's a pretty bad regression case. If you are running a serial console and want to leave DTR high either wire the cable that way or don't set HUPCL in the first place. The technology for fixing this problem already exists! Notwithstanding what I wrote above, this patch does change behavior with remote consoles, which may be unacceptable. For example, if the remote user logs out, the current behavior hangs up the modem (if HUPCL), whereas the patch behavior just presents a new login prompt. So yeah, I agree; this patch should be dropped. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 7/7] rtmutex: Avoid pointless requeueing in the deadlock detection chain walk
On Mon, 09 Jun 2014 20:28:10 -
Thomas Gleixner wrote:
> In case the dead lock detector is enabled we follow the lock chain to
> the end in rt_mutex_adjust_prio_chain, even if we could stop earlier
> due to the priority/waiter constellation.
>
> But once we are not longer the top priority waiter in a certain step
> or the task holding the lock has already the same priority then there
> is no point in dequeing and enqueing along the lock chain as there is
> no change at all.
>
> So stop the requeueing at this point.
>
> Signed-off-by: Thomas Gleixner
> ---
> kernel/locking/rtmutex.c | 61
> +--
> 1 file changed, 54 insertions(+), 7 deletions(-)
>
> Index: tip/kernel/locking/rtmutex.c
> ===
> --- tip.orig/kernel/locking/rtmutex.c
> +++ tip/kernel/locking/rtmutex.c
> @@ -359,6 +359,7 @@ static int rt_mutex_adjust_prio_chain(st
> struct rt_mutex *lock;
> bool detect_deadlock;
> unsigned long flags;
> + bool requeue = true;
>
> detect_deadlock = rt_mutex_cond_detect_deadlock(orig_waiter, chwalk);
>
> @@ -436,18 +437,31 @@ static int rt_mutex_adjust_prio_chain(st
> goto out_unlock_pi;
> /*
>* If deadlock detection is off, we stop here if we
> - * are not the top pi waiter of the task.
> + * are not the top pi waiter of the task. If deadlock
> + * detection is enabled we continue, but stop the
> + * requeueing in the chain walk.
>*/
> - if (!detect_deadlock && top_waiter != task_top_pi_waiter(task))
> - goto out_unlock_pi;
> + if (top_waiter != task_top_pi_waiter(task)) {
> + if (!detect_deadlock)
> + goto out_unlock_pi;
> + else
> + requeue = false;
> + }
> }
>
> /*
> - * When deadlock detection is off then we check, if further
> - * priority adjustment is necessary.
> + * If the waiter priority is the same as the task priority
> + * then there is no further priority adjustment necessary. If
> + * deadlock detection is off, we stop the chain walk. If its
> + * enabled we continue, but stop the requeueing in the chain
> + * walk.
>*/
> - if (!detect_deadlock && waiter->prio == task->prio)
> - goto out_unlock_pi;
> + if (waiter->prio == task->prio) {
> + if (!detect_deadlock)
> + goto out_unlock_pi;
> + else
> + requeue = false;
> + }
>
> /*
>* We need to trylock here as we are holding task->pi_lock,
> @@ -475,6 +489,39 @@ static int rt_mutex_adjust_prio_chain(st
> }
>
> /*
> + * If we just follow the lock chain for deadlock detection, no
> + * need to do all the requeue operations. We avoid a truckload
s/We/To/
> + * of conditinals around the various places below and just do
s/ and/, /
> + * the minimum chain walk checks here.
> + */
> + if (!requeue) {
> + /* Release the task */
> + raw_spin_unlock_irqrestore(>pi_lock, flags);
> + put_task_struct(task);
> +
> + /* If there is no owner of the lock, end of chain. */
> + if (!rt_mutex_owner(lock)) {
> + raw_spin_unlock(>wait_lock);
> + return 0;
> + }
> +
> + /* Grab the next task, i.e. owner of @lock */
> + task = rt_mutex_owner(lock);
> + get_task_struct(task);
> + raw_spin_lock_irqsave(>pi_lock, flags);
> +
> + /* Store whether owner is blocked itself and drop locks */
> + next_lock = task_blocked_on(task);
> + raw_spin_unlock_irqrestore(>pi_lock, flags);
> + raw_spin_unlock(>wait_lock);
> +
> + /* If owner is not blocked, end of chain. */
> + if (!next_lock)
> + goto out_put_task;
On the loop back around, have something like:
if (top_waiter) {
if (!task_has_pi_waiters(task))
goto out_unlock_pi;
if (!requeue &&
top_waiter != task_top_pi_waiter(task)) {
if (!detect_deadlock)
goto out_unlock_pi;
else
requeue = false;
}
}
??
> + goto again;
> + }
> +
> + /*
>* Store the current top waiter before doing the requeue
>* operation on @lock. We need it for the boost/deboost
>* decision below.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH 3.4 47/88] mm: add kmap_to_page()
On Mon, 9 Jun 2014, Greg Kroah-Hartman wrote:
> 3.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Ben Hutchings
>
> commit fcb8996728fb59eddf84678df7cb213b2c9a2e26 upstream.
>
> This is extracted from Mel Gorman's commit 5a178119b0fb ('mm: add
> support for direct_IO to highmem pages') upstream.
>
> Required to backport commit b9cdc88df8e6 ('virtio: 9p: correctly pass
> physical address to userspace for high pages').
>
> Cc: Mel Gorman
> Cc: Rik van Riel
> Cc: Andrew Morton
> Signed-off-by: Ben Hutchings
> Cc: Yijing Wang
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> include/linux/highmem.h |7 +++
> mm/highmem.c| 12
> 2 files changed, 19 insertions(+)
>
> --- a/include/linux/highmem.h
> +++ b/include/linux/highmem.h
> @@ -39,10 +39,17 @@ extern unsigned long totalhigh_pages;
>
> void kmap_flush_unused(void);
>
> +struct page *kmap_to_page(void *addr);
> +
> #else /* CONFIG_HIGHMEM */
>
> static inline unsigned int nr_free_highpages(void) { return 0; }
>
> +static inline struct page *kmap_to_page(void *addr)
> +{
> + return virt_to_page(addr);
> +}
> +
> #define totalhigh_pages 0UL
>
> #ifndef ARCH_HAS_KMAP
> --- a/mm/highmem.c
> +++ b/mm/highmem.c
> @@ -94,6 +94,18 @@ static DECLARE_WAIT_QUEUE_HEAD(pkmap_map
> do { spin_unlock(_lock); (void)(flags); } while (0)
> #endif
>
> +struct page *kmap_to_page(void *vaddr)
> +{
> + unsigned long addr = (unsigned long)vaddr;
> +
> + if (addr >= PKMAP_ADDR(0) && addr <= PKMAP_ADDR(LAST_PKMAP)) {
> + int i = (addr - PKMAP_ADDR(0)) >> PAGE_SHIFT;
> + return pte_page(pkmap_page_table[i]);
> + }
> +
> + return virt_to_page(addr);
> +}
> +
> static void flush_all_zero_pkmaps(void)
> {
> int i;
I think this needs the following on top:
commit 498c2280212327858e521e9d21345d4cc2637f54
Author: Will Deacon
Date: Fri Nov 16 14:15:00 2012 -0800
mm: highmem: don't treat PKMAP_ADDR(LAST_PKMAP) as a highmem address
kmap_to_page returns the corresponding struct page for a virtual address
of an arbitrary mapping. This works by checking whether the address
falls in the pkmap region and using the pkmap page tables instead of the
linear mapping if appropriate.
Unfortunately, the bounds checking means that PKMAP_ADDR(LAST_PKMAP) is
incorrectly treated as a highmem address and we can end up walking off
the end of pkmap_page_table and subsequently passing junk to pte_page.
This patch fixes the bound check to stay within the pkmap tables.
Signed-off-by: Will Deacon
Cc: Mel Gorman
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
diff --git a/mm/highmem.c b/mm/highmem.c
index d517cd16a6eb..2da13a5c50e2 100644
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -98,7 +98,7 @@ struct page *kmap_to_page(void *vaddr)
{
unsigned long addr = (unsigned long)vaddr;
- if (addr >= PKMAP_ADDR(0) && addr <= PKMAP_ADDR(LAST_PKMAP)) {
+ if (addr >= PKMAP_ADDR(0) && addr < PKMAP_ADDR(LAST_PKMAP)) {
int i = (addr - PKMAP_ADDR(0)) >> PAGE_SHIFT;
return pte_page(pkmap_page_table[i]);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Wed, Jun 04, 2014 at 07:52:56PM -0700, Cameron Norman wrote:
> On Wed, Jun 4, 2014 at 5:31 PM, Luis R. Rodriguez wrote:
> > On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
> >> On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcg...@suse.com) wrote:
> >>
> >> > I'm cc'ing a few security folks as I'd appreciate review on the ideas
> >> > here,
> >> > in particular that of a launcher idea on system to replace alternatives
> >> > on the
> >> > ExecStart= line of a systemd service unit file, alternative ideas are of
> >> > course welcomed. I'm also Cc'ing systemd-devel as this subject was
> >> > reviewed
> >> > a little while ago with nothing concrete being recommended but instead a
> >> > few
> >> > options being now archived as possibilities. I'm looking for a bit wider
> >> > review of the approaches and recomendations.
> >> >
> >> > Some general background for non xen folks: old xen requires the launch of
> >> > a daemon which implements supports of the xenstore, which is the database
> >> > that xen uses for information about guests / dom0. There are two
> >> > supported
> >> > daemons, xenstored (C version) and oxenstored (Ocaml version) but they
> >> > do the
> >> > same thing. Right now old init lets you override which one you pick
> >> > through
> >> > an environment variable on /etc/{sysconfig,default}/xencommons, the
> >> > script
> >> > will use the appropriate on there. Systemd doesn't let you use variables
> >> > on
> >> > the ExecStart line of a service unit file so alternatives are required.
> >> >
> >> > The reason I'm being very careful here this could set a precedent and at
> >> > least for the launcher idea it'd require the usage of getenv() and
> >> > execve(),
> >> > and secure alternatives for these (secure_getenv(), execve_nosecurity())
> >> > have either been merged or suggested before for Linux. The systemd
> >> > discussion
> >> > is only specific to Linux but if we have a launcher we could consider it
> >> > for
> >> > other supported OSes. All that said I'd like proper review of the
> >> > security
> >> > implications of *all* strategies but obviously in particular the launcher
> >> > idea. I want to tread carefuly before setting precedents.
> >>
> >> You can also just invoke a shell script from ExecStart=. I mean, we try
> >> to deemphesize them in the boot process, but there's nothing wrong with
> >> using shell, if you need to parse shell configuraiton fragments and just
> >> want to execute on ot another program...
> >
> > I tried this and it didn't work given that systemd expects sd_notify()
> > to be called from the parent process, in this case the shell script.
>
> Just use exec before the daemon command. I am pretty certain it can be
> just like this:
>
> ExecStart=/bin/sh -c "exec $XENSTORED"
>
> xenstored then has the same PID as the sh process, and $NOTIFY_SOCKET
> works just fine.
Actually this does work on a test unit I just built. I'll proceed with
this approach since I haven't heard back from others and I think
this is the best approach now.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: workqueue: WARN at at kernel/workqueue.c:2176
On 06/09/2014 10:01 PM, Jason J. Herne wrote:
> On 06/05/2014 06:54 AM, Lai Jiangshan wrote:
>>
>>
>> Subject: [PATCH] sched: migrate the waking tasks
>>
>> Current code skips to migrate the waking task silently when TTWU_QUEUE is
>> enabled.
>>
>> When a task is waking, it is pending on the wake_list of the rq, but
>> it is not on queue (task->on_rq == 0). In this case, set_cpus_allowed_ptr()
>> and __migrate_task() will not migrate it due to it is not on queue.
>>
>> This behavior is incorrect, because the task had been already waken-up, it
>> will
>> be running on the wrong CPU without correct placement until the next wake-up
>> or update for cpus_allowed.
>>
>> To fix this problem, we need to make the waking tasks on-queue (transfer
>> the waking tasks to running state) before migrate them.
>>
>> Signed-off-by: Lai Jiangshan
>> ---
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 268a45e..d05a5a1 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -1474,20 +1474,24 @@ static int ttwu_remote(struct task_struct *p, int
>> wake_flags)
>> }
>>
>> #ifdef CONFIG_SMP
>> -static void sched_ttwu_pending(void)
>> +static void sched_ttwu_pending_locked(struct rq *rq)
>> {
>> -struct rq *rq = this_rq();
>> struct llist_node *llist = llist_del_all(>wake_list);
>> struct task_struct *p;
>>
>> -raw_spin_lock(>lock);
>> -
>> while (llist) {
>> p = llist_entry(llist, struct task_struct, wake_entry);
>> llist = llist_next(llist);
>> ttwu_do_activate(rq, p, 0);
>> }
>> +}
>>
>> +static void sched_ttwu_pending(void)
>> +{
>> +struct rq *rq = this_rq();
>> +
>> +raw_spin_lock(>lock);
>> +sched_ttwu_pending_locked(rq);
>> raw_spin_unlock(>lock);
>> }
>>
>> @@ -4530,6 +4534,11 @@ int set_cpus_allowed_ptr(struct task_struct *p, const
>> struct cpumask *new_mask)
>> goto out;
>>
>> dest_cpu = cpumask_any_and(cpu_active_mask, new_mask);
>> +
>> +/* Ensure it is on rq for migration if it is waking */
>> +if (p->state == TASK_WAKING)
>> +sched_ttwu_pending_locked(rq);
>> +
>> if (p->on_rq) {
>> struct migration_arg arg = { p, dest_cpu };
>> /* Need help from migration thread: drop lock and wait. */
>> @@ -4576,6 +4585,10 @@ static int __migrate_task(struct task_struct *p, int
>> src_cpu, int dest_cpu)
>> if (!cpumask_test_cpu(dest_cpu, tsk_cpus_allowed(p)))
>> goto fail;
>>
>> +/* Ensure it is on rq for migration if it is waking */
>> +if (p->state == TASK_WAKING)
>> +sched_ttwu_pending_locked(rq_src);
>> +
>> /*
>>* If we're not on a rq, the next wake-up will ensure we're
>>* placed properly.
>>
>
> FYI, this patch appears to fix the problem. I was able to run for 3 days
> without hitting the warning.
Thank you for the test. It proves that we found the root cause.
Your tests are the most important, coding takes the second place, let it go
forward step by step.
Thanks,
Lai
>
> I see that you guys are still discussing the details of the fix. When you
> decide on a final solution I'm happy to retest. Just be sure to ask :). It is
> hard to tell what to test with so many patches and code snippets flying
> around all the time.
>
> Happy coding.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/9] ARM: Berlin: USB support
> > we are early in the cycle and I feel there will be a v2 of the chipidea > stub. IMHO, controlling the vbus regulator should not be business of the > phy driver, so ci will have to deal with it. > vbus handling has already in chipidea common code, it treats vbus as a regulator. So, the glue layer only needs to register and add vbus-supply to dts file, no source code change is needed. Peter > Anyways, good to know you are fine with it already! > > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 76/88] 8250/16?50: Add support for Broadcom TruManage redirected serial port
On Mon, 2014-06-09 at 17:25 -0700, Greg Kroah-Hartman wrote: > 3.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Stephen Hurd > > commit ebebd49a8eab5e9aa1b1f8f1614ccc3c2120f886 upstream. > > Add support for the UART device present in Broadcom TruManage capable > NetXtreme chips (ie: 5761m 5762, and 5725). > > This implementation has a hidden transmit FIFO, so running in single-byte > interrupt mode results in too many interrupts. The UART_CAP_HFIFO > capability was added to track this. It continues to reload the THR as long > as the THRE and TSRE bits are set in the LSR up to a specified limit (1024 > is used here). > > Signed-off-by: Stephen Hurd > Signed-off-by: Michael Chan > [xr: Backported to 3.4: > - Adjust filenames > - Adjust context > - PORT_BRCM_TRUMANAGE is 22 not 24] This last line isn't true any more. Ben. > Cc: Ben Hutchings > Signed-off-by: Rui Xiang > Signed-off-by: Greg Kroah-Hartman [...] -- Ben Hutchings DNRC Motto: I can please only one person per day. Today is not your day. Tomorrow isn't looking good either. signature.asc Description: This is a digitally signed message part
Re: [patch V3 6/7] rtmutex: Cleanup deadlock detector debug logic
On Mon, 09 Jun 2014 20:28:10 -
Thomas Gleixner wrote:
> The conditions under which deadlock detection is conducted are unclear
> and undocumented.
>
> Add constants instead of using 0/1 and provide a selection function
> which hides the additional debug dependency from the calling code.
>
> Add comments where needed.
>
> Signed-off-by: Thomas Gleixner
> ---
> kernel/locking/rtmutex-debug.c |5 +-
> kernel/locking/rtmutex-debug.h |7 ++--
> kernel/locking/rtmutex.c| 69
> +++-
> kernel/locking/rtmutex.h|7 +++-
> kernel/locking/rtmutex_common.h | 15
> 5 files changed, 75 insertions(+), 28 deletions(-)
>
> Index: tip/kernel/locking/rtmutex-debug.c
> ===
> --- tip.orig/kernel/locking/rtmutex-debug.c
> +++ tip/kernel/locking/rtmutex-debug.c
> @@ -66,12 +66,13 @@ void rt_mutex_debug_task_free(struct tas
> * the deadlock. We print when we return. act_waiter can be NULL in
> * case of a remove waiter operation.
> */
> -void debug_rt_mutex_deadlock(int detect, struct rt_mutex_waiter *act_waiter,
> +void debug_rt_mutex_deadlock(enum rtmutex_chainwalk chwalk,
> + struct rt_mutex_waiter *act_waiter,
>struct rt_mutex *lock)
> {
> struct task_struct *task;
>
> - if (!debug_locks || detect || !act_waiter)
> + if (!debug_locks || chwalk || !act_waiter)
I know this will probably get a little verbose, but chwalk isn't very
descriptive. Perhaps change this to:
if (!debug_locks || chwalk == RT_MUTEX_FULL_CHAINWALK ||
!act_waiter)
To cut down on the verbosity, we could add helper macros:
#define chwalk_is_full(chwalk) ((chwalk) == RT_MUTEX_FULL_CHAINWALK)
#define chwalk_is_min(chwalk) ((chwalk) == RT_MUTEX_MIN_CHAINWALK)
And then the above would simply be:
if (!debug_locks || chwalk_is_full(chwalk) || !act_waiter)
And put this throughout.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 65/88] mpt2sas: Fix for issue Missing delay not getting set during system bootup
On Mon, 2014-06-09 at 17:25 -0700, Greg Kroah-Hartman wrote: > 3.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: "Reddy, Sreekanth" > > commit 93cfcb8c998e3fe2c075fa61ab28f7b018e5049a upstream. The hash above is for 3.2.y, so you should delete it. > commit b0df96a0068daee4f9c2189c29b9053eb6e46b17 upstream. [...] This is the real upstream hash. Ben. -- Ben Hutchings DNRC Motto: I can please only one person per day. Today is not your day. Tomorrow isn't looking good either. signature.asc Description: This is a digitally signed message part
Re: [patch V3 5/7] rtmutex: Confine deadlock logic to futex
On Mon, 09 Jun 2014 20:28:09 -
Thomas Gleixner wrote:
> +/*
> + * Futex variant to allow full deadlock detection.
> + */
> +int __rt_mutex_timed_lock(struct rt_mutex *lock,
> + struct hrtimer_sleeper *timeout)
> +{
> + might_sleep();
> +
> + return rt_mutex_timed_fastlock(lock, TASK_INTERRUPTIBLE, timeout, 0,
> +rt_mutex_slowlock);
> +}
> +
> /**
> * rt_mutex_timed_lock - lock a rt_mutex interruptible
> * the timeout structure is provided
> * by the caller
> *
> - * @lock:the rt_mutex to be locked
> + * @lock:the rt_mutex to be locked
> * @timeout: timeout structure or NULL (no timeout)
> - * @detect_deadlock: deadlock detection on/off
> *
> * Returns:
> - * 0on success
> - * -EINTRwhen interrupted by a signal
> + * 0on success
> + * -EINTRwhen interrupted by a signal
> * -ETIMEDOUTwhen the timeout expired
> - * -EDEADLK when the lock would deadlock (when deadlock detection is on)
> */
> int
> -rt_mutex_timed_lock(struct rt_mutex *lock, struct hrtimer_sleeper *timeout,
> - int detect_deadlock)
> +rt_mutex_timed_lock(struct rt_mutex *lock, struct hrtimer_sleeper *timeout)
> {
> might_sleep();
>
> - return rt_mutex_timed_fastlock(lock, TASK_INTERRUPTIBLE, timeout,
> -detect_deadlock, rt_mutex_slowlock);
> + return rt_mutex_timed_fastlock(lock, TASK_INTERRUPTIBLE, timeout, 0,
> +rt_mutex_slowlock);
> }
> EXPORT_SYMBOL_GPL(rt_mutex_timed_lock);
>
I must be missing something. What's the difference between the above
and the futex variant one? They both do the exact same thing:
int foo(struct rt_mutex *lock, struct hrtimer_sleeper *timeout)
{
might_sleep();
return rt_mutex_timed_fastlock(lock, TASK_INTERRUPTIBLE, timout,
0, rt_mutex_slowlock);
}
??
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch V3 4/7] rtmutex: Siplify remove_waiter()
On Mon, 09 Jun 2014 20:28:08 -
Thomas Gleixner wrote:
> Exit right away, when the removed waiter was not the top prioriy
> waiter on the lock. Get rid of the extra indent level.
>
> Signed-off-by: Thomas Gleixner
> ---
> kernel/locking/rtmutex.c | 26 ++
> 1 file changed, 10 insertions(+), 16 deletions(-)
>
> Index: tip/kernel/locking/rtmutex.c
> ===
> --- tip.orig/kernel/locking/rtmutex.c
> +++ tip/kernel/locking/rtmutex.c
> @@ -780,7 +780,7 @@ static void remove_waiter(struct rt_mute
> {
> int first = (waiter == rt_mutex_top_waiter(lock));
> struct task_struct *owner = rt_mutex_owner(lock);
> - struct rt_mutex *next_lock = NULL;
> + struct rt_mutex *next_lock;
> unsigned long flags;
>
> raw_spin_lock_irqsave(>pi_lock, flags);
> @@ -788,28 +788,22 @@ static void remove_waiter(struct rt_mute
> current->pi_blocked_on = NULL;
> raw_spin_unlock_irqrestore(>pi_lock, flags);
>
Add comment here, something like...
/*
* Only update priority if this task was the highest priority
* task waiting on the lock, and there is an owner to update.
*/
Rest looks good.
Reviewed-by: Steven Rostedt
-- Steve
> - if (!owner)
> + if (!owner || !first)
> return;
>
> - if (first) {
> + raw_spin_lock_irqsave(>pi_lock, flags);
>
> - raw_spin_lock_irqsave(>pi_lock, flags);
> + rt_mutex_dequeue_pi(owner, waiter);
>
> - rt_mutex_dequeue_pi(owner, waiter);
> + if (rt_mutex_has_waiters(lock))
> + rt_mutex_enqueue_pi(owner, rt_mutex_top_waiter(lock));
>
> - if (rt_mutex_has_waiters(lock)) {
> - struct rt_mutex_waiter *next;
> + __rt_mutex_adjust_prio(owner);
>
> - next = rt_mutex_top_waiter(lock);
> - rt_mutex_enqueue_pi(owner, next);
> - }
> - __rt_mutex_adjust_prio(owner);
> + /* Store the lock on which owner is blocked or NULL */
> + next_lock = task_blocked_on_lock(owner);
>
> - /* Store the lock on which owner is blocked or NULL */
> - next_lock = task_blocked_on_lock(owner);
> -
> - raw_spin_unlock_irqrestore(>pi_lock, flags);
> - }
> + raw_spin_unlock_irqrestore(>pi_lock, flags);
>
> if (!next_lock)
> return;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] auditsc: audit_krule mask accesses need bounds checking
[cc list trimmed, security@ added] On Mon, Jun 9, 2014 at 5:31 PM, Greg KH wrote: > On Mon, Jun 09, 2014 at 07:35:57PM -0400, Josh Boyer wrote: >> On Mon, Jun 9, 2014 at 6:46 PM, Greg KH wrote: >> > >> > But yes, having something "real" might be good if the load gets higher, >> > right now it's so low that my "sweep pending security patches" task >> > usually catches anything pending, which is rare. >> >> How does one get added to the security@ alias? We've been carrying >> this patch in Fedora for a bit now. I'd be happy to help track things >> given we get distro security bug reports and such. > > Just ask on the security@ alias to be added and we can take it from > there. > Would it make sense for there to be someone on the security list who can assign CVE numbers? --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.4 03/88] perf: Limit perf_event_attr::sample_period to 63 bits
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Zijlstra
commit 0819b2e30ccb93edf04876237b6205eef84ec8d2 upstream.
Vince reported that using a large sample_period (one with bit 63 set)
results in wreckage since while the sample_period is fundamentally
unsigned (negative periods don't make sense) the way we implement
things very much rely on signed logic.
So limit sample_period to 63 bits to avoid tripping over this.
Reported-by: Vince Weaver
Signed-off-by: Peter Zijlstra
Link: http://lkml.kernel.org/n/tip-p25fhunibl4y3qi0zuqmy...@git.kernel.org
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
kernel/events/core.c |3 +++
1 file changed, 3 insertions(+)
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6356,6 +6356,9 @@ SYSCALL_DEFINE5(perf_event_open,
if (attr.freq) {
if (attr.sample_freq > sysctl_perf_event_sample_rate)
return -EINVAL;
+ } else {
+ if (attr.sample_period & (1ULL << 63))
+ return -EINVAL;
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.4 16/88] USB: Avoid runtime suspend loops for HCDs that cant handle suspend/resume
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Alan Stern
commit 8ef42ddd9a53b73e6fc3934278710c27f80f324f upstream.
Not all host controller drivers have bus-suspend and bus-resume
methods. When one doesn't, it will cause problems if runtime PM is
enabled in the kernel. The PM core will attempt to suspend the
controller's root hub, the suspend will fail because there is no
bus-suspend routine, and a -EBUSY error code will be returned to the
PM core. This will cause the suspend attempt to be repeated shortly
thereafter, in a never-ending loop.
Part of the problem is that the original error code -ENOENT gets
changed to -EBUSY in usb_runtime_suspend(), on the grounds that the PM
core will interpret -ENOENT as meaning that the root hub has gotten
into a runtime-PM error state. While this change is appropriate for
real USB devices, it's not such a good idea for a root hub. In fact,
considering the root hub to be in a runtime-PM error state would not
be far from the truth. Therefore this patch updates
usb_runtime_suspend() so that it adjusts error codes only for
non-root-hub devices.
Furthermore, the patch attempts to prevent the problem from occurring
in the first place by not enabling runtime PM by default for root hubs
whose host controller driver doesn't have bus_suspend and bus_resume
methods.
Signed-off-by: Alan Stern
Reported-by: Will Deacon
Tested-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/core/driver.c |9 ++---
drivers/usb/core/hub.c| 15 +--
2 files changed, 19 insertions(+), 5 deletions(-)
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -1708,10 +1708,13 @@ int usb_runtime_suspend(struct device *d
if (status == -EAGAIN || status == -EBUSY)
usb_mark_last_busy(udev);
- /* The PM core reacts badly unless the return code is 0,
-* -EAGAIN, or -EBUSY, so always return -EBUSY on an error.
+ /*
+* The PM core reacts badly unless the return code is 0,
+* -EAGAIN, or -EBUSY, so always return -EBUSY on an error
+* (except for root hubs, because they don't suspend through
+* an upstream port like other USB devices).
*/
- if (status != 0)
+ if (status != 0 && udev->parent)
return -EBUSY;
return status;
}
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1401,8 +1401,19 @@ static int hub_probe(struct usb_interfac
desc = intf->cur_altsetting;
hdev = interface_to_usbdev(intf);
- /* Hubs have proper suspend/resume support. */
- usb_enable_autosuspend(hdev);
+ /*
+* Hubs have proper suspend/resume support, except for root hubs
+* where the controller driver doesn't have bus_suspend and
+* bus_resume methods.
+*/
+ if (hdev->parent) { /* normal device */
+ usb_enable_autosuspend(hdev);
+ } else {/* root hub */
+ const struct hc_driver *drv = bus_to_hcd(hdev->bus)->driver;
+
+ if (drv->bus_suspend && drv->bus_resume)
+ usb_enable_autosuspend(hdev);
+ }
if (hdev->level == MAX_TOPO_LEVEL) {
dev_err(>dev,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.4 01/88] sched: Use CPUPRI_NR_PRIORITIES instead of MAX_RT_PRIO in cpupri check
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: "Steven Rostedt (Red Hat)"
commit 6227cb00cc120f9a43ce8313bb0475ddabcb7d01 upstream.
The check at the beginning of cpupri_find() makes sure that the task_pri
variable does not exceed the cp->pri_to_cpu array length. But that length
is CPUPRI_NR_PRIORITIES not MAX_RT_PRIO, where it will miss the last two
priorities in that array.
As task_pri is computed from convert_prio() which should never be bigger
than CPUPRI_NR_PRIORITIES, if the check should cause a panic if it is
hit.
Reported-by: Mike Galbraith
Signed-off-by: Steven Rostedt
Signed-off-by: Peter Zijlstra
Link: http://lkml.kernel.org/r/1397015410.5212.13.ca...@marge.simpson.net
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
kernel/sched/cpupri.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/kernel/sched/cpupri.c
+++ b/kernel/sched/cpupri.c
@@ -68,8 +68,7 @@ int cpupri_find(struct cpupri *cp, struc
int idx = 0;
int task_pri = convert_prio(p->prio);
- if (task_pri >= MAX_RT_PRIO)
- return 0;
+ BUG_ON(task_pri >= CPUPRI_NR_PRIORITIES);
for (idx = 0; idx < task_pri; idx++) {
struct cpupri_vec *vec = >pri_to_cpu[idx];
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.4 06/88] ARM: 8051/1: put_user: fix possible data corruption in put_user
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Andrey Ryabinin
commit 537094b64b229bf3ad146042f83e74cf6abe59df upstream.
According to arm procedure call standart r2 register is call-cloberred.
So after the result of x expression was put into r2 any following
function call in p may overwrite r2. To fix this, the result of p
expression must be saved to the temporary variable before the
assigment x expression to __r2.
Signed-off-by: Andrey Ryabinin
Reviewed-by: Nicolas Pitre
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/include/asm/uaccess.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -158,8 +158,9 @@ extern int __put_user_8(void *, unsigned
#define put_user(x,p) \
({ \
unsigned long __limit = current_thread_info()->addr_limit - 1; \
+ const typeof(*(p)) __user *__tmp_p = (p); \
register const typeof(*(p)) __r2 asm("r2") = (x); \
- register const typeof(*(p)) __user *__p asm("r0") = (p);\
+ register const typeof(*(p)) __user *__p asm("r0") = __tmp_p; \
register unsigned long __l asm("r1") = __limit; \
register int __e asm("r0"); \
switch (sizeof(*(__p))) { \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.4 05/88] mm/memory-failure.c: fix memory leak by race between poison and unpoison
3.4-stable review patch. If anyone has any objections, please let me know.
--
From: Naoya Horiguchi
commit 3e030ecc0fc7de10fd0da10c1c19939872a31717 upstream.
When a memory error happens on an in-use page or (free and in-use)
hugepage, the victim page is isolated with its refcount set to one.
When you try to unpoison it later, unpoison_memory() calls put_page()
for it twice in order to bring the page back to free page pool (buddy or
free hugepage list). However, if another memory error occurs on the
page which we are unpoisoning, memory_failure() returns without
releasing the refcount which was incremented in the same call at first,
which results in memory leak and unconsistent num_poisoned_pages
statistics. This patch fixes it.
Signed-off-by: Naoya Horiguchi
Cc: Andi Kleen
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
mm/memory-failure.c |2 ++
1 file changed, 2 insertions(+)
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1122,6 +1122,8 @@ int memory_failure(unsigned long pfn, in
*/
if (!PageHWPoison(p)) {
printk(KERN_ERR "MCE %#lx: just unpoisoned\n", pfn);
+ atomic_long_sub(nr_pages, _bad_pages);
+ put_page(hpage);
res = 0;
goto out;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
