Re: [PATCH net 09/10] net: hns: adds limitation for debug port mtu
在 2016/3/21 22:17, Sergei Shtylyov 写道: > Hello. > > On 03/21/2016 02:06 PM, Yisen Zhuang wrote: > >> From: Kejian Yan >> >> If mtu for debug port is set more than 1500, it may cause that packets >> are dropped by ppe. So maximum value for debug port should be 1500. >> >> Signed-off-by: Kejian Yan >> Signed-off-by: Yisen Zhuang > [...] >> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h >> b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h >> index a69c8af..a68efd6 100644 >> --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h >> +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h >> @@ -28,6 +28,7 @@ struct dsaf_device; >> #define MAC_MAX_MTU9600 >> #define MAC_MAX_MTU_V29728 >> #define MAC_MIN_MTU68 >> +#define MAC_MAX_MTU_DBG MAC_DEFAULT_MTU > >Please use tabs, not spaces to indent the value, like above Will fix it in next version. Thanks, Yisen > > [...] > > MBR, Sergei > > > . >
Re: [PATCH] cpufreq: rockchip: add driver
I get it, thanks. 在 2016/3/21 23:52, Heiko Stübner 写道: Am Montag, 21. März 2016, 16:13:40 schrieb Heiko Stübner: Hi, Am Montag, 21. März 2016, 21:24:32 schrieb Feng Xiao: 在 2016/3/21 17:58, Viresh Kumar 写道: On 21-03-16, 10:54, Heiko Stübner wrote: I hadn't seen that yet ... nice that cpufreq-dt now also supports clusters :-) The other part still stands though, as we probably should register the platform-device somewhere else and not in some new special module. When everything is using cpufreq-dt now, I guess we could just add it to the core rockchip clk-code. Or was there some agreement where this should be done (obviously not the devicetree itself)? Of_clk_init is called early, and platform_device_register_simple should be called after devices_init, it will be failed to do it from clk-code. So we need add a new file or add module_init to each clock controller driver(like clk-rk3368.c, clk-rk3399.c) ? as Viresh said, it should be ok to do it like your approach creating a module in drivers/cpufreq. But the compatible check is necessary. Doing it this way also makes it easier to have Seem like I forgot the complete my sentence here. This should've been Doing it this way also makes it easier to have everything go into cpufreq-dt once that whitelist appears that Viresh wrote about. So this might be better than to distribute this stuff around other subsystems, as I originally suggested. Yeah, there was a discussion around creating a white or black list of platforms that want to create a platform device for cpufreq-dt. That can be done in cpufreq-dt.c or a new file, but I haven't worked out on that yet. You can do it from clk-code or from the driver that was added in this thread. Just that you need to match your platform's compatible string before doing that. Rockchip-cpufreq.c depends on ARM_ROCKCHIP_CPUFREQ, it will not be compiled on non-Rockchip platforms. The driver can support all Rockchip SoCs up to now, add of_machine_is_compatible may be redundant ? Please always keep multiplatform in mind. These days the kernel can be compiled for multiple architectures at the same time, so you can have support for Rockchip, Exynos, Qualcom and whatever in the same kernel image. Therefore a compile-time check is not enough and you need to check the actually running machine as well. Heiko
RE: [PATCH v2 3/3] Make core_pattern support namespace
Hi, Eric > -Original Message- > From: Eric W. Biederman [mailto:ebied...@xmission.com] > Sent: Tuesday, March 22, 2016 5:25 AM > To: Zhao Lei > Cc: linux-kernel@vger.kernel.org; contain...@lists.linux-foundation.org; > 'Mateusz Guzik' ; 'Kamezawa Hiroyuki' > > Subject: Re: [PATCH v2 3/3] Make core_pattern support namespace > > Zhao Lei writes: > > > Hi, Eric > > > >> -Original Message- > >> From: Eric W. Biederman [mailto:ebied...@xmission.com] > > > Let me make a summarize: > > You think this way is not acceptable, because the pipe program is running > > in the panic-process's namespace context. > > Actually my view is that your patchset is not acceptable because it > is implemented in a way that is not backwards compatible (AKA it can > break existing configurations that remain unchanged) and your > implementation does not appear in the least safe from malicious users. > > There is also a problem that your patchset is simply buggy for what it > tries to implement, as using pid_ns_for_children and the multiple kbuild > robot emails testifies. > > > And in my view, a pipe program in the host's top level namespace is also > > a problem. > > > > Let us think a container, to make it act as a real machine, when a program > > panic, linux kernel should dump it into the container's filesystem. > > > > For the kernel, to keep the current way of forking pipe program by kthread, > > just let the pipe thread running in the container's namespace, instead the > host, > > may solve the problem in current kernel. > > > > What is your opinion? > > > > Btw, this patch is trying to solve the problem descripted in thread named: > > "piping core dump to a program escapes container" in > > > http://lists.linuxfoundation.org/pipermail/containers/2015-December/036476. > html > > Maybe using a userspace tool can make container dump to anywhere, > > but for kernel ifself, it is better to solve above problem if we can. > > I think it would be great to find a way to run a core dump helper and > otherwise allow setting the core dump pattern in a container in a way > that is safe from malicious users and does not break existing setups. > So, there is following problem: 1: safe from malicious users We can try to find a way to fork process which have no relationship with the panic process. 2: Bug in patch It can be fixed, but I'd rather get a conclusion of this discussion before fix. 3: Backwards compatible It maybe the biggest problem in discussion, this patch is used to let container dump files into container, it is different with current action. Before patch: File type dump_pattern: dump to container Pipe type dump_pattern: dump to host After patch: File type dump_pattern: dump to container Pipe type dump_pattern: dump to container The second design seems better but not compatible with current kernel, but this patch can not fix to keep compatible because it is the patch's function. Maybe we can make some workagound, as: a. Add a kernel config to let the old style as default. b. keep old style, and add "||" for core_pattern, as echo "|| /root/container_dumper" >/proc/sys/kernel/core_pattern to dump to container. What is your opinion about it? Thanks Zhaolei
RE: [PATCH net-next 1/3] net: add the AF_KCM entries to family name tables
> From: David Miller [mailto:da...@davemloft.net] > Sent: Monday, March 21, 2016 23:28 > To: Dexuan Cui > Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; jasow...@redhat.com; KY Srinivasan > ; Haiyang Zhang ; > vkuzn...@redhat.com > Subject: Re: [PATCH net-next 1/3] net: add the AF_KCM entries to family > name tables > > > Two things wrong with this submission: > > 1) You need to provide an initial "[PATCH net-next 0/3] ..." header posting >explaining at a high level what this patch series is about and how it is >implemented and why. Hi David, Thanks for the reply! I'll fix this. > 2) The net-next tree is closed at this time because we are in the merge > window, >therefore no new feature patches should be submitted to the netdev > mailing >list at this time. Please wait until some (reasonable) amount of time > after >the merge window closes to resubmit this. OK. I'll repost it when the merge window is open -- I suppose that would happen in 1~2 weeks, according to my reading the documentation. Thanks, -- Dexuan
Re: [PATCH v2 3/5] dt-bindings: Add documentation for GM20B GPU
On Sun, Mar 20, 2016 at 1:55 AM, Alexandre Courbot wrote:
> On Sat, Mar 19, 2016 at 5:47 AM, Rob Herring wrote:
>> On Tue, Mar 15, 2016 at 11:58:42AM +0900, Alexandre Courbot wrote:
>>> GM20B's definition is mostly similar to GK20A's, but requires an
>>> additional clock.
[...]
>>> gpu@0,5700 {
>>> compatible = "nvidia,gk20a";
>>> @@ -45,3 +49,22 @@ Example:
>>> iommus = <&mc TEGRA_SWGROUP_GPU>;
>>> status = "disabled";
>>> };
>>> +
>>> +Example for GM20B:
>>> +
>>> + gpu@0,5700 {
>>
>> Drop the comma and leading zero.
>
> Even though this is how it appears in the actual DT?
Yes, those will need to get fixed, too.
Rob
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64
On Mon, Mar 21, 2016 at 09:43:12PM +0300, Yury Norov wrote:
> On Mon, Mar 21, 2016 at 07:23:28PM +0800, Zhangjian (Bamvor) wrote:
> > >>So this most probably means that ilp32 code doesn't handle one of cloned
> > >>item properly. I have already discovered a bug where child processes
> > >>used parent TLS,
> > >It is a kernel bug or glibc bug? Could you please explain it or show the
> > >patch?
> > >The current ILP32 patches looks good to me. Recently, I backport these
> > >patches
> > >to our 4.1 kernel. And I saw crash frequently even if I only do a single
> > >print
> > >or infinite loop. There is some small changes about tls register after
> > >4.1. I
> > >am not sure if it is a similar issue. It is great if you have some
> > >suggestions/
> > >ideas.
> > My issue is because I forget to change is_compat_task to
> > is_a32_compat_task in arch/arm64/kernel/process.c such piece of code
> > is delete after commit d00a3810c162 ("arm64: context-switch user tls
> > register tpidr_el0 for compat tasks). It is not exist in upstream
> > kernel, never mind.
> >
> > Meanwhile, I found that it seem that there is another is_compat_task
> > in tls_thread_flush. Is it relative the issue you mentioned?
> >
> > ```
> > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > index 432b094..9ab968c 100644
> > --- a/arch/arm64/kernel/process.c
> > +++ b/arch/arm64/kernel/process.c
> > @@ -209,7 +209,7 @@ static void tls_thread_flush(void)
> > {
> > asm ("msr tpidr_el0, xzr");
> >
> > - if (is_compat_task()) {
> > + if (is_a32_compat_task()) {
> > current->thread.tp_value = 0;
> >
> > /*
> > ```
> >
> > Regards
> >
> > Bamvor
>
> Hi,
>
> This fix looks correct, though doesn't fix issue.
> Thank you.
>
> Yury.
Hi again.
Next fix helps with SIGSEGV crash of trigo test. But now it hangs on
futex, so work is not finished yet. Nevertheless, you can apply it and
do your tests.
Signed-off-by: Yury Norov
---
arch/arm64/kernel/signal_ilp32.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/signal_ilp32.c b/arch/arm64/kernel/signal_ilp32.c
index 455b0fb..1bb0ea8 100644
--- a/arch/arm64/kernel/signal_ilp32.c
+++ b/arch/arm64/kernel/signal_ilp32.c
@@ -107,6 +107,7 @@ int ilp32_setup_rt_frame(int usig, struct ksignal *ksig,
if (!frame)
return 1;
+ err |= copy_siginfo_to_user32(&frame->info, &ksig->info);
__put_user_error(0, &frame->sig.uc.uc_flags, err);
__put_user_error(NULL, &frame->sig.uc.uc_link, err);
@@ -115,12 +116,9 @@ int ilp32_setup_rt_frame(int usig, struct ksignal *ksig,
err |= setup_sigframe(&frame->sig, regs, set);
if (err == 0) {
setup_return(regs, &ksig->ka, frame,
- offsetof(struct ilp32_rt_sigframe, sig), usig);
- if (ksig->ka.sa.sa_flags & SA_SIGINFO) {
- err |= copy_siginfo_to_user32(&frame->info,
&ksig->info);
- regs->regs[1] = (unsigned long)&frame->info;
- regs->regs[2] = (unsigned long)&frame->sig.uc;
- }
+ offsetof(struct ilp32_rt_sigframe, sig), usig);
+ regs->regs[1] = (unsigned long)&frame->info;
+ regs->regs[2] = (unsigned long)&frame->sig.uc;
}
return err;
--
2.5.0
[PATCH v6 1/7][Resend] cpufreq: sched: Helpers to add and remove update_util hooks
From: Rafael J. Wysocki
Replace the single helper for adding and removing cpufreq utilization
update hooks, cpufreq_set_update_util_data(), with a pair of helpers,
cpufreq_add_update_util_hook() and cpufreq_remove_update_util_hook(),
and modify the users of cpufreq_set_update_util_data() accordingly.
With the new helpers, the code using them doesn't need to worry
about the internals of struct update_util_data and in particular
it doesn't need to worry about populating the func field in it
properly upfront.
Signed-off-by: Rafael J. Wysocki
---
No changes since v4 (this patch appeared then).
---
drivers/cpufreq/cpufreq_governor.c | 76 ++---
drivers/cpufreq/intel_pstate.c |8 +--
include/linux/sched.h |5 +-
kernel/sched/cpufreq.c | 48 ++-
4 files changed, 83 insertions(+), 54 deletions(-)
Index: linux-pm/include/linux/sched.h
===
--- linux-pm.orig/include/linux/sched.h
+++ linux-pm/include/linux/sched.h
@@ -3218,7 +3218,10 @@ struct update_util_data {
u64 time, unsigned long util, unsigned long max);
};
-void cpufreq_set_update_util_data(int cpu, struct update_util_data *data);
+void cpufreq_add_update_util_hook(int cpu, struct update_util_data *data,
+ void (*func)(struct update_util_data *data, u64 time,
+unsigned long util, unsigned long max));
+void cpufreq_remove_update_util_hook(int cpu);
#endif /* CONFIG_CPU_FREQ */
#endif
Index: linux-pm/kernel/sched/cpufreq.c
===
--- linux-pm.orig/kernel/sched/cpufreq.c
+++ linux-pm/kernel/sched/cpufreq.c
@@ -14,24 +14,50 @@
DEFINE_PER_CPU(struct update_util_data *, cpufreq_update_util_data);
/**
- * cpufreq_set_update_util_data - Populate the CPU's update_util_data pointer.
+ * cpufreq_add_update_util_hook - Populate the CPU's update_util_data pointer.
* @cpu: The CPU to set the pointer for.
* @data: New pointer value.
+ * @func: Callback function to set for the CPU.
*
- * Set and publish the update_util_data pointer for the given CPU. That
pointer
- * points to a struct update_util_data object containing a callback function
- * to call from cpufreq_update_util(). That function will be called from an
RCU
- * read-side critical section, so it must not sleep.
+ * Set and publish the update_util_data pointer for the given CPU.
*
- * Callers must use RCU-sched callbacks to free any memory that might be
- * accessed via the old update_util_data pointer or invoke synchronize_sched()
- * right after this function to avoid use-after-free.
+ * The update_util_data pointer of @cpu is set to @data and the callback
+ * function pointer in the target struct update_util_data is set to @func.
+ * That function will be called by cpufreq_update_util() from RCU-sched
+ * read-side critical sections, so it must not sleep. @data will always be
+ * passed to it as the first argument which allows the function to get to the
+ * target update_util_data structure and its container.
+ *
+ * The update_util_data pointer of @cpu must be NULL when this function is
+ * called or it will WARN() and return with no effect.
*/
-void cpufreq_set_update_util_data(int cpu, struct update_util_data *data)
+void cpufreq_add_update_util_hook(int cpu, struct update_util_data *data,
+ void (*func)(struct update_util_data *data, u64 time,
+unsigned long util, unsigned long max))
{
- if (WARN_ON(data && !data->func))
+ if (WARN_ON(!data || !func))
return;
+ if (WARN_ON(per_cpu(cpufreq_update_util_data, cpu)))
+ return;
+
+ data->func = func;
rcu_assign_pointer(per_cpu(cpufreq_update_util_data, cpu), data);
}
-EXPORT_SYMBOL_GPL(cpufreq_set_update_util_data);
+EXPORT_SYMBOL_GPL(cpufreq_add_update_util_hook);
+
+/**
+ * cpufreq_remove_update_util_hook - Clear the CPU's update_util_data pointer.
+ * @cpu: The CPU to clear the pointer for.
+ *
+ * Clear the update_util_data pointer for the given CPU.
+ *
+ * Callers must use RCU-sched callbacks to free any memory that might be
+ * accessed via the old update_util_data pointer or invoke synchronize_sched()
+ * right after this function to avoid use-after-free.
+ */
+void cpufreq_remove_update_util_hook(int cpu)
+{
+ rcu_assign_pointer(per_cpu(cpufreq_update_util_data, cpu), NULL);
+}
+EXPORT_SYMBOL_GPL(cpufreq_remove_update_util_hook);
Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -258,43 +258,6 @@ unsigned int dbs_update(struct cpufreq_p
}
EXPORT_SYMBOL_GPL(dbs_update);
-static void gov_set_update_util(struct policy_dbs_info *po
[PATCH v6 7/7][Resend] cpufreq: schedutil: New governor based on scheduler utilization data
From: Rafael J. Wysocki Add a new cpufreq scaling governor, called "schedutil", that uses scheduler-provided CPU utilization information as input for making its decisions. Doing that is possible after commit 34e2c555f3e1 (cpufreq: Add mechanism for registering utilization update callbacks) that introduced cpufreq_update_util() called by the scheduler on utilization changes (from CFS) and RT/DL task status updates. In particular, CPU frequency scaling decisions may be based on the the utilization data passed to cpufreq_update_util() by CFS. The new governor is relatively simple. The frequency selection formula used by it depends on whether or not the utilization is frequency-invariant. In the frequency-invariant case the new CPU frequency is given by next_freq = 1.25 * max_freq * util / max where util and max are the last two arguments of cpufreq_update_util(). In turn, if util is not frequency-invariant, the maximum frequency in the above formula is replaced with the current frequency of the CPU: next_freq = 1.25 * curr_freq * util / max The coefficient 1.25 corresponds to the frequency tipping point at (util / max) = 0.8. All of the computations are carried out in the utilization update handlers provided by the new governor. One of those handlers is used for cpufreq policies shared between multiple CPUs and the other one is for policies with one CPU only (and therefore it doesn't need to use any extra synchronization means). The governor supports fast frequency switching if that is supported by the cpufreq driver in use and possible for the given policy. In the fast switching case, all operations of the governor take place in its utilization update handlers. If fast switching cannot be used, the frequency switch operations are carried out with the help of a work item which only calls __cpufreq_driver_target() (under a mutex) to trigger a frequency update (to a value already computed beforehand in one of the utilization update handlers). Currently, the governor treats all of the RT and DL tasks as "unknown utilization" and sets the frequency to the allowed maximum when updated from the RT or DL sched classes. That heavy-handed approach should be replaced with something more subtle and specifically targeted at RT and DL tasks. The governor shares some tunables management code with the "ondemand" and "conservative" governors and uses some common definitions from cpufreq_governor.h, but apart from that it is stand-alone. Signed-off-by: Rafael J. Wysocki --- Changes from v5: - Fixed sugov_update_commit() to set sg_policy->next_freq properly in the "work item" branch. - Used smp_processor_id() in sugov_irq_work() and restored work_in_progress. Changes from v4: - Use TICK_NSEC in sugov_next_freq_shared(). - Use schedule_work_on() to schedule work items and replace work_in_progress with work_cpu (which is used both for scheduling work items and as a "work in progress" marker). - Rearrange sugov_update_commit() to only check policy->min/max if fast switching is enabled. - Replace util > max checks with util == ULONG_MAX checks to make it clear that they are about a special case (RT/DL). Changes from v3: - The "next frequency" formula based on http://marc.info/?l=linux-acpi&m=145756618321500&w=4 and http://marc.info/?l=linux-kernel&m=145760739700716&w=4 - The governor goes into kernel/sched/ (again). Changes from v2: - The governor goes into drivers/cpufreq/. - The "next frequency" formula has an additional 1.1 factor to allow more util/max values to map onto the top-most frequency in case the distance between that and the previous one is unproportionally small. - sugov_update_commit() traces CPU frequency even if the new one is the same as the previous one (otherwise, if the system is 100% loaded for long enough, powertop starts to report that all CPUs are 100% idle). --- drivers/cpufreq/Kconfig | 26 + kernel/sched/Makefile|1 kernel/sched/cpufreq_schedutil.c | 528 +++ kernel/sched/sched.h |8 4 files changed, 563 insertions(+) Index: linux-pm/drivers/cpufreq/Kconfig === --- linux-pm.orig/drivers/cpufreq/Kconfig +++ linux-pm/drivers/cpufreq/Kconfig @@ -107,6 +107,16 @@ config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE Be aware that not all cpufreq drivers support the conservative governor. If unsure have a look at the help section of the driver. Fallback governor will be the performance governor. + +config CPU_FREQ_DEFAULT_GOV_SCHEDUTIL + bool "schedutil" + select CPU_FREQ_GOV_SCHEDUTIL + select CPU_FREQ_GOV_PERFORMANCE + help + Use the 'schedutil' CPUFreq governor by default. If unsure, + have a look at the help section of that governor. The fallback + governor will be 'performance'. + endchoice config CPU_FREQ_GOV_PERFORMANCE @@ -18
[PATCH v6 5/7][Resend] cpufreq: Move governor symbols to cpufreq.h
From: Rafael J. Wysocki
Move definitions of symbols related to transition latency and
sampling rate to include/linux/cpufreq.h so they can be used by
(future) goverernors located outside of drivers/cpufreq/.
No functional changes.
Signed-off-by: Rafael J. Wysocki
---
This patch was new in v4, no changes since then.
---
drivers/cpufreq/cpufreq_governor.h | 14 --
include/linux/cpufreq.h| 14 ++
2 files changed, 14 insertions(+), 14 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq_governor.h
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.h
+++ linux-pm/drivers/cpufreq/cpufreq_governor.h
@@ -24,20 +24,6 @@
#include
#include
-/*
- * The polling frequency depends on the capability of the processor. Default
- * polling frequency is 1000 times the transition latency of the processor. The
- * governor will work on any processor with transition latency <= 10ms, using
- * appropriate sampling rate.
- *
- * For CPUs with transition latency > 10ms (mostly drivers with
CPUFREQ_ETERNAL)
- * this governor will not work. All times here are in us (micro seconds).
- */
-#define MIN_SAMPLING_RATE_RATIO(2)
-#define LATENCY_MULTIPLIER (1000)
-#define MIN_LATENCY_MULTIPLIER (20)
-#define TRANSITION_LATENCY_LIMIT (10 * 1000 * 1000)
-
/* Ondemand Sampling types */
enum {OD_NORMAL_SAMPLE, OD_SUB_SAMPLE};
Index: linux-pm/include/linux/cpufreq.h
===
--- linux-pm.orig/include/linux/cpufreq.h
+++ linux-pm/include/linux/cpufreq.h
@@ -426,6 +426,20 @@ static inline unsigned long cpufreq_scal
#define CPUFREQ_POLICY_POWERSAVE (1)
#define CPUFREQ_POLICY_PERFORMANCE (2)
+/*
+ * The polling frequency depends on the capability of the processor. Default
+ * polling frequency is 1000 times the transition latency of the processor. The
+ * ondemand governor will work on any processor with transition latency <=
10ms,
+ * using appropriate sampling rate.
+ *
+ * For CPUs with transition latency > 10ms (mostly drivers with
CPUFREQ_ETERNAL)
+ * the ondemand governor will not work. All times here are in us
(microseconds).
+ */
+#define MIN_SAMPLING_RATE_RATIO(2)
+#define LATENCY_MULTIPLIER (1000)
+#define MIN_LATENCY_MULTIPLIER (20)
+#define TRANSITION_LATENCY_LIMIT (10 * 1000 * 1000)
+
/* Governor Events */
#define CPUFREQ_GOV_START 1
#define CPUFREQ_GOV_STOP 2
[PATCH v6 2/7][Resend] cpufreq: governor: New data type for management part of dbs_data
From: Rafael J. Wysocki
In addition to fields representing governor tunables, struct dbs_data
contains some fields needed for the management of objects of that
type. As it turns out, that part of struct dbs_data may be shared
with (future) governors that won't use the common code used by
"ondemand" and "conservative", so move it to a separate struct type
and modify the code using struct dbs_data to follow.
Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
---
No changes from previous versions.
---
drivers/cpufreq/cpufreq_conservative.c | 25 +
drivers/cpufreq/cpufreq_governor.c | 90 -
drivers/cpufreq/cpufreq_governor.h | 35 +++-
drivers/cpufreq/cpufreq_ondemand.c | 29 ++
4 files changed, 107 insertions(+), 72 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq_governor.h
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.h
+++ linux-pm/drivers/cpufreq/cpufreq_governor.h
@@ -41,6 +41,13 @@
/* Ondemand Sampling types */
enum {OD_NORMAL_SAMPLE, OD_SUB_SAMPLE};
+struct gov_attr_set {
+ struct kobject kobj;
+ struct list_head policy_list;
+ struct mutex update_lock;
+ int usage_count;
+};
+
/*
* Abbreviations:
* dbs: used as a shortform for demand based switching It helps to keep
variable
@@ -52,7 +59,7 @@ enum {OD_NORMAL_SAMPLE, OD_SUB_SAMPLE};
/* Governor demand based switching data (per-policy or global). */
struct dbs_data {
- int usage_count;
+ struct gov_attr_set attr_set;
void *tuners;
unsigned int min_sampling_rate;
unsigned int ignore_nice_load;
@@ -60,37 +67,35 @@ struct dbs_data {
unsigned int sampling_down_factor;
unsigned int up_threshold;
unsigned int io_is_busy;
-
- struct kobject kobj;
- struct list_head policy_dbs_list;
- /*
-* Protect concurrent updates to governor tunables from sysfs,
-* policy_dbs_list and usage_count.
-*/
- struct mutex mutex;
};
+static inline struct dbs_data *to_dbs_data(struct gov_attr_set *attr_set)
+{
+ return container_of(attr_set, struct dbs_data, attr_set);
+}
+
/* Governor's specific attributes */
-struct dbs_data;
struct governor_attr {
struct attribute attr;
- ssize_t (*show)(struct dbs_data *dbs_data, char *buf);
- ssize_t (*store)(struct dbs_data *dbs_data, const char *buf,
+ ssize_t (*show)(struct gov_attr_set *attr_set, char *buf);
+ ssize_t (*store)(struct gov_attr_set *attr_set, const char *buf,
size_t count);
};
#define gov_show_one(_gov, file_name) \
static ssize_t show_##file_name
\
-(struct dbs_data *dbs_data, char *buf) \
+(struct gov_attr_set *attr_set, char *buf) \
{ \
+ struct dbs_data *dbs_data = to_dbs_data(attr_set); \
struct _gov##_dbs_tuners *tuners = dbs_data->tuners;\
return sprintf(buf, "%u\n", tuners->file_name); \
}
#define gov_show_one_common(file_name) \
static ssize_t show_##file_name
\
-(struct dbs_data *dbs_data, char *buf) \
+(struct gov_attr_set *attr_set, char *buf) \
{ \
+ struct dbs_data *dbs_data = to_dbs_data(attr_set); \
return sprintf(buf, "%u\n", dbs_data->file_name); \
}
@@ -184,7 +189,7 @@ void od_register_powersave_bias_handler(
(struct cpufreq_policy *, unsigned int, unsigned int),
unsigned int powersave_bias);
void od_unregister_powersave_bias_handler(void);
-ssize_t store_sampling_rate(struct dbs_data *dbs_data, const char *buf,
+ssize_t store_sampling_rate(struct gov_attr_set *attr_set, const char *buf,
size_t count);
void gov_update_cpu_data(struct dbs_data *dbs_data);
#endif /* _CPUFREQ_GOVERNOR_H */
Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -43,9 +43,10 @@ static DEFINE_MUTEX(gov_dbs_data_mutex);
* This must be called with dbs_data->mutex held, otherwise traversing
* policy_dbs_list isn't safe.
*/
-ssize_t store_sampling_rate(struct dbs_data *dbs_data, const char *buf,
+ssize_t store_sampling_rate(struct gov_attr_set *attr_set, const char *buf,
size_t count)
{
+ struct dbs_data *dbs_data = to_dbs_data(attr_set);
struct policy_dbs
[PATCH v6 4/7][Resend] cpufreq: Move governor attribute set headers to cpufreq.h
From: Rafael J. Wysocki
Move definitions and function headers related to struct gov_attr_set
to include/linux/cpufreq.h so they can be used by (future) goverernors
located outside of drivers/cpufreq/.
No functional changes.
Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
---
This one was first present in v2, no changes since then.
---
drivers/cpufreq/cpufreq_governor.h | 21 -
include/linux/cpufreq.h| 23 +++
2 files changed, 23 insertions(+), 21 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq_governor.h
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.h
+++ linux-pm/drivers/cpufreq/cpufreq_governor.h
@@ -41,19 +41,6 @@
/* Ondemand Sampling types */
enum {OD_NORMAL_SAMPLE, OD_SUB_SAMPLE};
-struct gov_attr_set {
- struct kobject kobj;
- struct list_head policy_list;
- struct mutex update_lock;
- int usage_count;
-};
-
-extern const struct sysfs_ops governor_sysfs_ops;
-
-void gov_attr_set_init(struct gov_attr_set *attr_set, struct list_head
*list_node);
-void gov_attr_set_get(struct gov_attr_set *attr_set, struct list_head
*list_node);
-unsigned int gov_attr_set_put(struct gov_attr_set *attr_set, struct list_head
*list_node);
-
/*
* Abbreviations:
* dbs: used as a shortform for demand based switching It helps to keep
variable
@@ -80,14 +67,6 @@ static inline struct dbs_data *to_dbs_da
return container_of(attr_set, struct dbs_data, attr_set);
}
-/* Governor's specific attributes */
-struct governor_attr {
- struct attribute attr;
- ssize_t (*show)(struct gov_attr_set *attr_set, char *buf);
- ssize_t (*store)(struct gov_attr_set *attr_set, const char *buf,
-size_t count);
-};
-
#define gov_show_one(_gov, file_name) \
static ssize_t show_##file_name
\
(struct gov_attr_set *attr_set, char *buf) \
Index: linux-pm/include/linux/cpufreq.h
===
--- linux-pm.orig/include/linux/cpufreq.h
+++ linux-pm/include/linux/cpufreq.h
@@ -462,6 +462,29 @@ void cpufreq_unregister_governor(struct
struct cpufreq_governor *cpufreq_default_governor(void);
struct cpufreq_governor *cpufreq_fallback_governor(void);
+/* Governor attribute set */
+struct gov_attr_set {
+ struct kobject kobj;
+ struct list_head policy_list;
+ struct mutex update_lock;
+ int usage_count;
+};
+
+/* sysfs ops for cpufreq governors */
+extern const struct sysfs_ops governor_sysfs_ops;
+
+void gov_attr_set_init(struct gov_attr_set *attr_set, struct list_head
*list_node);
+void gov_attr_set_get(struct gov_attr_set *attr_set, struct list_head
*list_node);
+unsigned int gov_attr_set_put(struct gov_attr_set *attr_set, struct list_head
*list_node);
+
+/* Governor sysfs attribute */
+struct governor_attr {
+ struct attribute attr;
+ ssize_t (*show)(struct gov_attr_set *attr_set, char *buf);
+ ssize_t (*store)(struct gov_attr_set *attr_set, const char *buf,
+size_t count);
+};
+
/*
* FREQUENCY TABLE HELPERS *
*/
[PATCH v6 6/7][Resend] cpufreq: Support for fast frequency switching
From: Rafael J. Wysocki
Modify the ACPI cpufreq driver to provide a method for switching
CPU frequencies from interrupt context and update the cpufreq core
to support that method if available.
Introduce a new cpufreq driver callback, ->fast_switch, to be
invoked for frequency switching from interrupt context by (future)
governors supporting that feature via (new) helper function
cpufreq_driver_fast_switch().
Add two new policy flags, fast_switch_possible, to be set by the
cpufreq driver if fast frequency switching can be used for the
given policy and fast_switch_enabled, to be set by the governor
if it is going to use fast frequency switching for the given
policy. Also add a helper for setting the latter.
Since fast frequency switching is inherently incompatible with
cpufreq transition notifiers, make it possible to set the
fast_switch_enabled only if there are no transition notifiers
already registered and make the registration of new transition
notifiers fail if fast_switch_enabled is set for at least one
policy.
Implement the ->fast_switch callback in the ACPI cpufreq driver
and make it set fast_switch_possible during policy initialization
as appropriate.
Signed-off-by: Rafael J. Wysocki
---
Changes from v5:
- cpufreq_enable_fast_switch() fixed to avoid printing a confusing message
if fast_switch_possible is not set for the policy.
- Fixed a typo in that message.
- Removed the WARN_ON() from the (cpufreq_fast_switch_count > 0) check in
cpufreq_register_notifier(), because it triggered false-positive warnings
from the cpufreq_stats module (cpufreq_stats don't work with the fast
switching, because it is based on notifiers).
Changes from v4:
- If cpufreq_enable_fast_switch() is about to fail, it will print the list
of currently registered transition notifiers.
- Added lock_assert_held(&policy->rwsem) to cpufreq_enable_fast_switch().
- Added WARN_ON() to the (cpufreq_fast_switch_count > 0) check in
cpufreq_register_notifier().
- Modified the kerneldoc comment of cpufreq_driver_fast_switch() to
mention the RELATION_L expectation regarding the ->fast_switch callback.
Changes from v3:
- New fast_switch_enabled field in struct cpufreq_policy to help
avoid affecting existing setups by setting the fast_switch_possible
flag in the driver.
- __cpufreq_get() skips the policy->cur check if fast_switch_enabled is set.
Changes from v2:
- The driver ->fast_switch callback and cpufreq_driver_fast_switch()
don't need the relation argument as they will always do RELATION_L now.
- New mechanism to make fast switch and cpufreq notifiers mutually
exclusive.
- cpufreq_driver_fast_switch() doesn't do anything in addition to
invoking the driver callback and returns its return value.
---
drivers/cpufreq/acpi-cpufreq.c | 41
drivers/cpufreq/cpufreq.c | 130 ++---
include/linux/cpufreq.h|9 ++
3 files changed, 171 insertions(+), 9 deletions(-)
Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c
===
--- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c
+++ linux-pm/drivers/cpufreq/acpi-cpufreq.c
@@ -458,6 +458,43 @@ static int acpi_cpufreq_target(struct cp
return result;
}
+unsigned int acpi_cpufreq_fast_switch(struct cpufreq_policy *policy,
+ unsigned int target_freq)
+{
+ struct acpi_cpufreq_data *data = policy->driver_data;
+ struct acpi_processor_performance *perf;
+ struct cpufreq_frequency_table *entry;
+ unsigned int next_perf_state, next_freq, freq;
+
+ /*
+* Find the closest frequency above target_freq.
+*
+* The table is sorted in the reverse order with respect to the
+* frequency and all of the entries are valid (see the initialization).
+*/
+ entry = data->freq_table;
+ do {
+ entry++;
+ freq = entry->frequency;
+ } while (freq >= target_freq && freq != CPUFREQ_TABLE_END);
+ entry--;
+ next_freq = entry->frequency;
+ next_perf_state = entry->driver_data;
+
+ perf = to_perf_data(data);
+ if (perf->state == next_perf_state) {
+ if (unlikely(data->resume))
+ data->resume = 0;
+ else
+ return next_freq;
+ }
+
+ data->cpu_freq_write(&perf->control_register,
+perf->states[next_perf_state].control);
+ perf->state = next_perf_state;
+ return next_freq;
+}
+
static unsigned long
acpi_cpufreq_guess_freq(struct acpi_cpufreq_data *data, unsigned int cpu)
{
@@ -740,6 +777,9 @@ static int acpi_cpufreq_cpu_init(struct
goto err_unreg;
}
+ policy->fast_switch_possible = !acpi_pstate_strict &&
+ !(policy_is_shared(policy) && policy->shared_type !=
CPUFREQ_SHARED_TYPE_ANY);
+
data->freq_table = kzalloc(sizeof(*d
[PATCH v6 0/7] cpufreq: schedutil governor
Hi, Yet another iteration of the schedutil governor patchset. It essentially is a resend of the series, but since patches [6-7/7] have been updated since the v4 (http://marc.info/?l=linux-kernel&m=145814047719883&w=4), the complete series goes again here. The patches are based on the current Linus' tree and they have been present in my pm-cpufreq-experimental branch for a few days. Also, Srinivas ran SpecPower on one of the previous iterations and the results are very promising. With CPU loads below 80% the system using the new governor achieves the same performance and consumes much less energy at the same time (up to around 30% less which translates to around 100 W of power in this particular test setup). Again, the question here is whether or not anyone has anything against queuing this series up for 4.7 early in the cycle (preferably right after the closing of the 4.6 merge window) in order to provide a convenient base for further development. Of course, ACKs are welcome in case of no objections. :-) Thanks, Rafael
[PATCH v3 2/3] crypto: s5p-sss - Handle unaligned buffers
From: Krzysztof Kozlowski
During crypto selftests on Odroid XU3 (Exynos5422) some of the
algorithms failed because of passing AES-block unaligned source and
destination buffers:
alg: skcipher: encryption failed on chunk test 1 for ecb-aes-s5p: ret=22
Handle such case by copying the buffers to a new aligned and contiguous
space.
Signed-off-by: Krzysztof Kozlowski
Acked-by: Vladimir Zapolskiy
---
Changes since v2:
1. Fix infinite loop in s5p_is_sg_aligned().
Changes since v1:
1. Add Vladimir's acked-by.
Driver tested on Exynos4412/Trats2 and Exynos5422/Odroid XU4 with crypto
manager self-tests and tcrypt:
$ modprobe tcrypt sec=1 mode=500
---
drivers/crypto/s5p-sss.c | 150 +++
1 file changed, 138 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 60f835455a41..3730fb0af4d8 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#define _SBF(s, v) ((v) << (s))
#define _BIT(b) _SBF(b, 1)
@@ -185,6 +186,10 @@ struct s5p_aes_dev {
struct scatterlist *sg_src;
struct scatterlist *sg_dst;
+ /* In case of unaligned access: */
+ struct scatterlist *sg_src_cpy;
+ struct scatterlist *sg_dst_cpy;
+
struct tasklet_struct tasklet;
struct crypto_queue queue;
boolbusy;
@@ -244,8 +249,45 @@ static void s5p_set_dma_outdata(struct s5p_aes_dev *dev,
struct scatterlist *sg)
SSS_WRITE(dev, FCBTDMAL, sg_dma_len(sg));
}
+static void s5p_free_sg_cpy(struct s5p_aes_dev *dev, struct scatterlist **sg)
+{
+ int len;
+
+ if (!*sg)
+ return;
+
+ len = ALIGN(dev->req->nbytes, AES_BLOCK_SIZE);
+ free_pages((unsigned long)sg_virt(*sg), get_order(len));
+
+ kfree(*sg);
+ *sg = NULL;
+}
+
+static void s5p_sg_copy_buf(void *buf, struct scatterlist *sg,
+ unsigned int nbytes, int out)
+{
+ struct scatter_walk walk;
+
+ if (!nbytes)
+ return;
+
+ scatterwalk_start(&walk, sg);
+ scatterwalk_copychunks(buf, &walk, nbytes, out);
+ scatterwalk_done(&walk, out, 0);
+}
+
static void s5p_aes_complete(struct s5p_aes_dev *dev, int err)
{
+ if (dev->sg_dst_cpy) {
+ dev_dbg(dev->dev,
+ "Copying %d bytes of output data back to original
place\n",
+ dev->req->nbytes);
+ s5p_sg_copy_buf(sg_virt(dev->sg_dst_cpy), dev->req->dst,
+ dev->req->nbytes, 1);
+ }
+ s5p_free_sg_cpy(dev, &dev->sg_src_cpy);
+ s5p_free_sg_cpy(dev, &dev->sg_dst_cpy);
+
/* holding a lock outside */
dev->req->base.complete(&dev->req->base, err);
dev->busy = false;
@@ -261,14 +303,36 @@ static void s5p_unset_indata(struct s5p_aes_dev *dev)
dma_unmap_sg(dev->dev, dev->sg_src, 1, DMA_TO_DEVICE);
}
+static int s5p_make_sg_cpy(struct s5p_aes_dev *dev, struct scatterlist *src,
+ struct scatterlist **dst)
+{
+ void *pages;
+ int len;
+
+ *dst = kmalloc(sizeof(**dst), GFP_ATOMIC);
+ if (!*dst)
+ return -ENOMEM;
+
+ len = ALIGN(dev->req->nbytes, AES_BLOCK_SIZE);
+ pages = (void *)__get_free_pages(GFP_ATOMIC, get_order(len));
+ if (!pages) {
+ kfree(*dst);
+ *dst = NULL;
+ return -ENOMEM;
+ }
+
+ s5p_sg_copy_buf(pages, src, dev->req->nbytes, 0);
+
+ sg_init_table(*dst, 1);
+ sg_set_buf(*dst, pages, len);
+
+ return 0;
+}
+
static int s5p_set_outdata(struct s5p_aes_dev *dev, struct scatterlist *sg)
{
int err;
- if (!IS_ALIGNED(sg_dma_len(sg), AES_BLOCK_SIZE)) {
- err = -EINVAL;
- goto exit;
- }
if (!sg_dma_len(sg)) {
err = -EINVAL;
goto exit;
@@ -291,10 +355,6 @@ static int s5p_set_indata(struct s5p_aes_dev *dev, struct
scatterlist *sg)
{
int err;
- if (!IS_ALIGNED(sg_dma_len(sg), AES_BLOCK_SIZE)) {
- err = -EINVAL;
- goto exit;
- }
if (!sg_dma_len(sg)) {
err = -EINVAL;
goto exit;
@@ -394,6 +454,71 @@ static void s5p_set_aes(struct s5p_aes_dev *dev,
memcpy_toio(keystart, key, keylen);
}
+static bool s5p_is_sg_aligned(struct scatterlist *sg)
+{
+ while (sg) {
+ if (!IS_ALIGNED(sg_dma_len(sg), AES_BLOCK_SIZE))
+ return false;
+ sg = sg_next(sg);
+ }
+
+ return true;
+}
+
+static int s5p_set_indata_start(struct s5p_aes_dev *dev,
+ struct ablkcipher_request *req)
+{
+ struct scatterlist *sg;
+ int err;
+
+
[PATCH v3 3/3] crypto: s5p-sss - Sort the headers to improve readability
Sort the headers alphabetically to improve readability and to spot duplications easier. Suggested-by: Vladimir Zapolskiy Signed-off-by: Krzysztof Kozlowski Acked-by: Vladimir Zapolskiy --- Changes since v2: 1. Add Vladimir's acked-by. Changes since v1: 1. New patch. My email differs from one used in previous patches because this time I am sending this from work. --- drivers/crypto/s5p-sss.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c index 3730fb0af4d8..4f6d5b3ec418 100644 --- a/drivers/crypto/s5p-sss.c +++ b/drivers/crypto/s5p-sss.c @@ -11,23 +11,23 @@ * */ +#include +#include +#include #include -#include -#include #include +#include +#include +#include #include -#include +#include +#include #include #include -#include -#include -#include -#include -#include -#include -#include #include +#include +#include #include #define _SBF(s, v) ((v) << (s)) -- 2.5.0
[PATCH v6 3/7][Resend] cpufreq: governor: Move abstract gov_attr_set code to seperate file
From: Rafael J. Wysocki
Move abstract code related to struct gov_attr_set to a separate (new)
file so it can be shared with (future) goverernors that won't share
more code with "ondemand" and "conservative".
No intentional functional changes.
Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
---
No changes from previous versions.
---
drivers/cpufreq/Kconfig |4 +
drivers/cpufreq/Makefile|1
drivers/cpufreq/cpufreq_governor.c | 82 ---
drivers/cpufreq/cpufreq_governor.h |6 ++
drivers/cpufreq/cpufreq_governor_attr_set.c | 84
5 files changed, 95 insertions(+), 82 deletions(-)
Index: linux-pm/drivers/cpufreq/Kconfig
===
--- linux-pm.orig/drivers/cpufreq/Kconfig
+++ linux-pm/drivers/cpufreq/Kconfig
@@ -18,7 +18,11 @@ config CPU_FREQ
if CPU_FREQ
+config CPU_FREQ_GOV_ATTR_SET
+ bool
+
config CPU_FREQ_GOV_COMMON
+ select CPU_FREQ_GOV_ATTR_SET
select IRQ_WORK
bool
Index: linux-pm/drivers/cpufreq/Makefile
===
--- linux-pm.orig/drivers/cpufreq/Makefile
+++ linux-pm/drivers/cpufreq/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_CPU_FREQ_GOV_USERSPACE) +=
obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND)+= cpufreq_ondemand.o
obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE)+= cpufreq_conservative.o
obj-$(CONFIG_CPU_FREQ_GOV_COMMON) += cpufreq_governor.o
+obj-$(CONFIG_CPU_FREQ_GOV_ATTR_SET)+= cpufreq_governor_attr_set.o
obj-$(CONFIG_CPUFREQ_DT) += cpufreq-dt.o
Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -112,53 +112,6 @@ void gov_update_cpu_data(struct dbs_data
}
EXPORT_SYMBOL_GPL(gov_update_cpu_data);
-static inline struct gov_attr_set *to_gov_attr_set(struct kobject *kobj)
-{
- return container_of(kobj, struct gov_attr_set, kobj);
-}
-
-static inline struct governor_attr *to_gov_attr(struct attribute *attr)
-{
- return container_of(attr, struct governor_attr, attr);
-}
-
-static ssize_t governor_show(struct kobject *kobj, struct attribute *attr,
-char *buf)
-{
- struct governor_attr *gattr = to_gov_attr(attr);
-
- return gattr->show(to_gov_attr_set(kobj), buf);
-}
-
-static ssize_t governor_store(struct kobject *kobj, struct attribute *attr,
- const char *buf, size_t count)
-{
- struct gov_attr_set *attr_set = to_gov_attr_set(kobj);
- struct governor_attr *gattr = to_gov_attr(attr);
- int ret = -EBUSY;
-
- mutex_lock(&attr_set->update_lock);
-
- if (attr_set->usage_count)
- ret = gattr->store(attr_set, buf, count);
-
- mutex_unlock(&attr_set->update_lock);
-
- return ret;
-}
-
-/*
- * Sysfs Ops for accessing governor attributes.
- *
- * All show/store invocations for governor specific sysfs attributes, will
first
- * call the below show/store callbacks and the attribute specific callback will
- * be called from within it.
- */
-static const struct sysfs_ops governor_sysfs_ops = {
- .show = governor_show,
- .store = governor_store,
-};
-
unsigned int dbs_update(struct cpufreq_policy *policy)
{
struct policy_dbs_info *policy_dbs = policy->governor_data;
@@ -425,41 +378,6 @@ static void free_policy_dbs_info(struct
gov->free(policy_dbs);
}
-static void gov_attr_set_init(struct gov_attr_set *attr_set,
- struct list_head *list_node)
-{
- INIT_LIST_HEAD(&attr_set->policy_list);
- mutex_init(&attr_set->update_lock);
- attr_set->usage_count = 1;
- list_add(list_node, &attr_set->policy_list);
-}
-
-static void gov_attr_set_get(struct gov_attr_set *attr_set,
-struct list_head *list_node)
-{
- mutex_lock(&attr_set->update_lock);
- attr_set->usage_count++;
- list_add(list_node, &attr_set->policy_list);
- mutex_unlock(&attr_set->update_lock);
-}
-
-static unsigned int gov_attr_set_put(struct gov_attr_set *attr_set,
-struct list_head *list_node)
-{
- unsigned int count;
-
- mutex_lock(&attr_set->update_lock);
- list_del(list_node);
- count = --attr_set->usage_count;
- mutex_unlock(&attr_set->update_lock);
- if (count)
- return count;
-
- kobject_put(&attr_set->kobj);
- mutex_destroy(&attr_set->update_lock);
- return 0;
-}
-
static int cpufreq_governor_init(struct cpufreq_policy *policy)
{
struct dbs_governor *gov = dbs_governor_of(policy);
Index: linux-pm/drivers/cpufreq/cpufreq_governor.h
[PATCH v3 1/3] crypto: s5p-sss - Minor coding cleanups
From: Krzysztof Kozlowski Remove unneeded inclusion of delay.h and get rid of indentation from labels. Signed-off-by: Krzysztof Kozlowski Acked-by: Vladimir Zapolskiy --- Changes since v2: 1. None. Changes since v1: 1. Add Vladimir's acked-by. --- drivers/crypto/s5p-sss.c | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c index 5f161a9777e3..60f835455a41 100644 --- a/drivers/crypto/s5p-sss.c +++ b/drivers/crypto/s5p-sss.c @@ -11,7 +11,6 @@ * */ -#include #include #include #include @@ -284,7 +283,7 @@ static int s5p_set_outdata(struct s5p_aes_dev *dev, struct scatterlist *sg) dev->sg_dst = sg; err = 0; - exit: +exit: return err; } @@ -310,7 +309,7 @@ static int s5p_set_indata(struct s5p_aes_dev *dev, struct scatterlist *sg) dev->sg_src = sg; err = 0; - exit: +exit: return err; } @@ -452,10 +451,10 @@ static void s5p_aes_crypt_start(struct s5p_aes_dev *dev, unsigned long mode) return; - outdata_error: +outdata_error: s5p_unset_indata(dev); - indata_error: +indata_error: s5p_aes_complete(dev, err); spin_unlock_irqrestore(&dev->lock, flags); } @@ -506,7 +505,7 @@ static int s5p_aes_handle_req(struct s5p_aes_dev *dev, tasklet_schedule(&dev->tasklet); - exit: +exit: return err; } @@ -705,7 +704,7 @@ static int s5p_aes_probe(struct platform_device *pdev) return 0; - err_algs: +err_algs: dev_err(dev, "can't register '%s': %d\n", algs[i].cra_name, err); for (j = 0; j < i; j++) @@ -713,7 +712,7 @@ static int s5p_aes_probe(struct platform_device *pdev) tasklet_kill(&pdata->tasklet); - err_irq: +err_irq: clk_disable_unprepare(pdata->clk); s5p_dev = NULL; -- 2.5.0
[PATCH 1/2] ARM: dts: exynos: Add Security SubSystem node to Exynos4
Add Security SubSystem (SSS) node to Exynos4 which provides hardware
acceleration of AES operations.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index c679b3cc3c48..39000f9c6b86 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -969,6 +969,15 @@
#iommu-cells = <0>;
};
+ sss: sss@1083 {
+ compatible = "samsung,exynos4210-secss";
+ reg = <0x1083 0x300>;
+ interrupts = <0 112 0>;
+ clocks = <&clock CLK_SSS>;
+ clock-names = "secss";
+ status = "disabled";
+ };
+
prng: rng@10830400 {
compatible = "samsung,exynos4-rng";
reg = <0x10830400 0x200>;
--
2.5.0
[PATCH 2/2] ARM: dts: exynos: Enable SSS on Trats2
Enable the Security SubSystem (SSS) on Trats2 (Exynos4412) board which
allows usage of its hardware accelerated AES operations.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-trats2.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index ed017cc7b14f..2bf363c3bf62 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -1286,6 +1286,10 @@
};
};
+&sss {
+ status = "okay";
+};
+
&tmu {
vtmu-supply = <&ldo10_reg>;
status = "okay";
--
2.5.0
Re: [PATCH] Staging: wlan-ng: moved memset() calls after copy_from_user() call
On Tue, Mar 15, 2016 at 09:53:15PM +0200, Claudiu Beznea wrote: > This patch moves memset() calls from p80211netdev_ethtool() > after copy_from_user() call in order to avoid unnecessary > instruction in case copy_from_user() fails. Does that really matter? If an error happens, then we are on a "slow path" and the extra memset didn't matter at all. Don't move code around for no good reason, and if you think it makes things faster, then you have to be able to prove it somehow :) thanks, greg k-h
Re: [PATCH] Staging: wlan-ng: removed "goto " instructions where this is not necessary.
On Mon, Mar 21, 2016 at 12:29:01AM +0200, Claudiu Beznea wrote: > This patch removes "goto " instructions which do only > a return. In this way, aditional instructions were removed. But this is now harder to read and understand, why make this change for no good reason? thanks, greg k-h
Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER
Hi Doug,
On 2016/3/22 7:33, Doug Anderson wrote:
Shawn,
On Wed, Mar 9, 2016 at 12:11 AM, Shawn Lin wrote:
Let's defer probing the driver if the return value of
dma_request_slave_channel is ERR_PTR(-EPROBE_DEFER) instead
of disabling dma capability directly.
Signed-off-by: Shawn Lin
---
drivers/spi/spi-rockchip.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index ca4f4e0..75fa990 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -737,8 +737,14 @@ static int rockchip_spi_probe(struct platform_device *pdev)
master->handle_err = rockchip_spi_handle_err;
rs->dma_tx.ch = dma_request_slave_channel(rs->dev, "tx");
- if (!rs->dma_tx.ch)
+ if (IS_ERR_OR_NULL(rs->dma_tx.ch)) {
+ /* Check tx to see if we need defer probing driver */
+ if (PTR_ERR(rs->dma_tx.ch) == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto err_get_fifo_len;
+ }
dev_warn(rs->dev, "Failed to request TX DMA channel\n");
Presumably Dan would be happy if you just add this right after the dev_warn():
rs->dma_tx.ch = NULL;
Presumably from Dan's email it would also be wise to make sure you
don't pass NULL to PTR_ERR, which you could probably do by just using
ERR_PTR instead of PTR_ERR. I think you could structure like this:
rs->dma_tx.ch = dma_request_slave_channel(rs->dev, "tx");
- if (!rs->dma_tx.ch)
+ if (IS_ERR_OR_NULL(rs->dma_tx.ch)) {
+ /* Check tx to see if we need defer probing driver */
+ if (rs->dma_tx.ch == ERR_PTR(-EPROBE_DEFER)) {
+ ret = -EPROBE_DEFER;
+ goto err_get_fifo_len;
+ }
dev_warn(rs->dev, "Failed to request TX DMA channel\n");
+ rs->dma_tx.ch = NULL;
+ }
With that change your patch should be happy, I think. If some new
unknown error return gets added to dma_request_slave_channel() then
your code will continue to work properly. Such a change is simple and
safe, so presumably you could just spin your patch with that fix.
Although unlikely, it's probably good to check for IS_ERR_OR_NULL()
when requesting the "rx" channel too.
Thanks for reminding it. I was planing to fix it, so give me a little
more time. :)
...but, looking at this, presumably before landing any patch that made
dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify
_all_ users of dma_request_slave_channel to handle error pointers
being returned. Right now dma_request_slave_channel() says it returns
a pointer to a channel or NULL and the function explicitly avoids
returning any errors. That might be possible, but it's a big
change...
At first glance, it's a big change, but maybe not really.
Almost all of them use the templet like:
ch = dma_request_slave_channel
if (!ch)
balabala
It's same for all the non-null return pointer/non-zero value ?
So from my view, we can safely change dma_request_slave_channel,
and leave the caller here. I presumably the respective
drivers will graduately migrate to check the return value with
EPROBE_DEFER if they do care this issue. Otherwise, we believe
they don't suffer the changes we make, just as what they did in the
past. Does that make sense?
-Doug
--
Best Regards
Shawn Lin
Re: [PATCH] Security: Keys: Added derived keytype
Hi Kirill,
[auto build test WARNING on v4.5-rc7]
[also build test WARNING on next-20160321]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Kirill-Marinushkin/Security-Keys-Added-derived-keytype/20160322-084809
config: sparc64-allyesconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All warnings (new ones prefixed by >>):
security/keys/derived.c: In function 'parse_options':
>> security/keys/derived.c:217:15: warning: assignment from incompatible
>> pointer type
usalt.lenp = &payload->saltlen;
^
vim +217 security/keys/derived.c
201 switch (token) {
202
203 case OPT_SHORT_SALT: /* salt */
204 case OPT_LONG_SALT:
205 templen = args[0].to - args[0].from;
206 if (templen < 0 || templen > SALT_MAX_SIZE) {
207 pr_err(PREFIX "invalid salt length");
208 return -EINVAL;
209 }
210 payload->salt = kstrndup(args[0].from, templen,
GFP_KERNEL);
211 if (!payload->salt) {
212 pr_err(PREFIX "salt alloc failed");
213 return -ENOMEM;
214 }
215 payload->saltlen = templen;
216 usalt.data = payload->salt;
> 217 usalt.lenp = &payload->saltlen;
218 break;
219
220 case OPT_SHORT_ITER: /* iterations */
221 case OPT_LONG_ITER:
222 if (kstrtou64(args[0].from, 0, &tempul)
223 || tempul == 0
224 || tempul > ITER_MAX_VAL) {
225 pr_err(PREFIX "invalid iterations
number");
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH] Staging: rtl8192e: Fix warning exceeding characters per line
On Sat, Mar 12, 2016 at 04:01:03PM +0100, Adonis Settouf wrote:
> This patch fixes the checkpatch.pl warning regarding the exceeding 80
> characters on line 36. This patch add a newline after function statement
> on line 52
You did 2 different things in the same patch, that should be 2 patches.
>
> Signed-off-by: Adonis Settouf
> ---
> drivers/staging/rtl8192e/dot11d.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/dot11d.h
> b/drivers/staging/rtl8192e/dot11d.h
> index 735a199..5cffc8f 100644
> --- a/drivers/staging/rtl8192e/dot11d.h
> +++ b/drivers/staging/rtl8192e/dot11d.h
> @@ -30,8 +30,8 @@ enum dot11d_state {
> };
>
> /**
> - * struct rt_dot11d_info * @CountryIeLen: value greater than 0 if
> @CountryIeBuf contains
> - * valid country information element.
> + * struct rt_dot11d_info * @CountryIeLen: value greater than 0 if
> + * @CountryIeBuf contains valid country information element.
You forgot to indent like the rest of this comment block did :(
Re: [PATCH] staging: rtl8192e: fixed coding style issues
On Thu, Mar 17, 2016 at 04:55:37PM +, Yousof El-Sayed wrote: > Signed-off-by: Yousof El-Sayed I can't take a patch with no changelog entry. And your subject is too vague as well :( greg k-h
Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async
On Mon, Mar 21, 2016 at 06:28:48PM +0900, Sergey Senozhatsky wrote: > > Just to be sure, whether you take my suggestion or not is not important. > > I just suggested it in this thread since it can solve what you worried > > about. That's all. I can post it in another thread though. Why don't you > > consider it so that yours don't miss any printk message? Do you think there > > are any problems in my suggestion? > > we have 2 spin locks in vprintk_emit() -- logbuf_lock and sem->lock. and N > CPUs can concurrently lockup on those two locks, which already makes a > single static pointer in spiun_dump() questionable. As I already said, the static pointer is for an infinite recursion within a printk() in the case "lockup suspected". It can prevent at least meaningless *infinite* recursion at the first place the recursion occured. Once the single static variable works, that is, it solves the recursion, the next recusion can be solved if it exists, that is, more than two locks are locked-up. It will be helpful for understanding what I am saying if you think about how the infinite recursion can happen. So a single static variable is enough to prevent a *infinite* recursion. CPU0CPU1 spin_lock(A)printk() (not release A)spin_lock(A) spin_dump() // lockup suspected printk() spint_lock(A) ... where A can be logbuf_lock, sem->lock, rq->lock, p->pi_lock or any lock which is used within printk(). For your information, logbuf_lock can also cause an infinite recursion at the first entrance on a CPU. > logbug_lock *theoretically* can detect and handle recursive printk()s, > there is no way to catch sem->lock spin_dump() at the moment (but that's > not the point). It's the reason why I suggested the way to avoid an inifinit recursion in the spin debug facitity in the case "lockup suspected". > there are 2 new spin locks in vprintk_emit() -- p->pi_lock and rq->lock. > what I want is to put those locks inside the "we can detect recursion 100%" > region. so these two locks will not add any new possibilities of recursive > printks, they are covered by the existing recursion detection code thanks > to logbuf lock and static logbuf_cpu. so we still can say that we have 5 I think, even though we can detect the recursion by the logbuf_cpu, we should not use it for the purpose of detecting since it's the last resort preventing an infinite recursion. It seems to be same, it's different purpose. Now you decided to put it out of the critical section, this arguing is not much important though.. :-( > places where printk recursion can happen > > -- lock + unlock logbuf_lock >printk() recursion detection code can't help here > > -- inside of logbuf_lock critical section >printk() recursion detection code works here > > -- lock + unlock sem->lock >printk() recursion detection code can't help here > > > note how "inside of logbuf_lock critical section" takes care of nested > 'lock + unlock p->pi_lock' and 'lock + unlock rq->lock'. I got what you intended to do. You don't need to explain in more detail. > moreover, printk() will switch to synchronous mode in recursion handler and > two misbehaving spin locks (4 places where recursion can happen) will not be > executed anymore. This, too. > what you want to have -- 4 independent spin locks and 9 places where > recursion can happen, only 1 of which is covered by printk recursion code. > > -- lock + unlock logbuf_lock >printk() recursion detection code can't help here > > -- inside of logbuf_lock critical section >printk() recursion detection code works here > > -- lock + unlock p->pi_lock >printk() recursion detection code can't help here > > -- lock + unlock rq->lock >printk() recursion detection code can't help here > > -- lock + unlock sem->lock >printk() recursion detection code can't help here > > and there is a static pointer to fix everything up? what if 2 We can use a single static pointer to fix it as I said. > CPUs will simultaneously printk-recurse in 2 different places? As I said, 2 different places mean 2 different timings, in the case of infinite recursion. I think I explained fully. Do I need to explain more? Thanks, Byungchul > why this is better? > > -ss
Re: [RFC PATCH v1 0/4] Add Rockchip RGA support
Hi Heiko, On 03/22/2016 08:42 AM, Heiko Stuebner wrote: Hi Yakir, Am Montag, 21. März 2016, 20:17:46 schrieb Yakir Yang: On 03/21/2016 07:29 PM, Heiko Stübner wrote: Am Montag, 21. März 2016, 17:28:38 schrieb Yakir Yang: This patch set would add the RGA direct rendering based 2d graphics acceleration module. very cool to see that. ;) This patch set is based on git repository below: git://people.freedesktop.org/~airlied/linux drm-next commit id: 568d7c764ae01f3706085ac8f0d8a8ac7e826bd7 And the RGA driver is based on Exynos G2D driver, it only manages the command lists received from user, so user should make the command list to data and registers needed by operation to use. I have prepared an userspace demo application for testing: https://github.com/yakir-Yang/libdrm-rockchip That is a rockchip libdrm library, and I have write a simple test case "rockchip_rga_test" that would test the below RGA features: - solid - copy - rotation - flip - window clip - dithering Did you submit your libdrm changes as well? Userspace-interfaces need to be stable so the other side must also get accepted - even before the kernel change if I remember correctly. Got it, and I just saw exynos_fimg2d already landed at mainline libdrm. But I don't find the way to submit patches to libdrm, would you like share some helps here ;) Looking at the libdrm sources on cgit.freedesktop.org, I did not find any specific manual on submitting patches. But looking at the dri-list archive, dri-de...@lists.freedesktop.org is the right list and looking at the libdrm history it looks like Emil Velikov seems to be doing maintenance-stuff in libdrm. And as a 3rd recipient, please also include the linux-rockchip list. Great, thanks, I would improve my libdrm changes, and submit them soon :) - Yakir @Emil, please shout if I read that wrong :-) Hope that helps Heiko
Re: [GIT PULL] Btrfs
On Mon, Mar 21, 2016 at 06:16:54PM -0700, Linus Torvalds wrote:
> On Mon, Mar 21, 2016 at 5:24 PM, Chris Mason wrote:
> >
> > I waited an extra day to send this one out because I hit a crash late
> > last week with CONFIG_DEBUG_PAGEALLOC enabled (fixed in the top commit).
>
> Hmm. If that commit helps, it will spit out a warning.
>
> So is it actually fixed, or just hacked around to the point where you
> don't get a page fault?
>
> That WARN_ON_ONCE kind of implies it's a "this happens, but we don't know
> why".
Hi Linus,
while (bio_index < bio->bi_vcnt) {
count = find some crcs
...
while (count--) {
...
page_bytes_left -= root->sectorsize;
if (!page_bytes_left) {
bio_index++;
/*
* make sure we're still inside the
* bio before we update page_bytes_left
*/
if (bio_index >= bio->bi_vcnt) {
WARN_ON_ONCE(count);
goto done;
}
bvec++;
page_bytes_left = bvec->bv_len;
^ this was the line that crashed
before
}
}
}
done:
cleanup;
return;
What should be happening here is we'll goto done when count is zero and
we've walked past the end of the bio. IOW, both the outer and inner
loops are doing the right tests and the right math, but the inner loop
is improperly accessing a bogus bvec->bv_len because it didn't realize
the outer loop was now completely done.
I don't see a way for it to happen when count != 0, and I ran xfstests
on a few machines to try and triple check that. If there are new bugs
hiding here, we'll have EIOs returned up to userland because this
function didn't properly fetch the crcs. If anyone reported the EIOs,
they would send in the WARN_ON output too, so we'd know right away not
to blame their hardware.
I also ran for days with heavy read/write loads without seeing the crc
errors. I didn't have the WARN_ON, or CONFIG_DEBUG_PAGEALLOC on that
box, but if other things were wrong, we'd have done a lot worse than poke
into bvec->bv_len, and the crc errors would have stopped the test.
-chris
Re: [Ocfs2-devel] [PATCH v4 2/5] ocfs2: sysfile interfaces for online file check
Hello Mark and Andrew, Thank for taking the time in reviewing the patches, move the thing forward. Thanks Gang >>> > On Mon, 21 Mar 2016 16:38:02 -0700 Mark Fasheh wrote: > >> On Mon, Mar 21, 2016 at 04:05:47PM -0700, Andrew Morton wrote: >> > On Mon, 21 Mar 2016 15:57:23 -0700 Mark Fasheh wrote: >> > >> > > On Mon, Feb 29, 2016 at 01:17:59PM +0800, Gang He wrote: >> > > > Implement online file check sysfile interfaces, e.g. >> > > > how to create the related sysfile according to device name, >> > > > how to display/handle file check request from the sysfile. >> > > > >> > > > Signed-off-by: Gang He >> > > Reviewed-by: Mark Fasheh >> > >> > Thanks. So all of >> > >> > ocfs2-export-ocfs2_kset-for-online-file-check.patch >> > ocfs2-sysfile-interfaces-for-online-file-check.patch >> > ocfs2-sysfile-interfaces-for-online-file-check-v4.patch >> > ocfs2-create-remove-sysfile-for-online-file-check.patch >> > ocfs2-check-fix-inode-block-for-online-file-check.patch >> > ocfs2-check-fix-inode-block-for-online-file-check-v4.patch >> > ocfs2-add-feature-document-for-online-file-check.patch >> > >> > have your reviewed-by. I'll send them on to Linus. >> >> I'm curious, are the '-V4' patches built on top of the non '-V4' versions? > > yes, the -v4 patches bring the base patch from > whatever-version-i-originally-merged up to v4. > >> Otherwise though this generally sounds good to me - I have reviewed the >> entire online fsck patch series. > > Cool. > > ___ > Ocfs2-devel mailing list > ocfs2-de...@oss.oracle.com > https://oss.oracle.com/mailman/listinfo/ocfs2-devel
Re: [PATCH] staging: rts5208: coding style clean-ups
On Mon, Mar 21, 2016 at 05:29:24PM -0400, Greg KH wrote: > On Mon, Mar 21, 2016 at 10:53:36PM +0530, Sohom Bhattacharjee wrote: > > fixed *only* comments that did not follow kernel coding style. > > the errors were caught by the checkpatch.pl tool > > > > Signed-off-by: Sohom Bhattacharjee > > Does not apply to the tree at all :( what do you mean ? i used the Linus's latest git tree. :) thanks, sohom b
Re: [kbuild-all] arch/xtensa/include/asm/initialize_mmu.h:55: Error: invalid register 'atomctl' for 'wsr' instruction
Hi Max, Thank you for the info! CC Philip for following this issue. Thanks, Fengguang On Sun, Mar 20, 2016 at 02:54:54PM +0300, Max Filippov wrote: > Hi Fengguang, > > On Sun, Mar 20, 2016 at 8:34 AM, kbuild test robot > wrote: > > Hi Max, > > > > FYI, the error/warning still remains. > > Each xtensa core configuration requires corresponding toolchain to be > built correctly. > In this case the toolchain needs to be built for de212 core with the > following overlay: > > https://github.com/jcmvbkbc/xtensa-toolchain-build/blob/master/overlays/xtensa_de212.tar.gz > > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > master > > head: 1e75a9f34a5ed5902707fb74b468356c55142b71 > > commit: ca55b2fef3a9373fcfc30f82fd26bc7fccbda732 xtensa: add de212 core > > variant > > date: 5 months ago > > config: xtensa-nommu_kc705_defconfig (attached as .config) > > reproduce: > > wget > > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > > -O ~/bin/make.cross > > chmod +x ~/bin/make.cross > > git checkout ca55b2fef3a9373fcfc30f82fd26bc7fccbda732 > > # save the attached .config to linux build tree > > make.cross ARCH=xtensa > > > > All errors (new ones prefixed by >>): > > > >arch/xtensa/include/asm/initialize_mmu.h: Assembler messages: > >>> arch/xtensa/include/asm/initialize_mmu.h:55: Error: invalid register > >>> 'atomctl' for 'wsr' instruction > > > > vim +55 arch/xtensa/include/asm/initialize_mmu.h > > > > 6cb97111 Baruch Siach 2013-12-29 39 > > c622b29d Max Filippov 2012-11-19 40 #ifdef __ASSEMBLY__ > > c622b29d Max Filippov 2012-11-19 41 > > c622b29d Max Filippov 2012-11-19 42 #define XTENSA_HWVERSION_RC_2009_0 > > 23 > > c622b29d Max Filippov 2012-11-19 43 > > c622b29d Max Filippov 2012-11-19 44.macro initialize_mmu > > c622b29d Max Filippov 2012-11-19 45 > > c622b29d Max Filippov 2012-11-19 46 #if XCHAL_HAVE_S32C1I && > > (XCHAL_HW_MIN_VERSION >= XTENSA_HWVERSION_RC_2009_0) > > c622b29d Max Filippov 2012-11-19 47 /* > > c622b29d Max Filippov 2012-11-19 48 * We Have Atomic Operation Control > > (ATOMCTL) Register; Initialize it. > > c622b29d Max Filippov 2012-11-19 49 * For details see > > Documentation/xtensa/atomctl.txt > > c622b29d Max Filippov 2012-11-19 50 */ > > c622b29d Max Filippov 2012-11-19 51 #if XCHAL_DCACHE_IS_COHERENT > > c622b29d Max Filippov 2012-11-19 52movia3, 0x25/* For > > SMP/MX -- internal for writeback, > > c622b29d Max Filippov 2012-11-19 53 * RCW > > otherwise > > c622b29d Max Filippov 2012-11-19 54 */ > > c622b29d Max Filippov 2012-11-19 @55 #else > > c622b29d Max Filippov 2012-11-19 56movia3, 0x29/* non-MX > > -- Most cores use Std Memory > > c622b29d Max Filippov 2012-11-19 57 * > > Controlers which usually can't use RCW > > c622b29d Max Filippov 2012-11-19 58 */ > > c622b29d Max Filippov 2012-11-19 59 #endif > > c622b29d Max Filippov 2012-11-19 60wsr a3, atomctl > > c622b29d Max Filippov 2012-11-19 61 #endif /* XCHAL_HAVE_S32C1I && > > c622b29d Max Filippov 2012-11-19 62 * (XCHAL_HW_MIN_VERSION >= > > XTENSA_HWVERSION_RC_2009_0) > > c622b29d Max Filippov 2012-11-19 63 */ > > > > :: The code at line 55 was first introduced by commit > > :: c622b29d1f38021411965b7e0170ab01b257 xtensa: initialize atomctl > > SR > > > > :: TO: Max Filippov > > :: CC: Chris Zankel > > > > --- > > 0-DAY kernel test infrastructureOpen Source Technology > > Center > > https://lists.01.org/pipermail/kbuild-all Intel > > Corporation > > > > -- > Thanks. > -- Max > ___ > kbuild-all mailing list > kbuild-...@lists.01.org > https://lists.01.org/mailman/listinfo/kbuild-all
Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async
On Tue, Mar 22, 2016 at 02:11:05AM +0900, Sergey Senozhatsky wrote: > On (03/21/16 16:33), Jan Kara wrote: > [..] > > > > And by calling wake_up_process() under logbuf_lock, you actually > > > > introduce > > > > recursion issues for printk_deferred() messages which are supposed to be > > > > working from under rq->lock and similar. So I think you have to keep > > > > this > > > > section outside of logbuf_lock. > > > > > > hm, in_sched (printk_deferred()) messages are printed by > > > irq work->wake_up_klogd_work_func(), not by wake_up_process() > > > from vprintk_emit(). or am I missing something? > > > > Think of following: > > > > some function > > printk() > > vprintk_emit() > > spin_lock(&logbuf_lock); > > ... > > wake_up_process() > > printk_deferred() > > vprintk_emit() -> recursion on logbuf_lock > > uh, indeed. I was more concerned about printk() calls that are > troublemakers and are already in wake_up_process() - spin_dump()s. > but yes, braking printk_deferred() in this case is a regression. Already said any kind of printk() cannot work within logbuf_lock. :-( > thanks for pointing that out. and also thanks to Byungchul. My pleasure.
Re: [PATCH] x86: Avoid undefined behavior in macro expansion
On Fri, Mar 18, 2016 at 11:15 PM, Al Viro wrote: > On Wed, Mar 16, 2016 at 11:48:49PM -0300, Vinicius Tinti wrote: >> C11 standard (at 6.10.3.3) says that ## operator (paste) has undefined >> behavior when one of the result operands is not a valid preprocessing >> token. >> >> Therefore the macro expansion may depend on compiler implementation >> which may or no preserve the leading white space. >> >> Moreover other places in kernel use CONCAT(a,b) instead of CONCAT(a, b). >> Changing favors concise usage. > > Huh? > >> -#define XMM(i) CONCAT(%xmm, i) >> +#define XMM(i) CONCAT(%xmm,i) > > What are you talking about? Undefined behaviour is when the result of > concatenation of adjacent tokens is not a valid preprocessor token. > It says nothing about the either argument being a single token. Please check the example below otherwise it will be hard to explain. The problem is that _i_ can be a macro to be expanded too. And it can be a parameter for a _paste_ operator. // tricky code #define CONCAT(a,b)a##b #defineXMM(i)CONCAT(%xmm, i) .macro foo n x = XMM(\n) .endm _%xmm_ is not a problem but _i_ is. > In this case after the substitution of e.g. XMM(42) we get 3 tokens: > Punctuator[%] Identifier[xmm] Pp-number[42] > with ## instructing us to replace the last two with preprocessor token that > would be represented as concatenation of their representations. Which is > to say, concatenation of xmm and 42, i.e. xmm42. Which *is* a > representation of a valid preprocessor token - namely, Identifier[xmm42]. Agree. But it is not this case. I will add the code above at commit and describe it. It will be easy to explain what I am trying to solve. > No undefined behaviour at all. And yes, you get two preprocessor tokens > in the expansion - % and xmm42. Preprocessor works in terms of tokens, > not strings... Understood. > If you know of any compiler where these two variants would produce different > expansions of XMM(), please report it to maintainers of > the compiler in question; it's a bug, plain and simple. And no, there's > no undefined behaviour in that. I reported a bug and discussed over it and I too believe that the tricky code that I have just sent triggers an undefined behavior. What do you think? -- Simplicity is the ultimate sophistication
Re: [PATCH v2 14/18] mm/balloon: use general movable page feature into balloon
On Mon, Mar 21, 2016 at 04:29:55PM +0800, kbuild test robot wrote:
> Hi Minchan,
>
> [auto build test ERROR on next-20160318]
> [cannot apply to v4.5-rc7 v4.5-rc6 v4.5-rc5 v4.5]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improving the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Minchan-Kim/Support-non-lru-page-migration/20160321-143339
> config: x86_64-randconfig-x000-201612 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All error/warnings (new ones prefixed by >>):
>
>drivers/virtio/virtio_balloon.c: In function 'virtballoon_probe':
> >> drivers/virtio/virtio_balloon.c:578:15: error: 'balloon_mnt' undeclared
> >> (first use in this function)
> kern_unmount(balloon_mnt);
> ^
>drivers/virtio/virtio_balloon.c:578:15: note: each undeclared identifier
> is reported only once for each function it appears in
> >> drivers/virtio/virtio_balloon.c:579:1: warning: label 'out_free_vb'
> >> defined but not used [-Wunused-label]
> out_free_vb:
> ^
>
> vim +/balloon_mnt +578 drivers/virtio/virtio_balloon.c
>
>572
>573out_oom_notify:
>574vdev->config->del_vqs(vdev);
>575out_unmount:
>576if (vb->vb_dev_info.inode)
>577iput(vb->vb_dev_info.inode);
> > 578kern_unmount(balloon_mnt);
> > 579out_free_vb:
>580kfree(vb);
>581out:
>582return err;
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
Thanks, kbuild.
Fixed.
>From 7006a7ee62bb09273f96d8cb45c32e42453ab931 Mon Sep 17 00:00:00 2001
From: Minchan Kim
Date: Thu, 3 Mar 2016 14:28:45 +0900
Subject: [PATCH] mm/balloon: use general movable page feature into balloon
Now, VM has a feature to migrate non-lru movable pages so
balloon doesn't need custom migration hooks in migrate.c
and compact.c. Instead, this patch implements page->mapping
->{isolate|migrate|putback} functions.
With that, we could remove hooks for ballooning in general
migration functions and make balloon compaction simple.
Cc: virtualizat...@lists.linux-foundation.org
Cc: Rafael Aquini
Cc: Konstantin Khlebnikov
Signed-off-by: Gioh Kim
Signed-off-by: Minchan Kim
---
drivers/virtio/virtio_balloon.c| 53 ---
include/linux/balloon_compaction.h | 47 -
include/linux/page-flags.h | 52 +++
include/uapi/linux/magic.h | 1 +
mm/balloon_compaction.c| 101 -
mm/compaction.c| 7 ---
mm/migrate.c | 22 ++--
mm/vmscan.c| 2 +-
8 files changed, 116 insertions(+), 169 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 7b6d74f0c72f..0c16192d2684 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
/*
* Balloon device works in 4K page units. So each page is pointed to by
@@ -45,6 +46,10 @@ static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
module_param(oom_pages, int, S_IRUSR | S_IWUSR);
MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
+#ifdef CONFIG_BALLOON_COMPACTION
+static struct vfsmount *balloon_mnt;
+#endif
+
struct virtio_balloon {
struct virtio_device *vdev;
struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
@@ -482,10 +487,29 @@ static int virtballoon_migratepage(struct
balloon_dev_info *vb_dev_info,
mutex_unlock(&vb->balloon_lock);
+ ClearPageIsolated(page);
put_page(page); /* balloon reference */
return MIGRATEPAGE_SUCCESS;
}
+
+static struct dentry *balloon_mount(struct file_system_type *fs_type,
+ int flags, const char *dev_name, void *data)
+{
+ static const struct dentry_operations ops = {
+ .d_dname = simple_dname,
+ };
+
+ return mount_pseudo(fs_type, "balloon-kvm:", NULL, &ops,
+ BALLOON_KVM_MAGIC);
+}
+
+static struct file_system_type balloon_fs = {
+ .name = "balloon-kvm",
+ .mount = balloon_mount,
+ .kill_sb= kill_anon_super,
+};
+
#endif /* CONFIG_BALLOON_COMPACTION */
static int virtballoon_probe(struct virtio_device *vdev)
@@ -515,10 +539,6 @@ static int virtballoon_probe(struct virtio_device *vdev)
vb->vdev = vde
Re: [PATCH] locking/qrwlock: Allow multiple spinning readers
On 03/20/2016 06:43 AM, Peter Zijlstra wrote: We still have that starvation case in mutex, I would think that is far more important to fix. Peter, I am sorry that I let the mutex patch languish for a while. I will work on that next. Cheers, Longman
Re: [PATCH] zsmalloc: fix semicolon.cocci warnings
On Mon, Mar 21, 2016 at 05:48:25PM +0800, kbuild test robot wrote:
> mm/zsmalloc.c:1103:2-3: Unneeded semicolon
>
>
> Remove unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> CC: Minchan Kim
> Signed-off-by: Fengguang Wu
> ---
>
> zsmalloc.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -1100,7 +1100,7 @@ void unlock_zspage(struct page *first_pa
> VM_BUG_ON_PAGE(!PageLocked(cursor), cursor);
> if (cursor != locked_page)
> unlock_page(cursor);
> - };
> + }
> }
>
> static void free_zspage(struct zs_pool *pool, struct page *first_page)
Thanks.
Fixed.
>From bb46f8265b55228f31b8096bd1c13dd6e6ee1bc4 Mon Sep 17 00:00:00 2001
From: Minchan Kim
Date: Wed, 9 Mar 2016 09:37:57 +0900
Subject: [PATCH] zsmalloc: migrate tail pages in zspage
This patch enables tail page migration of zspage.
In this point, I tested zsmalloc regression with micro-benchmark
which does zs_malloc/map/unmap/zs_free for all size class
in every CPU(my system is 12) during 20 sec.
It shows 1% regression which is really small when we consider
the benefit of this feature and realworkload overhead(i.e.,
most overhead comes from compression).
Signed-off-by: Minchan Kim
---
mm/zsmalloc.c | 131 +++---
1 file changed, 115 insertions(+), 16 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 9b4b03d8f993..3f1d488633e1 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -551,6 +551,19 @@ static void set_zspage_mapping(struct page *first_page,
m->class = class_idx;
}
+static bool check_isolated_page(struct page *first_page)
+{
+ struct page *cursor;
+
+ for (cursor = first_page; cursor != NULL; cursor =
+ get_next_page(cursor)) {
+ if (PageIsolated(cursor))
+ return true;
+ }
+
+ return false;
+}
+
/*
* zsmalloc divides the pool into various size classes where each
* class maintains a list of zspages where each zspage is divided
@@ -1052,6 +1065,44 @@ void lock_zspage(struct page *first_page)
} while ((cursor = get_next_page(cursor)) != NULL);
}
+int trylock_zspage(struct page *first_page, struct page *locked_page)
+{
+ struct page *cursor, *fail;
+
+ VM_BUG_ON_PAGE(!is_first_page(first_page), first_page);
+
+ for (cursor = first_page; cursor != NULL; cursor =
+ get_next_page(cursor)) {
+ if (cursor != locked_page) {
+ if (!trylock_page(cursor)) {
+ fail = cursor;
+ goto unlock;
+ }
+ }
+ }
+
+ return 1;
+unlock:
+ for (cursor = first_page; cursor != fail; cursor =
+ get_next_page(cursor)) {
+ if (cursor != locked_page)
+ unlock_page(cursor);
+ }
+
+ return 0;
+}
+
+void unlock_zspage(struct page *first_page, struct page *locked_page)
+{
+ struct page *cursor = first_page;
+
+ for (; cursor != NULL; cursor = get_next_page(cursor)) {
+ VM_BUG_ON_PAGE(!PageLocked(cursor), cursor);
+ if (cursor != locked_page)
+ unlock_page(cursor);
+ }
+}
+
static void free_zspage(struct zs_pool *pool, struct page *first_page)
{
struct page *nextp, *tmp;
@@ -1090,16 +1141,17 @@ static void init_zspage(struct size_class *class,
struct page *first_page,
first_page->freelist = NULL;
INIT_LIST_HEAD(&first_page->lru);
set_zspage_inuse(first_page, 0);
- BUG_ON(!trylock_page(first_page));
- first_page->mapping = mapping;
- __SetPageMovable(first_page);
- unlock_page(first_page);
while (page) {
struct page *next_page;
struct link_free *link;
void *vaddr;
+ BUG_ON(!trylock_page(page));
+ page->mapping = mapping;
+ __SetPageMovable(page);
+ unlock_page(page);
+
vaddr = kmap_atomic(page);
link = (struct link_free *)vaddr + off / sizeof(*link);
@@ -1850,6 +1902,7 @@ static enum fullness_group putback_zspage(struct
size_class *class,
VM_BUG_ON_PAGE(!list_empty(&first_page->lru), first_page);
VM_BUG_ON_PAGE(ZsPageIsolate(first_page), first_page);
+ VM_BUG_ON_PAGE(check_isolated_page(first_page), first_page);
fullness = get_fullness_group(class, first_page);
insert_zspage(class, fullness, first_page);
@@ -1956,6 +2009,12 @@ static struct page *isolate_source_page(struct
size_class *class)
if (!page)
continue;
+ /* To prevent race between object and page migration */
+ if (!trylock_zspage(page,
Re: [GIT PULL] Btrfs
On Mon, Mar 21, 2016 at 10:15:33PM -0400, Chris Mason wrote: > On Mon, Mar 21, 2016 at 06:16:54PM -0700, Linus Torvalds wrote: > > On Mon, Mar 21, 2016 at 5:24 PM, Chris Mason wrote: > > > > > > I waited an extra day to send this one out because I hit a crash late > > > last week with CONFIG_DEBUG_PAGEALLOC enabled (fixed in the top commit). > > > > Hmm. If that commit helps, it will spit out a warning. > > > > So is it actually fixed, or just hacked around to the point where you > > don't get a page fault? Hmmm, rereading my answer I realized I didn't actually answer. I really think this is fixed. I left the warning only because I originally expected something much more exotic. -chris
Re: [PATCH] staging: rts5208: coding style clean-ups
On Tue, Mar 22, 2016 at 07:45:25AM +0530, Sohom Bhattacharjee wrote: > On Mon, Mar 21, 2016 at 05:29:24PM -0400, Greg KH wrote: > > On Mon, Mar 21, 2016 at 10:53:36PM +0530, Sohom Bhattacharjee wrote: > > > fixed *only* comments that did not follow kernel coding style. > > > the errors were caught by the checkpatch.pl tool > > > > > > Signed-off-by: Sohom Bhattacharjee > > > > Does not apply to the tree at all :( > what do you mean ? > i used the Linus's latest git tree. :) That's usually quite a bit behind the current development tree. Always use linux-next to work against, you can miss almost 3 months of development effort at times. thanks, greg k-h
Re: [PATCH v6 1/4] lib/percpu-list: Per-cpu list with associated per-cpu locks
On 03/21/2016 05:49 AM, Jan Kara wrote:
On Fri 18-03-16 15:44:01, Waiman Long wrote:
+static __always_inline bool
+__pcpu_list_next_cpu(struct pcpu_list_head *head, struct pcpu_list_state
*state)
+{
+ if (state->lock)
+ spin_unlock(state->lock);
+next_cpu:
+ /*
+* for_each_possible_cpu(cpu)
+*/
+ state->cpu = cpumask_next(state->cpu, cpu_possible_mask);
+ if (state->cpu>= nr_cpu_ids)
+ return false; /* All the per-cpu lists iterated */
+
+ state->head =&per_cpu_ptr(head, state->cpu)->list;
+ if (list_empty(state->head))
+ goto next_cpu;
+
+ state->lock =&per_cpu_ptr(head, state->cpu)->lock;
+ spin_lock(state->lock);
+ state->curr = list_entry(state->head->next,
+struct pcpu_list_node, list);
+ return true;
Waiman, I repeat it for the third time as you keep ignoring it: This is
*racy*. The list for state->cpu can be empty by the time you acquire
state->lock and thus state->curr will point somewhere around the head of
the list but definitely not to a list member where it should.
Honza
I am sorry for missing your previous comment. Yes, it is possible that
the list is empty after the lock. So I should have checked for that
before returning. Thanks for reminding me that. I will fix that later on.
Cheers,
Longman
Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER
Shawn,
On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin wrote:
>> ...but, looking at this, presumably before landing any patch that made
>> dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify
>> _all_ users of dma_request_slave_channel to handle error pointers
>> being returned. Right now dma_request_slave_channel() says it returns
>> a pointer to a channel or NULL and the function explicitly avoids
>> returning any errors. That might be possible, but it's a big
>> change...
>
>
> At first glance, it's a big change, but maybe not really.
> Almost all of them use the templet like:
> ch = dma_request_slave_channel
> if (!ch)
> balabala
>
> It's same for all the non-null return pointer/non-zero value ?
>
> So from my view, we can safely change dma_request_slave_channel,
> and leave the caller here. I presumably the respective
> drivers will graduately migrate to check the return value with
> EPROBE_DEFER if they do care this issue. Otherwise, we believe
> they don't suffer the changes we make, just as what they did in the
> past. Does that make sense?
...but if you return ERR_PTR(-EPROBE_DEFER) and don't change existing
callers, then existing callers will think you've returned a valid
pointer when you really returned an error pointer. They'll pass this
error pointer around like it's a valid "struct dma_chan", won't then?
Actually, could your code just call
dma_request_slave_channel_reason(). Oh, looks like that's exactly
what you want. See commit 0ad7c00057dc ("dma: add channel request API
that supports deferred probe"). Oh, but I'm looking at 4.4. Looking
at linuxnext, it looks like this got renamed to dma_request_chan().
...so you need to use that, no?
Strange, but on 4.4 there was some extra code in
dma_request_slave_channel() that wasn't in
dma_request_slave_channel_reason(). ...but looks like that all got
cleaned up in the same CL that added the new name.
-Doug
Re: [GIT PULL] Btrfs
On Mon, Mar 21, 2016 at 7:24 PM, Chris Mason wrote: > > Hmmm, rereading my answer I realized I didn't actually answer. I really > think this is fixed. I left the warning only because I originally > expected something much more exotic. Ok. It's more that you said the top commit fixes a problem, and the only case where the top commit makes a difference it will also do that WARN_ON_ONCE. But it's pulled, test-built, and pushed out now. Linus
Re: Nonterministic hang during bootconsole/console handover on ath79
Hi Matthias,
On 03/21/2016 04:02 PM, Matthias Schiffer wrote:
> Hi,
> we're experiencing weird nondeterministic hangs during bootconsole/console
> handover on some ath79 systems on OpenWrt. I've seen this issue myself on
> kernel 3.18.23~3.18.27 on a AR7241-based system, but according to other
> reports ([1], [2]) kernel 4.1.x is affected as well, and other SoCs like
> QCA953x likewise.
>
> See the log below for the exact place it hangs; the log was taken in during
> a good boot; a bad boot will just hang forever at the marked location. The
> issue is extremely hard to debug, as changing the timing in any way (like
> adding additional printk) will usually make it work without problems. (Even
> recompiling the kernel with the same config, but different uname timestamp
> will make the occurence more or less likely)
>
> My theory is the following:
>
> As soon as ttyS0 is detected and installed as the console, there are two
> console drivers active on the serial port at the same time: early0 and
> ttyS0. I suspect that the hang occurs when the primitive early0
> implementation prom_putchar_ar71xx waits indefinitely on THRE, but the real
> driver has just reset the serial controller in a way that makes THRE never
> come.
Doubtful.
console writes are performed with ints disabled, as is the 8250 driver's
autoconfig probing. Since this is a UP platform, as long as you're not
using the DEBUG_AUTOCONF switch in the 8250 driver, I don't think there's
a way for the boot console to be outputting while the 8250 driver is
configuring.
> When the boot is successful, I also sometimes see just garbage
> instead of the message "serial8250.0: ttyS0 at MMIO 0x1802...", which
> supports my idea that the kernel is trying to use the serial console while
> it is not correctly setup.
>
> Is is possible that the first "console [ttyS0] disabled" message caused by
> the call chain
>
> serial8250_register_8250_port
> uart_remove_one_port
> unregister_console
>
> should rather unregister early0 (as ttyS0 is not even registered at this
> point), so having both drivers active at the same time is avoided?
No.
Having both consoles active briefly at the handover is not really a problem;
all consoles are serialized with each other. Only one console can be outputting
at any one time.
The unregister_console() producing the bogus "ttyS0 disabled" message
is wrong but harmless.
That part happens because the 8250 driver creates phantom ports which are
unregistered as new ports are probed, but the ttyS0 console hadn't actually
been registered yet.
> Does this make any sense? Or do you have any other idea what might cause this?
I wonder if autoconfig probing (that's what discovers the uart port type)
is broken.
You could test this hypothesis by setting the port type directly and
set UPF_FIXED_TYPE; ie., in arch/mips/ath79/dev-common.c
diff --git a/arch/mips/ath79/dev-common.c b/arch/mips/ath79/dev-common.c
index 516225d..3814a42 100644
--- a/arch/mips/ath79/dev-common.c
+++ b/arch/mips/ath79/dev-common.c
@@ -36,7 +36,8 @@ static struct plat_serial8250_port ath79_uart_data[] = {
{
.mapbase= AR71XX_UART_BASE,
.irq= ATH79_MISC_IRQ(3),
- .flags = AR71XX_UART_FLAGS,
+ .flags = AR71XX_UART_FLAGS | UPF_FIXED_TYPE,
+ .type = PORT_16550A,
.iotype = UPIO_MEM32,
.regshift = 2,
}, {
Regards,
Peter Hurley
> Thanks in advance,
> Matthias
>
>
> [1] https://dev.openwrt.org/ticket/21773
> [2] https://dev.openwrt.org/ticket/21857
>
>
>> [0.00] Linux version 3.18.27 (neoraider@avalon) (gcc version 4.8.3
>> (OpenWrt/Linaro GCC 4.8-2014.04 r47335) ) #6 Sun Mar 20 22:40:15 CET 2016
>> [0.00] bootconsole [early0] enabled
>> [0.00] CPU0 revision is: 00019374 (MIPS 24Kc)
>> [0.00] SoC: Atheros AR7241 rev 1
>> [0.00] Determined physical RAM map:
>> [0.00] memory: 0200 @ (usable)
>> [0.00] Initrd not found or empty - disabling initrd
>> [0.00] Zone ranges:
>> [0.00] Normal [mem 0x-0x01ff]
>> [0.00] Movable zone start for each node
>> [0.00] Early memory node ranges
>> [0.00] node 0: [mem 0x-0x01ff]
>> [0.00] Initmem setup node 0 [mem 0x-0x01ff]
>> [0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32
>> bytes.
>> [0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize
>> 32 bytes
>> [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
>> pages: 8128
>> [0.00] Kernel command line: board=TL-WR841N-v7 console=ttyS0,115200
>> rootfstype=squashfs,jffs2 noinitrd
>> [0.00] PID hash table entries: 128 (order: -3, 512 bytes)
>> [0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
>> [0.00] Inode
Re: [PATCH v11] cpufreq: powernv: Add sysfs attributes to show throttle stats
On 21-03-16, 22:29, Shilpasri G Bhat wrote:
> + create_throttle_sysfs = kcalloc(cpu_nr_cores(), sizeof(bool),
> + GFP_KERNEL);
> + if (!create_throttle_sysfs) {
> + kfree(chips);
> + return -ENOMEM;
> + }
> +
> for (i = 0; i < nr_chips; i++) {
> chips[i].id = chip[i];
> cpumask_copy(&chips[i].mask, cpumask_of_node(chip[i]));
> @@ -582,6 +655,7 @@ static int init_chip_info(void)
>
> static inline void clean_chip_info(void)
> {
> + kfree(create_throttle_sysfs);
> kfree(chips);
> }
Why do you need this at all?. You can use policy->driver data, isn't
it ?
--
viresh
Re: [PATCH] cpufreq: governor: Always schedule work on the CPU running update
On 22-03-16, 01:17, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Modify dbs_irq_work() to always schedule the process-context work > on the current CPU which also ran the dbs_update_util_handler() > that the irq_work being handled came from. > > This causes the entire frequency update handling (involving the > "ondemand" or "conservative" governors) to be carried out by the > CPU whose frequency is to be updated and reduces the overall amount > of inter-CPU noise related to cpufreq. > > Signed-off-by: Rafael J. Wysocki > --- > drivers/cpufreq/cpufreq_governor.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-pm/drivers/cpufreq/cpufreq_governor.c > === > --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c > +++ linux-pm/drivers/cpufreq/cpufreq_governor.c > @@ -245,7 +245,7 @@ static void dbs_irq_work(struct irq_work > struct policy_dbs_info *policy_dbs; > > policy_dbs = container_of(irq_work, struct policy_dbs_info, irq_work); > - schedule_work(&policy_dbs->work); > + schedule_work_on(smp_processor_id(), &policy_dbs->work); > } > > static void dbs_update_util_handler(struct update_util_data *data, u64 time, queue_work() used to queue the work on local cpu by default, has that changed now ? -- viresh
Re: Nonterministic hang during bootconsole/console handover on ath79
On 03/21/2016 05:52 PM, Matthias Schiffer wrote: > On 03/22/2016 12:08 AM, Greg KH wrote: >> On Tue, Mar 22, 2016 at 12:02:57AM +0100, Matthias Schiffer wrote: >>> Hi, >>> we're experiencing weird nondeterministic hangs during bootconsole/console >>> handover on some ath79 systems on OpenWrt. I've seen this issue myself on >>> kernel 3.18.23~3.18.27 on a AR7241-based system, but according to other >>> reports ([1], [2]) kernel 4.1.x is affected as well, and other SoCs like >>> QCA953x likewise. >> >> Can you try 4.4 or ideally, 4.5? There's been a lot of console/tty >> fixes/changes since the obsolete 3.18 kernel you are using... >> >> thanks, >> >> greg k-h >> > > With 4.4, I was not able to reproduce this hang, but I have no idea if this > is caused by an actual bugfix, or just random timing changes hiding the > bug. Can you continue testing with 4.4.x and see if it eventually reproduces? > I suspect the latter might be the case (as I wrote in my first mail, > even minor differences in kernel images of the same version and the same > config make the hang more or less probable.) I was not yet able to test > 4.5, as OpenWrt is a hell of kernel patches... > > On 3.18, I also tried other things like disabling the early console > altogether, which also made the hang go away, but as even much smaller > changes hid the bug, this doesn't really say much. FWIW, printk() is not a small change; takes ~500us @ 115200 > > The basic code path during the console handover seems to be the same in > 3.18 and 4.4, even though a few functions have been moved; the relevant > part of the log looks the same: > >> [0.756298] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled >> [0.766754] console [ttyS0] disabled >> [0.790293] serial8250.0: ttyS0 at MMIO 0x1802 (irq = 11, base_baud = >> 1250) is a 16550A >> [0.798909] console [ttyS0] enabled >> [0.798909] console [ttyS0] enabled >> [0.805854] bootconsole [early0] disabled >> [0.805854] bootconsole [early0] disabled > > So, in propect of an actual bugfix or backport, this boils down to two > questions, which I hope the serial or MIPS maintainers can answer me: > > * Is it sane to have two console drivers using the same serial port? In > particular, is it sane for the early console to use the serial port after > serial8250_config_port has reset/configured it, but before the rest of the > setup of uart_configure_port has run? (this would be the case for the > message "serial8250.0: ttyS0 at MMIO...") > * Is it possible to get the serial controller into a state in which > early_printk might wait for THRE forever? I think I addressed these questions in my other reply; let me know if not. Regards, Peter Hurley
[lkp] [drm/i915] 97f9010af0: No primary result change, -36.2% piglit.time.percent_of_cpu_this_job_got
FYI, we noticed that piglit.time.percent_of_cpu_this_job_got -36.2% change with
your commit.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 97f9010af05c15e0b7e6b4ef6ff8cb0ebb7e7715 ("drm/i915: mdelay(10)
considered harmful")
=
compiler/group/kconfig/rootfs/tbox_group/testcase:
gcc-4.9/igt-037/x86_64-rhel/debian-x86_64-2015-02-07.cgz/snb-drag/piglit
commit:
57a2af6bbc7a4f1b145cc216c34476402836f0b8
97f9010af05c15e0b7e6b4ef6ff8cb0ebb7e7715
57a2af6bbc7a4f1b 97f9010af05c15e0b7e6b4ef6f
--
fail:runs %reproductionfail:runs
%stddev %change %stddev
\ |\
69.00 ± 0% -36.2% 44.00 ± 0%
piglit.time.percent_of_cpu_this_job_got
44.77 ± 0% -36.0% 28.66 ± 0% piglit.time.system_time
38337 ± 0% +4.1% 39904 ± 0%
piglit.time.voluntary_context_switches
69.00 ± 0% -36.2% 44.00 ± 0% time.percent_of_cpu_this_job_got
44.77 ± 0% -36.0% 28.66 ± 0% time.system_time
snb-drag: Sandy Bridge
Memory: 6G
piglit.time.system_time
46 ++-+
*..*..*..*..*..*..*..*..*..*..*..*..*.*..*..*..*..*..*..*..*..*..* |
44 ++ |
42 ++ |
| |
40 ++ |
38 ++ |
| |
36 ++ |
34 ++ |
| |
32 ++ |
30 ++ |
O O O O O O O O O O O O O O O O O O O O O O O O O
28 ++-+
piglit.time.percent_of_cpu_this_job_got
70 *+*--*--*--*--*--*--*--*--*--*--*-*--*--*--*--*--*--*--*--*--*-+
| .. |
65 ++ * |
60 ++ |
| |
55 ++ |
50 ++ |
| |
45 ++O O O O
40 ++ |
|O O O O O O O O O O |
35 ++ |
30 ++ |
| |
25 O+-O--O--O--O--O--O--O--O--O--O+
piglit.time.voluntary_context_switches
46000 ++--+
O O O O O O O O O O O |
45000 ++ |
44000 ++ |
| |
43000 ++ |
| |
42000 ++ |
| |
41000 ++ O O O O O O O O O O |
4 ++ |
| O O O O
39000 ++ |
*..*..*..*.*..*..*..*..*..*.*..*..*..*..*..*.*..*..*..*..*..*.* |
38000 ++--+
[*] bisect-good sample
[O] bisect-bad sample
To reproduce:
Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER
+ Vinod
On 2016/3/22 10:33, Doug Anderson wrote:
Shawn,
On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin wrote:
...but, looking at this, presumably before landing any patch that made
dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify
_all_ users of dma_request_slave_channel to handle error pointers
being returned. Right now dma_request_slave_channel() says it returns
a pointer to a channel or NULL and the function explicitly avoids
returning any errors. That might be possible, but it's a big
change...
At first glance, it's a big change, but maybe not really.
Almost all of them use the templet like:
ch = dma_request_slave_channel
if (!ch)
balabala
It's same for all the non-null return pointer/non-zero value ?
So from my view, we can safely change dma_request_slave_channel,
and leave the caller here. I presumably the respective
drivers will graduately migrate to check the return value with
EPROBE_DEFER if they do care this issue. Otherwise, we believe
they don't suffer the changes we make, just as what they did in the
past. Does that make sense?
...but if you return ERR_PTR(-EPROBE_DEFER) and don't change existing
callers, then existing callers will think you've returned a valid
pointer when you really returned an error pointer. They'll pass this
error pointer around like it's a valid "struct dma_chan", won't then?
possibly, it depends on how caller deal with it. Should check it case by
case for each caller.
Actually, could your code just call
dma_request_slave_channel_reason(). Oh, looks like that's exactly
what you want. See commit 0ad7c00057dc ("dma: add channel request API
that supports deferred probe"). Oh, but I'm looking at 4.4. Looking
at linuxnext, it looks like this got renamed to dma_request_chan().
...so you need to use that, no?
Strange, but on 4.4 there was some extra code in
dma_request_slave_channel() that wasn't in
dma_request_slave_channel_reason(). ...but looks like that all got
cleaned up in the same CL that added the new name.
dma_request_chan already return ERR_PTR(-EPROBE_DEFER), but
dma_request_slave_channel ignore this and rewrite it to be NULL.
Strange behaviour looks to me. commit 0ad7c00057dc ("dma: add channel
request API that supports deferred probe") did the right thing, but
what happened then? It was drop for some reasons?
Hello Vinod,
Could you please elaborate some more infomation to commit 0ad7c00057dc
("dma: add channel request API that supports deferred probe") :) ?
-Doug
--
Best Regards
Shawn Lin
arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (240) for 'rur240'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 968f3e374faf41e5e6049399eb7302777a09a1e8 commit: 2c684d892bb2ee31cc48f4a8b91e86a0f15e82f9 xtensa: add Three Core HiFi-2 MX Variant. date: 4 days ago config: xtensa-smp_lx200_defconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 2c684d892bb2ee31cc48f4a8b91e86a0f15e82f9 # save the attached .config to linux build tree make.cross ARCH=xtensa All errors (new ones prefixed by >>): arch/xtensa/kernel/coprocessor.S: Assembler messages: >> arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (240) >> for 'rur240' >> arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (241) >> for 'rur241' >> arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (242) >> for 'rur242' >> arch/xtensa/kernel/coprocessor.S:93: Error: invalid register number (243) >> for 'rur243' >> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name >> 'ae_sp24x2s.i' >> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name >> 'ae_sp24x2s.i' >> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name >> 'ae_sp24x2s.i' >> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name >> 'ae_sp24x2s.i' >> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name >> 'ae_sp24x2s.i' >> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name >> 'ae_sp24x2s.i' >> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name >> 'ae_sp24x2s.i' >> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name >> 'ae_sp24x2s.i' >> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name >> 'ae_sq56s.i' >> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name >> 'ae_sq56s.i' >> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name >> 'ae_sq56s.i' >> arch/xtensa/kernel/coprocessor.S:93: Error: unknown opcode or format name >> 'ae_sq56s.i' >> arch/xtensa/kernel/coprocessor.S:102: Error: invalid register number (240) >> for 'wur240' >> arch/xtensa/kernel/coprocessor.S:102: Error: invalid register number (241) >> for 'wur241' >> arch/xtensa/kernel/coprocessor.S:102: Error: invalid register number (242) >> for 'wur242' >> arch/xtensa/kernel/coprocessor.S:102: Error: invalid register number (243) >> for 'wur243' -- arch/xtensa/include/asm/processor.h: Assembler messages: >> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format >> name 'rer' >> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format >> name 'wer' >> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format >> name 'rer' >> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format >> name 'wer' >> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format >> name 'rer' >> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format >> name 'rer' >> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format >> name 'wer' >> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format >> name 'rer' >> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format >> name 'wer' >> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format >> name 'rer' >> arch/xtensa/include/asm/processor.h:233: Error: unknown opcode or format >> name 'rer' -- arch/xtensa/kernel/head.S: Assembler messages: >> arch/xtensa/kernel/head.S:187: Error: unknown opcode or format name 'wer' arch/xtensa/kernel/head.S:317: Error: unknown opcode or format name 'wer' -- arch/xtensa/include/asm/processor.h: Assembler messages: >> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format >> name 'wer' >> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format >> name 'wer' >> arch/xtensa/include/asm/processor.h:227: Error: unknown opcode or format >> name 'wer' vim +/rur240 +93 arch/xtensa/kernel/coprocessor.S c658eac6 Chris Zankel 2008-02-12 87 .else; \ c658eac6 Chris Zankel 2008-02-12 88 .long 0; \ c658eac6 Chris Zankel 2008-02-12 89 .endif; \ c658eac6 Chris Zankel 2008-02-12 90 .long THREAD_XTREGS_CP##x 5a0015d6 Chris Zankel 2005-06-23 91 c658eac6 Chris Zankel 2008-02-12 92 SAVE_CP_REGS(0) c658eac6 Chris Zankel 2008-02-12 @93 SAVE_CP_REGS(1) c658eac6 Chris Zankel 2008-02-12 94 SAVE_CP_REGS(2) c658eac6 Chris Zankel 2008-02-12 95 SAVE_CP_REGS(3) c658eac6 Chris Zankel 2008-02-12 96 SAVE_CP_REGS(4) c658eac6 Chris Zankel
Re: [PATCH v2] net: add missing descriptions in net_device_priv_flags
From: Luis de Bethencourt Date: Mon, 21 Mar 2016 20:58:28 + > The flags IFF_XMIT_DST_RELEASE_PERM, IFF_IPVLAN_MASTER and > IFF_IPVLAN_SLAVE are missing descriptions for the Documentation. Adding > them. > > Signed-off-by: Luis de Bethencourt > Suggested-by: Benjamin Poirier Applied.
[lkp] [cpuidle] b67bb65b9d: No primary result change, -33.1% turbostat.%Busy
O O O | | | 12 ++-+ turbostat.CPU_c1 66 ++-+ O O| 65 ++ O O O O O O O O O O O O O O O O O O O | 64 ++ | | | 63 ++ | 62 ++ | | | 61 ++ | 60 ++ | | | 59 ++ | 58 ++ | *..*..*...*..*..*..*...*..*..*..*...*..*..*..*..*...*..*..*..*...*..*..* 57 ++-+ turbostat.PkgWatt 374 +++ 372 *+.*.. .*..*.. ..*..*..*.. .*..*...*.. .* | *...*..*..*..*..*..*...*. *..*. *. *. | 370 ++| 368 ++| | | 366 ++| 364 ++| 362 ++| | | 360 ++| 358 ++| O | 356 ++ O O O O O O O O O O O O OO O | 354 ++--OO-O--O-O-+ [*] bisect-good sample [O] bisect-bad sample To reproduce: git clone git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git cd lkp-tests bin/lkp install job.yaml # job file is attached in this email bin/lkp run job.yaml Disclaimer: Results have been estimated based on internal Intel analysis and are provided for informational purposes only. Any difference in system hardware or software design or configuration may affect actual performance. Thanks, Xiaolong Ye --- LKP_SERVER: inn LKP_CGI_PORT: 80 LKP_CIFS_PORT: 139 testcase: vm-scalability default-monitors: wait: activate-monitor kmsg: uptime: iostat: heartbeat: vmstat: numa-numastat: numa-vmstat: numa-meminfo: proc-vmstat: proc-stat: interval: 10 meminfo: slabinfo: interrupts: lock_stat: latency_stats: softirqs: bdi_dev_mapping: diskstats: nfsstat: cpuidle: cpufreq-stats: turbostat: pmeter: sched_debug: interval: 60 cpufreq_governor: performance default-watchdogs: oom-killer: watchdog: commit: b67bb65b9de2d3c070073028aeb30cca6c6790a7 model: Brickland Haswell-EX nr_cpu: 120 memory: 512G nr_ssd_partitions: 1 ssd_partitions: "/dev/nvme0n1p1" swap_partitions: rootfs_partition: pmeter_server: lkp-st01 pmeter_device: yokogawa-wt310 category: benchmark perf-profile: runtime: 300s size: 1T vm-scalability: test: msync-mt queue: bisect testbox: lkp-hsx04 tbox_group: lkp-hsx04 kconfig: x86_64-rhel enqueue_time: 2016-03-21 11:41:09.815149567 +08:00 compiler: gcc-4.9 rootfs: debian-x86_64-2015-02-07.cgz id: 002c8e1d3658e5cd8978ad0552ee7fe543f64af0 user: lkp head_commit: cd1a8af09f25054f01c0f06dcd43d99a3196eb0c base_commit: b562e44f507e863c6792946e4e1b1449fbbac85d branch: linux-devel/devel-hourly-2016032015 result_root: "/result/vm-scalability/performance-300s-1T-msync-mt/lkp-hsx04/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/b67bb65b9de2d3c070073028aeb30cca6c6790a7/0" job_file: "/lkp/scheduled/lkp-hsx04/bisect_vm-scalability-performance-300s-1T-msync-mt-debian-x86_64-2015-02-07.cgz-x86_64-rhel-b67bb65b9de2d3c070073028aeb30cca6c6790a7-20160321-79544-wxo1vq-0.yaml" max_uptime: 1500 initrd: "/osimage/debian/debian-x86_64-2015-02-07.cgz" bootloader_append: - root=/dev/ram0 - user=lkp - job=/lkp/scheduled/lkp-hsx04/bisect_
Linux 3.4.111
I'm announcing the release of the 3.4.111 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary The following changes since commit 3edd6224c2a677bb59efe0b083a51fc2b3b5c64d: Linux 3.4.110 (2015-10-22 09:20:09 +0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lizf/linux-3.4.y.git tags/v3.4.111 for you to fetch changes up to 3389604d77540abf738b486d650c1745b2d663ca: Linux 3.4.111 (2016-03-21 09:17:59 +0800) This is the 3.4.111 stable release AMAN DEEP (1): usb: xhci: Bugfix for NULL pointer deference in xhci_endpoint_init() function Al Viro (3): 9p: don't leave a half-initialized inode sitting around sg_start_req(): make sure that there's not too many elements in iovec get rid of s_files and files_lock Aleksei Mamlin (1): libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for HP 250GB SATA disk VB0250EAVER Alex Deucher (1): drm/radeon/combios: add some validation of lvds values Alexei Potashnik (1): target/iscsi: Fix double free of a TUR followed by a solicited NOPOUT Andrey Vagin (1): netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get Andy Lutomirski (2): x86/xen: Probe target addresses in set_aliased_prot() before the hypercall x86/ldt: Make modify_ldt synchronous Anssi Hannula (1): ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly Arne Fitzenreiter (2): libata: add ATA_HORKAGE_NOTRIM libata: force disable trim for SuperSSpeed S238 Bart Van Assche (1): libfc: Fix fc_fcp_cleanup_each_cmd() Ben Hutchings (2): isdn_ppp: Add checks for allocation failure in isdn_ppp_open() ppp, slip: Validate VJ compression slot parameters completely Ben Zhang (1): kernel/watchdog.c: touch_nmi_watchdog should only touch local cpu not every one Bernhard Bender (1): Input: usbtouchscreen - avoid unresponsive TSC-30 touch screen Brian Campbell (1): xhci: Calculate old endpoints correctly on device reset Chris Metcalf (1): tile: use free_bootmem_late() for initrd Claudio Cappelli (1): USB: option: add 2020:4000 ID Clemens Ladisch (2): ALSA: tlv: compute TLV_*_ITEM lengths automatically ALSA: tlv: add DECLARE_TLV_DB_RANGE() Dan Carpenter (1): rds: fix an integer overflow test in rds_info_getsockopt() Daniel Borkmann (1): rtnetlink: verify IFLA_VF_INFO attributes before passing them to driver David Ahern (1): net: Fix RCU splat in af_key David Daney (1): MIPS: Make set_pte() SMP safe. David Howells (2): KEYS: Fix race between key destruction and finding a keyring by name KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring Dennis Yang (1): dm btree remove: fix bug in redistribute3 Dirk Behme (1): USB: sierra: add 1199:68AB device ID Dominic Sacr茅 (1): ALSA: usb-audio: Add MIDI support for Steinberg MI2/MI4 Edward Hyunkoo Jee (1): inet: frags: fix defragmented packet's IP header for af_packet Eric Northup (1): KVM: x86: work around infinite loop in microcode when #AC is delivered Felix Fietkau (1): MIPS: Fix sched_getaffinity with MT FPAFF enabled Filipe Manana (1): Btrfs: use kmem_cache_free when freeing entry in inode cache Gioh Kim (1): fs/buffer.c: support buffer cache allocations with gfp modifiers Hannes Frederic Sowa (3): net: add validation for the socket syscall protocol argument ipv6: probe routes asynchronous in rt6_probe net: fix warnings in 'make htmldocs' by moving macro definition out of field declaration Heiko Carstens (1): s390/process: fix sfpc inline assembly Herbert Xu (2): net: Clone skb before setting peeked flag crypto: ixp4xx - Remove bogus BUG_ON on scattered dst buffer Herton R. Krzesinski (1): ipc,sem: fix use after free on IPC_RMID after a task using same semaphore set exits Jan Beulich (1): x86/LDT: Print the real LDT base address Jason Wang (1): virtio-net: drop NETIF_F_FRAGLIST Jiri Pirko (1): niu: don't count tx error twice in case of headroom realloc fails Joe Perches (1): hpfs: hpfs_error: Remove static buffer, use vsprintf extension %pV instead Joe Stringer (1): netfilter: nf_conntrack: Support expectations in different zones Joe Thornber (4): dm thin: allocate the cell_sort_array dynamically dm btree: silence lockdep lock inversion in dm_btree_del() dm btree: add ref
Re: [PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem in mbigen driver.
在 2016/3/21 18:29, Thomas Gleixner 写道: > On Thu, 17 Mar 2016, MaJun wrote: >> This patch set is used to fix the problem of remap a set of registers >> repeatedly in current mbigen driver. >> >> irqchip/mbigen:Change the mbigen node definition in dt binding file >> irqchip/mbigen:Change the mbigen driver based on the new mbigen node >> definition > > These subject lines are still horrible as they tell nothing about the nature > of the change. I fixed them up along with the changelogs and applied them to > irq/urgent. Can you spot the difference? Yes, after you changing, the subject and change log clearly show why we need to do this change. I have learned a lot from you :) > > While at it. The config switch for this driver is horrible. It's just in the > middle of the device driver configs. Why is this configurable by the user at > all? It simply should be selected by arm64 or some subarch configuration > there. Please clean that up. > will do. Thanks! MaJun > Thanks, > > tglx > > . >
Re: [PATCH 1/3] cpufreq: Introduce cpufreq_start_governor()
On 21-03-16, 15:45, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Starting a governor in cpufreq always follows the same pattern > involving two calls to cpufreq_governor(), one with the event > argument set to CPUFREQ_GOV_START and one with that argument set to > CPUFREQ_GOV_LIMITS. > > Introduce cpufreq_start_governor() that will carry out those two > operations and make all places where governors are started use it. > > That slightly modifies the behavior of cpufreq_set_policy() which > now also will go back to the old governor if the second call to > cpufreq_governor() (the one with event equal to CPUFREQ_GOV_LIMITS) > fails, but that really is how it should work in the first place. > > Also cpufreq_resume() will now pring an error message if the > CPUFREQ_GOV_LIMITS call to cpufreq_governor() fails, but that > makes it follow cpufreq_add_policy_cpu() and cpufreq_offline() > in that respect. > > Signed-off-by: Rafael J. Wysocki > --- > drivers/cpufreq/cpufreq.c | 44 ++-- > 1 file changed, 22 insertions(+), 22 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: [PATCH 2/3] cpufreq: Introduce cpufreq_update_current_freq()
On 21-03-16, 15:46, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Move the part of cpufreq_update_policy() that obtains the current > frequency from the driver and updates policy->cur if necessary to > a separate function, cpufreq_get_current_freq(). > > That should not introduce functional changes and subsequent change > set will need it. > > Signed-off-by: Rafael J. Wysocki > --- > drivers/cpufreq/cpufreq.c | 28 +++- > 1 file changed, 19 insertions(+), 9 deletions(-) Acked-by: Viresh Kumar -- viresh
[PATCH v3 0/1] arm64/dma-mapping: reduce an unnecessary conversion for coherent DMA
Changelog: v2 -> v3: 1. Just add some description for this patch. v1 -> v2: 1. Give up removing the conversion, because of thoughtless, instead moved it into branch if (!is_device_dma_coherent(dev)). Thanks for Catalin's detailed explanation, I directly take some relies as comment in the code. Zhen Lei (1): arm64/dma-mapping: reduce an unnecessary conversion for coherent DMA arch/arm64/mm/dma-mapping.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) -- 2.5.0
[PATCH v3 1/1] arm64/dma-mapping: reduce an unnecessary conversion for coherent DMA
1.For coherent DMA
In swiotlb_alloc_coherent, it directly return vaddr on success, and
pass vaddr to free_pages on failure. So, we can directly transparent pass
vaddr from __dma_free to swiotlb_free_coherent.
According to my testing, it can save 8 clock cycles.
2.For non-coherent DMA.
Keep no change for the original processing flow.
Because all DDR memory mapped as cacheable by default. But for
non-coherent devices, both CPUs and devices should use NC(non-cacheable)
attributes to access memory, to keep consistency. So we can not directly
use vaddr retured by __dma_alloc_coherent, but should further remap the
physical memory as NC and return it. So in __dma_free, we first use the
NC-vaddr to unmap, then get vaddr base upon dma_handle and use it to free
memory back to buddy.
Signed-off-by: Zhen Lei
---
arch/arm64/mm/dma-mapping.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index a6e757c..ceb2018 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -187,16 +187,22 @@ static void __dma_free(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle,
struct dma_attrs *attrs)
{
- void *swiotlb_addr = phys_to_virt(dma_to_phys(dev, dma_handle));
-
size = PAGE_ALIGN(size);
if (!is_device_dma_coherent(dev)) {
if (__free_from_pool(vaddr, size))
return;
vunmap(vaddr);
+
+ /*
+* For non-coherent DMA, the vaddr is not part of the linear
+* mapping as it has been remapped by __dma_alloc() via
+* dma_common_contiguous_remap(), hence for swiotlb freeing we
+* need the actual linear map address.
+*/
+ vaddr = phys_to_virt(dma_to_phys(dev, dma_handle));
}
- __dma_free_coherent(dev, size, swiotlb_addr, dma_handle, attrs);
+ __dma_free_coherent(dev, size, vaddr, dma_handle, attrs);
}
static dma_addr_t __swiotlb_map_page(struct device *dev, struct page *page,
--
2.5.0
Re: [PATCH v2 0/4] locking/mutex: Enable optimistic spinning of lock waiter
On 02/16/2016 03:51 AM, Peter Zijlstra wrote: On Fri, Feb 12, 2016 at 12:32:11PM -0500, Waiman Long wrote: My own test on a 4-socket E7-4820 v3 system showed a regression of about 4% in the high_systime workload with Peter's patch which this new patch effectively eliminates. Testing on an 8-socket Westmere-EX server, however, has performance change from -9% to than +140% on the fserver workload of AIM7 depending on how the system was set up. Subject: [lkp] [locking/mutex] aaca135480: -72.9% fsmark.files_per_sec My patch also generated the above email. Please also test that benchmark against this approach. I also got an email from "kernel test robot", it didn't list fsmark at all. Instead, the subject was [lkp] [locking/mutex] 5267438002: +38.9% fileio.time.involuntary_context_switches 4409 ± 1% +38.9% 6126 ± 2% fileio.time.involuntary_context_switches 6.00 ± 0% +33.3% 8.00 ± 0% fileio.time.percent_of_cpu_this_job_got 36.06 ± 0% +43.0% 51.55 ± 0% fileio.time.system_time 1828660 ± 0% -92.5% 137258 ± 0% fileio.time.voluntary_context_switches Given that the number of voluntary context switches dropped by 92.5%, an increase in involuntary context switches that is order of magnitude less than the voluntary context switches should be OK, I think. Do you know how to report back that this increase is expected and is nothing to worry about? Do I just reply it back? Cheers, Longman
linux-next: Tree for Mar 22
Hi all, Please do not add any v4.7 related material to your linux-next included trees until after v4.6-rc1 is released. Changes since 20160321: The arm64 tree gained a conflict against Linus' tree. The rdma tree gained conflicts against Linus' tree. The drm tree lost its build failure. Non-merge commits (relative to Linus' tree): 1943 1620 files changed, 111055 insertions(+), 31754 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 231 trees (counting Linus' and 35 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (e531cdf50a8a Merge tag 'mmc-v4.6' of git://git.linaro.org/people/ulf.hansson/mmc) Merging fixes/master (36f90b0a2ddd Linux 4.5-rc2) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (deaf7565eb61 ARCv2: ioremap: Support dynamic peripheral address space) Merging arm-current/fixes (f474c8c857d9 ARM: 8544/1: set_memory_xx fixes) Merging m68k-current/for-linus (efbec135f11d m68k: Fix misspellings in comments.) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging powerpc-fixes/fixes (b562e44f507e Linux 4.5) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (9ef595d83aea sparc: Convert naked unsigned uses to unsigned int) Merging net/master (6b0725232dd1 Merge branch 'bridge-gso-segs-and-size') Merging ipsec/master (215276c0147e xfrm: Reset encapsulation field of the skb before transformation) Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID header search in SIP persistence engine) Merging wireless-drivers/master (10da848f67a7 ssb: host_soc depends on sprom) Merging mac80211/master (ad8ec957f693 wext: unregister_pernet_subsys() on notifier registration failure) Merging sound-current/for-linus (c64c1437afb1 ALSA: hda - Fix missing ELD update at unplugging) Merging pci-current/for-linus (30b5b8808c12 PCI: Restore inclusion of pci/hotplug Kconfig) Merging driver-core.current/driver-core-linus (18558cae0272 Linux 4.5-rc4) Merging tty.current/tty-linus (18558cae0272 Linux 4.5-rc4) Merging usb.current/usb-linus (6b5f04b6cf8e Merge branch 'for-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup) Merging usb-gadget-fixes/fixes (3b2435192fe9 MAINTAINERS: drop OMAP USB and MUSB maintainership) Merging usb-serial-fixes/usb-linus (f6cede5b49e8 Linux 4.5-rc7) Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: change workqueue ci_otg as freezable) Merging staging.current/staging-linus (1200b6809dfd Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next) Merging char-misc.current/char-misc-linus (5cd0911a9e0e Merge tag 'please-pull-pstore' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux) Merging input-current/for-linus (4d2508a55990 ARM: pxa/raumfeld: use PROPERTY_ENTRY_INTEGER to define props) Merging crypto-current/master (dfe97ad30e8c crypto: marvell/cesa - forward devm_ioremap_resource() error code) Merging ide/master (0d7ef45cdeeb ide: palm_bk3710: test clock rate to avoid division by 0) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstan
Re: [PATCH 3/3] cpufreq: Always update current frequency before startig governor
On 21-03-16, 15:47, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Make policy->cur match the current frequency returned by the driver's
> ->get() callback before starting the governor in case they went out of
> sync in the meantime and drop the piece of code attempting to
> resync policy->cur with the real frequency of the boot CPU from
> cpufreq_resume() as it serves no purpose any more (and it's racy and
> super-ugly anyway).
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/cpufreq/cpufreq.c | 14 +++---
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -1680,17 +1680,6 @@ void cpufreq_resume(void)
> __func__, policy);
> }
> }
> -
> - /*
> - * schedule call cpufreq_update_policy() for first-online CPU, as that
> - * wouldn't be hotplugged-out on suspend. It will verify that the
> - * current freq is in sync with what we believe it to be.
> - */
> - policy = cpufreq_cpu_get_raw(cpumask_first(cpu_online_mask));
> - if (WARN_ON(!policy))
> - return;
> -
> - schedule_work(&policy->update);
> }
>
> /**
> @@ -2062,6 +2051,9 @@ static int cpufreq_start_governor(struct
> {
> int ret;
>
> + if (cpufreq_driver->get && !cpufreq_driver->setpolicy)
> + cpufreq_update_current_freq(policy);
> +
> ret = cpufreq_governor(policy, CPUFREQ_GOV_START);
> return ret ? ret : cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
> }
This looks fine, but I am searching for answers to few doubts, maybe
you can help..
Why we did the same in process context earlier? And why it wouldn't be
a problem now, when we do it in interrupt context? Will IRQs be
disabled here? If so, then will you hit following ?
static void __cpufreq_notify_transition(struct cpufreq_policy *policy,
struct cpufreq_freqs *freqs, unsigned int state)
{
BUG_ON(irqs_disabled());
...
}
And will calling notifiers from interrupt-context just fine ?
--
viresh
Re: [PATCH 3/3] spi: rockchip: check requesting dma channel with EPROBE_DEFER
Shawn,
On Mon, Mar 21, 2016 at 7:53 PM, Shawn Lin wrote:
> + Vinod
>
>
> On 2016/3/22 10:33, Doug Anderson wrote:
>>
>> Shawn,
>>
>> On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin
>> wrote:
...but, looking at this, presumably before landing any patch that made
dma_request_slave_channel() return -EPROBE_DEFER you'd need to modify
_all_ users of dma_request_slave_channel to handle error pointers
being returned. Right now dma_request_slave_channel() says it returns
a pointer to a channel or NULL and the function explicitly avoids
returning any errors. That might be possible, but it's a big
change...
>>>
>>>
>>>
>>> At first glance, it's a big change, but maybe not really.
>>> Almost all of them use the templet like:
>>> ch = dma_request_slave_channel
>>> if (!ch)
>>> balabala
>>>
>>> It's same for all the non-null return pointer/non-zero value ?
>>>
>>> So from my view, we can safely change dma_request_slave_channel,
>>> and leave the caller here. I presumably the respective
>>> drivers will graduately migrate to check the return value with
>>> EPROBE_DEFER if they do care this issue. Otherwise, we believe
>>> they don't suffer the changes we make, just as what they did in the
>>> past. Does that make sense?
>>
>>
>> ...but if you return ERR_PTR(-EPROBE_DEFER) and don't change existing
>> callers, then existing callers will think you've returned a valid
>> pointer when you really returned an error pointer. They'll pass this
>> error pointer around like it's a valid "struct dma_chan", won't then?
>>
>
> possibly, it depends on how caller deal with it. Should check it case by
> case for each caller.
>
>> Actually, could your code just call
>> dma_request_slave_channel_reason(). Oh, looks like that's exactly
>> what you want. See commit 0ad7c00057dc ("dma: add channel request API
>> that supports deferred probe"). Oh, but I'm looking at 4.4. Looking
>> at linuxnext, it looks like this got renamed to dma_request_chan().
>> ...so you need to use that, no?
>>
>> Strange, but on 4.4 there was some extra code in
>> dma_request_slave_channel() that wasn't in
>> dma_request_slave_channel_reason(). ...but looks like that all got
>> cleaned up in the same CL that added the new name.
>
>
> dma_request_chan already return ERR_PTR(-EPROBE_DEFER), but
> dma_request_slave_channel ignore this and rewrite it to be NULL.
> Strange behaviour looks to me. commit 0ad7c00057dc ("dma: add channel
> request API that supports deferred probe") did the right thing, but
> what happened then? It was drop for some reasons?
>
> Hello Vinod,
>
> Could you please elaborate some more infomation to commit 0ad7c00057dc
> ("dma: add channel request API that supports deferred probe") :) ?
I think it's relatively straightforward.
The scheme they came up with allows them to more easily update one
client at a time. AKA:
* If your code has been updated to handle ERR_PTR() returns, you call
dma_request_slave_channel_reason().
* If your code hasn't been updated, it will still call
dma_request_slave_channel(). In this case EPROBE_DEFER is treated
like any other failure. That's not ideal but better than the
alternative.
* In recent kernels dma_request_slave_channel() was renamed to
dma_request_chan(). Old code can still use
dma_request_slave_channel_reason() but presumably they want you to use
dma_request_chan() for new code. They are equivalent:
> #define dma_request_slave_channel_reason(dev, name) dma_request_chan(dev,
> name)
So your patch should be:
- rs->dma_tx.ch = dma_request_slave_channel(rs->dev, "tx");
- if (!rs->dma_tx.ch)
+ rs->dma_tx.ch = dma_request_slave_chan(rs->dev, "tx");
+ if (IS_ERR_OR_NULL(rs->dma_tx.ch)) {
+ /* Check tx to see if we need defer probing driver */
+ if (rs->dma_tx.ch == ERR_PTR(-EPROBE_DEFER)) {
+ ret = -EPROBE_DEFER;
+ goto err_get_fifo_len;
+ }
dev_warn(rs->dev, "Failed to request TX DMA channel\n");
+ rs->dma_tx.ch = NULL;
+ }
...and then a similar patch for the "rx" side of things.
-Doug
RE: [f2fs-dev] [PATCH 1/2] f2fs: cover large section in sanity check of super
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, March 22, 2016 2:56 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim; stable 4 . 5+
> Subject: [f2fs-dev] [PATCH 1/2] f2fs: cover large section in sanity check of
> super
>
> This patch fixes the bug which does not cover a large section case when
> checking
> the sanity of superblock.
>
> Reported-by: Matthias Prager
> Reported-by: David Gnedt
> Cc: stable 4.5+
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/super.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 15bb81f..fc9147f 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -1000,6 +1000,7 @@ static inline bool sanity_check_area_boundary(struct
> super_block *sb,
> u32 segment_count_main = le32_to_cpu(raw_super->segment_count_main);
> u32 segment_count = le32_to_cpu(raw_super->segment_count);
> u32 log_blocks_per_seg = le32_to_cpu(raw_super->log_blocks_per_seg);
> + u32 segs_per_sec = le32_to_cpu(raw_super->segs_per_sec);
>
> if (segment0_blkaddr != cp_blkaddr) {
> f2fs_msg(sb, KERN_INFO,
> @@ -1044,12 +1045,26 @@ static inline bool sanity_check_area_boundary(struct
> super_block *sb,
> return true;
> }
>
> - if (main_blkaddr + (segment_count_main << log_blocks_per_seg) !=
> + if (segs_per_sec == 1 &&
> + main_blkaddr + (segment_count_main << log_blocks_per_seg) !=
> segment0_blkaddr + (segment_count << log_blocks_per_seg)) {
> f2fs_msg(sb, KERN_INFO,
> "Wrong MAIN_AREA boundary, start(%u) end(%u)
> blocks(%u)",
> main_blkaddr,
> - segment0_blkaddr + (segment_count <<
> log_blocks_per_seg),
> + segment0_blkaddr +
> + (segment_count << log_blocks_per_seg),
> + segment_count_main << log_blocks_per_seg);
> + return true;
> + }
> +
> + if (segs_per_sec > 1 &&
if ((segs_per_sec > 1 || secs_per_zone > 1)) && ?
Thanks,
> + main_blkaddr + (segment_count_main << log_blocks_per_seg) >
> + segment0_blkaddr + (segment_count << log_blocks_per_seg)) {
> + f2fs_msg(sb, KERN_INFO,
> + "Wrong MAIN_AREA boundary in large section, start(%u)
> end(%u) blocks(%u)",
> + main_blkaddr,
> + segment0_blkaddr +
> + (segment_count << log_blocks_per_seg),
> segment_count_main << log_blocks_per_seg);
> return true;
> }
> --
> 2.6.3
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [PATCH v2 3/5] dt-bindings: Add documentation for GM20B GPU
On 03/22/2016 10:41 AM, Rob Herring wrote:
On Sun, Mar 20, 2016 at 1:55 AM, Alexandre Courbot wrote:
On Sat, Mar 19, 2016 at 5:47 AM, Rob Herring wrote:
On Tue, Mar 15, 2016 at 11:58:42AM +0900, Alexandre Courbot wrote:
GM20B's definition is mostly similar to GK20A's, but requires an
additional clock.
[...]
gpu@0,5700 {
compatible = "nvidia,gk20a";
@@ -45,3 +49,22 @@ Example:
iommus = <&mc TEGRA_SWGROUP_GPU>;
status = "disabled";
};
+
+Example for GM20B:
+
+ gpu@0,5700 {
Drop the comma and leading zero.
Even though this is how it appears in the actual DT?
Yes, those will need to get fixed, too.
Sorry, I just want to confirm that I understand why this needs to be
fixed. The parent node has #address-cells = <2>, and the practice of
specifying two cells in the node name is consistent with what I see in
http://www.devicetree.org/Device_Tree_Usage.
However in the device tree usage example one can interpret the two cells
as being two different components of the address, whereas in our case we
are using two cells because the address is 64-bit - hence we should
specify it in the name as a single entity. Is this correct?
Thanks,
Alex.
Re: [PATCH] sound/usb: fix to release stream resources from media_snd_device_delete()
On 03/19/2016 07:31 AM, Shuah Khan wrote: > On 03/19/2016 06:10 AM, Mauro Carvalho Chehab wrote: >> Em Fri, 18 Mar 2016 20:50:31 -0600 >> Shuah Khan escreveu: >> >>> Fix to release stream resources from media_snd_device_delete() before >>> media device is unregistered. Without this change, stream resource free >>> is attempted after the media device is unregistered which would result >>> in use-after-free errors. >>> >>> Signed-off-by: Shuah Khan >>> --- >>> >>> - Ran bind/unbind loop (1000 iteration) test on snd-usb-audio >>> while running mc_nextgen_test loop (1000 iterations) in parallel. >>> - Ran bind/unbind and rmmod/modprobe tests on both drivers. Also >>> generated graphs when after bind/unbind, rmmod/modprobe. Graphs >>> look good. >>> - Note: Please apply the following patch to fix memory leak: >>> sound/usb: Fix memory leak in media_snd_stream_delete() during unbind >>> https://lkml.org/lkml/2016/3/16/1050 >> >> Yeah, a way better! >> >> For normal bind/unbind, it seems to be working fine. Also >> for driver's rmmod, so: >> >> Tested-by: Mauro Carvalho Chehab >> >> PS.: >> === >> >> There are still some troubles if we run an infinite loop >> binding/unbinding au0828 and another one binding/unbinding >> snd-usb-audio, like this one: > > Yes. I noticed this one when I was running a loop of 1000 on au0828. > I couldn't reproduce this when I tested this patch. > > P.S: au08282 loops takes longer btw since au0828 initialization is lot more > complex. We have to look at this one. > >> >> >> [ 91.556188] [ cut here ] >> [ 91.556500] WARNING: CPU: 1 PID: 2920 at drivers/media/media-entity.c:392 >> __media_entity_pipeline_start+0x271/0xce0 [media]() >> [ 91.556626] Modules linked in: ir_lirc_codec lirc_dev au8522_dig xc5000 >> tuner au8522_decoder au8522_common au0828 videobuf2_vmalloc videobuf2_memops >> videobuf2_v4l2 videobuf2_core tveeprom dvb_core rc_core v4l2_common videodev >> snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device media >> cpufreq_powersave cpufreq_conservative cpufreq_userspace cpufreq_stats >> parport_pc ppdev lp parport snd_hda_codec_hdmi intel_rapl >> x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iTCO_wdt kvm >> iTCO_vendor_support irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel >> ghash_clmulni_intel sha256_ssse3 sha256_generic hmac drbg >> snd_hda_codec_realtek i915 snd_hda_codec_generic aesni_intel aes_x86_64 >> btusb lrw btrtl gf128mul snd_hda_intel glue_helper ablk_helper btbcm btintel >> cryptd psmouse snd_hda_codec bluetooth >> [ 91.556693] snd_hwdep i2c_algo_bit sg snd_hda_core serio_raw pcspkr >> evdev drm_kms_helper snd_pcm rfkill drm snd_timer mei_me snd i2c_i801 >> soundcore lpc_ich mei mfd_core battery video dw_dmac i2c_designware_platform >> dw_dmac_core i2c_designware_core acpi_pad button tpm_tis tpm ext4 crc16 >> mbcache jbd2 dm_mod sd_mod hid_generic usbhid ahci libahci libata e1000e >> xhci_pci ptp scsi_mod ehci_pci ehci_hcd pps_core xhci_hcd fan thermal >> sdhci_acpi sdhci mmc_core i2c_hid hid >> [ 91.556748] CPU: 1 PID: 2920 Comm: v4l_id Tainted: G D W >> 4.5.0+ #62 >> [ 91.556751] Hardware name: /NUC5i7RYB, BIOS >> RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 >> [ 91.556754] a0e247a0 8803a3d17b08 819447c1 >> >> [ 91.556759] 88009bbe17c0 8803a3d17b48 8114fd16 >> a0e20651 >> [ 91.556763] 8803a47c9c58 8803a477d2c8 8803a5ac96f8 >> dc00 >> [ 91.556768] Call Trace: >> [ 91.556774] [] dump_stack+0x85/0xc4 >> [ 91.556778] [] warn_slowpath_common+0xc6/0x120 >> [ 91.556783] [] ? >> __media_entity_pipeline_start+0x271/0xce0 [media] >> [ 91.556786] [] warn_slowpath_null+0x1a/0x20 >> [ 91.556790] [] >> __media_entity_pipeline_start+0x271/0xce0 [media] >> [ 91.556794] [] ? __schedule+0x78a/0x2570 >> [ 91.556797] [] ? memset+0x28/0x30 >> [ 91.556802] [] ? media_entity_pipeline_stop+0x60/0x60 >> [media] >> [ 91.556806] [] ? trace_hardirqs_on+0xd/0x10 >> [ 91.556810] [] ? au0828_enable_source+0x55/0x9f0 >> [au0828] >> [ 91.556813] [] ? mutex_trylock+0x400/0x400 >> [ 91.556818] [] ? au0828_v4l2_close+0xb3/0x590 [au0828] >> [ 91.556822] [] au0828_enable_source+0x3f4/0x9f0 >> [au0828] >> [ 91.556824] [] ? mutex_trylock+0x400/0x400 >> [ 91.556834] [] v4l_enable_media_source+0x66/0x90 >> [videodev] >> [ 91.556839] [] au0828_v4l2_close+0x25a/0x590 [au0828] >> [ 91.556846] [] v4l2_release+0xf0/0x210 [videodev] >> [ 91.556849] [] __fput+0x20f/0x6d0 >> [ 91.556853] [] fput+0xe/0x10 >> [ 91.556856] [] task_work_run+0x137/0x200 >> [ 91.556859] [] exit_to_usermode_loop+0x154/0x180 >> [ 91.556863] [] ? trace_hardirqs_on_caller+0x16/0x590 >> [ 91.556866] [] syscall_return_slowpath+0x186/0x1c0 >> [ 91.556869] [] entry_SYSCALL_64_fastpath+0xbf/0xc1 >> [ 91.556872] ---[ end trace 3e95e11ff0b9ef
[PATCH] media: au0828 fix au0828_v4l2_close() dev_state race condition
au0828_v4l2_close() check for dev_state == DEV_DISCONNECTED will fail to
detect the device disconnected state correctly, if au0828_v4l2_open() runs
to set the DEV_INITIALIZED bit. A loop test of bind/unbind found this bug
by increasing the likelihood of au0828_v4l2_open() occurring while unbind
is in progress. When au0828_v4l2_close() fails to detect that the device
is in disconnect state, it attempts to power down the device and fails with
the following general protection fault:
[ 260.992962] Call Trace:
[ 260.993008] [] ? xc5000_sleep+0x8f/0xd0 [xc5000]
[ 260.993095] [] ? fe_standby+0x3c/0x50 [tuner]
[ 260.993186] [] au0828_v4l2_close+0x53c/0x620 [au0828]
[ 260.993298] [] v4l2_release+0xf0/0x210 [videodev]
[ 260.993382] [] __fput+0x1fc/0x6c0
[ 260.993449] [] fput+0xe/0x10
[ 260.993519] [] task_work_run+0x133/0x1f0
[ 260.993602] [] exit_to_usermode_loop+0x140/0x170
[ 260.993681] [] syscall_return_slowpath+0x16a/0x1a0
[ 260.993754] [] entry_SYSCALL_64_fastpath+0xa6/0xa8
Signed-off-by: Shuah Khan
---
drivers/media/usb/au0828/au0828-video.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/au0828/au0828-video.c
b/drivers/media/usb/au0828/au0828-video.c
index 13f6dab..88dcc6e 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -1075,7 +1075,7 @@ static int au0828_v4l2_close(struct file *filp)
del_timer_sync(&dev->vbi_timeout);
}
- if (dev->dev_state == DEV_DISCONNECTED)
+ if (dev->dev_state & DEV_DISCONNECTED)
goto end;
if (dev->users == 1) {
--
2.5.0
[PATCH v2] mwifiex: advertise low priority scan feature
From: Amitkumar Karwar Low priority scan handling code which delays or aborts scan operation based on Tx traffic is removed recently. The reason is firmware already takes care of it in our new feature scan channel gap. Hence we should advertise low priority scan support to cfg80211. This patch fixes a problem in which OBSS scan request from wpa_supplicant was being rejected by cfg80211. Signed-off-by: Amitkumar Karwar Signed-off-by: Wei-Ning Huang --- drivers/net/wireless/marvell/mwifiex/cfg80211.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c index bb7235e..7dafc5b 100644 --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c @@ -4086,6 +4086,7 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter) wiphy->features |= NL80211_FEATURE_HT_IBSS | NL80211_FEATURE_INACTIVITY_TIMER | + NL80211_FEATURE_LOW_PRIORITY_SCAN | NL80211_FEATURE_NEED_OBSS_SCAN; if (ISSUPP_TDLS_ENABLED(adapter->fw_cap_info)) -- 2.8.0.rc3.226.g39d4020
Re: [PATCH] mwifiex: advertise low priority scan feature
Hi Kalle, Thanks for the review. I accidentally removed the s-o-b line from akarwar in this version. The original patch can be found at: https://chromium-review.googlesource.com/#/c/246052/ I've resent a new one. Wei-Ning On Mon, Mar 21, 2016 at 6:28 PM, Kalle Valo wrote: > Wei-Ning Huang writes: > >> From: Amitkumar Karwar >> >> Low priority scan handling code which delays or aborts scan >> operation based on Tx traffic is removed recently. The reason >> is firmware already takes care of it in our new feature scan >> channel gap. Hence we should advertise low priority scan >> support to cfg80211. >> >> This patch fixes a problem in which OBSS scan request from >> wpa_supplicant was being rejected by cfg80211. >> >> Signed-off-by: Wei-Ning Huang > > The From line states that this is written by Amitkumar but there's no > Signed-off-By line from him. I can't take this without that, please > resend. > > (Wei-Ning's s-o-b line is correct, I just need also Amitkumar's line.) > > -- > Kalle Valo -- Wei-Ning Huang, 黃偉寧 | Software Engineer, Google Inc., Taiwan | wnhu...@google.com | Cell: +886 910-380678
Re: [PATCH v2] mwifiex: advertise low priority scan feature
Tested-by: Wei-Ning Huang On Tue, Mar 22, 2016 at 12:09 PM, Wei-Ning Huang wrote: > From: Amitkumar Karwar > > Low priority scan handling code which delays or aborts scan > operation based on Tx traffic is removed recently. The reason > is firmware already takes care of it in our new feature scan > channel gap. Hence we should advertise low priority scan > support to cfg80211. > > This patch fixes a problem in which OBSS scan request from > wpa_supplicant was being rejected by cfg80211. > > Signed-off-by: Amitkumar Karwar > Signed-off-by: Wei-Ning Huang > --- > drivers/net/wireless/marvell/mwifiex/cfg80211.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c > b/drivers/net/wireless/marvell/mwifiex/cfg80211.c > index bb7235e..7dafc5b 100644 > --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c > +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c > @@ -4086,6 +4086,7 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter > *adapter) > > wiphy->features |= NL80211_FEATURE_HT_IBSS | >NL80211_FEATURE_INACTIVITY_TIMER | > + NL80211_FEATURE_LOW_PRIORITY_SCAN | >NL80211_FEATURE_NEED_OBSS_SCAN; > > if (ISSUPP_TDLS_ENABLED(adapter->fw_cap_info)) > -- > 2.8.0.rc3.226.g39d4020 > -- Wei-Ning Huang, 黃偉寧 | Software Engineer, Google Inc., Taiwan | wnhu...@google.com | Cell: +886 910-380678
[PATCH] tpm: drop int_queue from tpm_vendor_specific
Drop field int_queue from tpm_vendor_specific as it is used only by
tpm_tis. Probably all of the fields should be eventually dropped and
moved to the private structures of different drivers but it is better to
do this one step at a time in order not to break anything.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm.h | 1 -
drivers/char/tpm/tpm_i2c_nuvoton.c | 1 -
drivers/char/tpm/tpm_tis.c | 19 ---
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index f197eef..4764545 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -148,7 +148,6 @@ struct tpm_vendor_specific {
void *priv;
wait_queue_head_t read_queue;
- wait_queue_head_t int_queue;
u16 manufacturer_id;
};
diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c
b/drivers/char/tpm/tpm_i2c_nuvoton.c
index d61d43f..a43b5f3 100644
--- a/drivers/char/tpm/tpm_i2c_nuvoton.c
+++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
@@ -540,7 +540,6 @@ static int i2c_nuvoton_probe(struct i2c_client *client,
return -ENOMEM;
init_waitqueue_head(&chip->vendor.read_queue);
- init_waitqueue_head(&chip->vendor.int_queue);
/* Default timeouts */
chip->vendor.timeout_a = msecs_to_jiffies(TPM_I2C_SHORT_TIMEOUT);
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index eed3bf5..7d7a776 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -95,6 +95,7 @@ struct tpm_info {
struct priv_data {
bool irq_tested;
+ wait_queue_head_t int_queue;
};
#if defined(CONFIG_PNP) && defined(CONFIG_ACPI)
@@ -157,6 +158,7 @@ static void release_locality(struct tpm_chip *chip, int l,
int force)
static int request_locality(struct tpm_chip *chip, int l)
{
+ struct priv_data *priv = chip->vendor.priv;
unsigned long stop, timeout;
long rc;
@@ -173,7 +175,7 @@ again:
timeout = stop - jiffies;
if ((long)timeout <= 0)
return -1;
- rc = wait_event_interruptible_timeout(chip->vendor.int_queue,
+ rc = wait_event_interruptible_timeout(priv->int_queue,
(check_locality
(chip, l) >= 0),
timeout);
@@ -249,6 +251,7 @@ static int recv_data(struct tpm_chip *chip, u8 *buf, size_t
count)
static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, size_t count)
{
+ struct priv_data *priv = chip->vendor.priv;
int size = 0;
int expected, status;
@@ -279,7 +282,7 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf,
size_t count)
}
wait_for_tpm_stat(chip, TPM_STS_VALID, chip->vendor.timeout_c,
- &chip->vendor.int_queue, false);
+ &priv->int_queue, false);
status = tpm_tis_status(chip);
if (status & TPM_STS_DATA_AVAIL) { /* retry? */
dev_err(&chip->dev, "Error left over data\n");
@@ -304,6 +307,7 @@ MODULE_PARM_DESC(itpm, "Force iTPM workarounds (found on
some Lenovo laptops)");
*/
static int tpm_tis_send_data(struct tpm_chip *chip, u8 *buf, size_t len)
{
+ struct priv_data *priv = chip->vendor.priv;
int rc, status, burstcnt;
size_t count = 0;
@@ -315,7 +319,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8
*buf, size_t len)
tpm_tis_ready(chip);
if (wait_for_tpm_stat
(chip, TPM_STS_COMMAND_READY, chip->vendor.timeout_b,
-&chip->vendor.int_queue, false) < 0) {
+&priv->int_queue, false) < 0) {
rc = -ETIME;
goto out_err;
}
@@ -330,7 +334,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8
*buf, size_t len)
}
wait_for_tpm_stat(chip, TPM_STS_VALID, chip->vendor.timeout_c,
- &chip->vendor.int_queue, false);
+ &priv->int_queue, false);
status = tpm_tis_status(chip);
if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
rc = -EIO;
@@ -342,7 +346,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8
*buf, size_t len)
iowrite8(buf[count],
chip->vendor.iobase + TPM_DATA_FIFO(chip->vendor.locality));
wait_for_tpm_stat(chip, TPM_STS_VALID, chip->vendor.timeout_c,
- &chip->vendor.int_queue, false);
+ &priv->int_queue, false);
status = tpm_tis_status(chip);
if ((status & TPM_STS_DATA_EXPECT) != 0) {
rc = -EIO;
@@ -537,6 +541,7 @@ static const struct tpm_class_ops tpm_tis = {
static irqreturn_t tis_int_handler(i
Re: [PATCH] cpufreq: governor: Always schedule work on the CPU running update
On Tue, 2016-03-22 at 08:21 +0530, Viresh Kumar wrote: > On 22-03-16, 01:17, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Modify dbs_irq_work() to always schedule the process-context work > > on the current CPU which also ran the dbs_update_util_handler() > > that the irq_work being handled came from. > > > > This causes the entire frequency update handling (involving the > > "ondemand" or "conservative" governors) to be carried out by the > > CPU whose frequency is to be updated and reduces the overall amount > > of inter-CPU noise related to cpufreq. > > > > Signed-off-by: Rafael J. Wysocki > > --- > > drivers/cpufreq/cpufreq_governor.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Index: linux-pm/drivers/cpufreq/cpufreq_governor.c > > === > > --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c > > +++ linux-pm/drivers/cpufreq/cpufreq_governor.c > > @@ -245,7 +245,7 @@ static void dbs_irq_work(struct irq_work > > struct policy_dbs_info *policy_dbs; > > > > policy_dbs = container_of(irq_work, > > structwq_unbound_cpumask policy_dbs_info, irq_work); > > - schedule_work(&policy_dbs->work); > > + schedule_work_on(smp_processor_id(), &policy_dbs->work); > > } > > > > static void dbs_update_util_handler(struct update_util_data *data, > > u64 time, > > queue_work() used to queue the work on local cpu by default, has that > changed now ? By default it still will, but the user now has the option to deflect work items with an unspecified target. These will land on a CPU included in wq_unbound_cpumask iff the current CPU is excluded therefrom. -Mike
Re: [PATCH RESEND v2 00/14] lib/mpi: bug fixes and cleanup
Hi Nicolai,
On 03/21/2016 06:26 AM, Nicolai Stange wrote:
> This is a resend of v2 with the crypto people properly CC'd.
>
> The original v1 can be found here:
>
>
> http://lkml.kernel.org/g/1458237606-4954-1-git-send-email-nicsta...@gmail.com
>
>
> While v1 (hopefully) fixed some issues in mpi_write_sgl() and
> mpi_read_buffer() introduced by
> commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") and by
> commit 9cbe21d8f89d ("lib/mpi: only require buffers as big as needed for
> the integer"),
> I missed that there are some, including out-of-bounds buffer accesses,
> in mpi_read_raw_from_sgl() as well.
>
> Hence v2, which includes the original stuff from v1 plus my new fixes to
> mpi_read_raw_from_sgl().
>
>
> Applicable to linux-next-20160318.
>
>
> Changes to v1:
> - [1-8/14]
> former [1-8/8], unchanged.
>
> - [9-14/14]
> Added in v2. Fixes to mpi_read_raw_from_sgl().
>
> Nicolai Stange (14):
> lib/mpi: mpi_write_sgl(): fix skipping of leading zero limbs
> lib/mpi: mpi_write_sgl(): fix style issue with lzero decrement
> lib/mpi: mpi_write_sgl(): purge redundant pointer arithmetic
> lib/mpi: mpi_write_sgl(): fix out-of-bounds stack access
> lib/mpi: mpi_write_sgl(): replace open coded endian conversion
> lib/mpi: mpi_read_buffer(): optimize skipping of leading zero limbs
> lib/mpi: mpi_read_buffer(): replace open coded endian conversion
> lib/mpi: mpi_read_buffer(): fix buffer overflow
> lib/mpi: mpi_read_raw_from_sgl(): replace len argument by nbytes
> lib/mpi: mpi_read_raw_from_sgl(): don't include leading zero SGEs in
> nbytes
> lib/mpi: mpi_read_raw_from_sgl(): purge redundant clearing of nbits
> lib/mpi: mpi_read_raw_from_sgl(): fix nbits calculation
> lib/mpi: mpi_read_raw_from_sgl(): sanitize meaning of indices
> lib/mpi: mpi_read_raw_from_sgl(): fix out-of-bounds buffer access
>
> lib/mpi/mpicoder.c | 122
> +++--
> 1 file changed, 43 insertions(+), 79 deletions(-)
Thanks for sending this. Nice work. In fact the mpi_write_sgl() function
worked only because the mpi_normalize() stripped all MSB zero limbs.
Given that this will hold for all cases we can simplify this even more.
Unfortunately I don't know if this will be true for mpi_sub() or
mpi_set_ui() because they are declared in include/linux/mpi.h,
but never defined anywhere.
I've found one problem in 08/14 in mpi_read_buffer()
It's a pointer arithmetic issue, which causes the first limb to be
written at an invalid address if lzeros > 0. This incremental patch
fixes it.
---8<---
Subject: [PATCH] lib/mpi: fix pointer arithmetic issue in mpi_read_buffer
Fix pointer arithmetic issue, which causes the first limb to be
written at invalid address if lzeros > 0.
Signed-off-by: Tadeusz Struk
---
lib/mpi/mpicoder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index 0c534ac..747606f 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -201,7 +201,7 @@ int mpi_read_buffer(MPI a, uint8_t *buf, unsigned buf_len,
unsigned *nbytes,
#else
#error please implement for this limb size.
#endif
- memcpy(p, &alimb + lzeros, BYTES_PER_MPI_LIMB - lzeros);
+ memcpy(p, (u8 *)&alimb + lzeros, BYTES_PER_MPI_LIMB - lzeros);
p += BYTES_PER_MPI_LIMB - lzeros;
lzeros = 0;
}
---
Other than that please include my
Tested-by: Tadeusz Struk
for the whole series.
Thanks,
--
TS
Re: [PATCH 1/6] mm/page_alloc: fix same zone check in __pageblock_pfn_to_page()
On Mon, Mar 21, 2016 at 11:37:19AM +, Mel Gorman wrote: > On Mon, Mar 14, 2016 at 04:31:32PM +0900, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > There is a system that node's pfn are overlapped like as following. > > > > -pfn> > > N0 N1 N2 N0 N1 N2 > > > > Therefore, we need to care this overlapping when iterating pfn range. > > > > In __pageblock_pfn_to_page(), there is a check for this but it's > > not sufficient. This check cannot distinguish the case that zone id > > is the same but node id is different. This patch fixes it. > > > > I think you may be mixing up page_zone_id with page_zonenum. Oops... Indeed. I will drop the patch. Thanks for catching it. :) Thanks.
Re: [PATCH] zram: revive swap_slot_free_notify
On Fri, Mar 18, 2016 at 04:58:31PM +0900, Minchan Kim wrote:
> "remove compressed copy from zram in-memory"
> applied swap_slot_free_notify call in *end_swap_bio_read* to
> remove duplicated memory between zram and memory.
>
> However, with introducing rw_page in zram <8c7f01025f7b>
> "zram: implement rw_page operation of zram", it became void
> because rw_page doesn't need bio.
>
> This patch restores the function for rw_page.
>
> Signed-off-by: Minchan Kim
> ---
> mm/page_io.c | 93
>
> 1 file changed, 50 insertions(+), 43 deletions(-)
>
> diff --git a/mm/page_io.c b/mm/page_io.c
> index ff74e512f029..18aac7819cc9 100644
> --- a/mm/page_io.c
> +++ b/mm/page_io.c
> @@ -66,6 +66,54 @@ void end_swap_bio_write(struct bio *bio)
> bio_put(bio);
> }
>
> +static void swap_slot_free_notify(struct page *page)
> +{
> + struct swap_info_struct *sis;
> + struct gendisk *disk;
> +
> + /*
> + * There is no guarantee that the page is in swap cache - the software
> + * suspend code (at least) uses end_swap_bio_read() against a non-
> + * swapcache page. So we must check PG_swapcache before proceeding with
> + * this optimization.
> + */
> + if (unlikely(!PageSwapCache(page)))
> + return;
> +
> + sis = page_swap_info(page);
> + if (!(sis->flags & SWP_BLKDEV))
> + return;
> +
> + /*
> + * The swap subsystem performs lazy swap slot freeing,
> + * expecting that the page will be swapped out again.
> + * So we can avoid an unnecessary write if the page
> + * isn't redirtied.
> + * This is good for real swap storage because we can
> + * reduce unnecessary I/O and enhance wear-leveling
> + * if an SSD is used as the as swap device.
> + * But if in-memory swap device (eg zram) is used,
> + * this causes a duplicated copy between uncompressed
> + * data in VM-owned memory and compressed data in
> + * zram-owned memory. So let's free zram-owned memory
> + * and make the VM-owned decompressed page *dirty*,
> + * so the page should be swapped out somewhere again if
> + * we again wish to reclaim it.
> + */
> + disk = sis->bdev->bd_disk;
> + if (disk->fops->swap_slot_free_notify) {
> + swp_entry_t entry;
> + unsigned long offset;
> +
> + entry.val = page_private(page);
> + offset = swp_offset(entry);
> +
> + SetPageDirty(page);
> + disk->fops->swap_slot_free_notify(sis->bdev,
> + offset);
> + }
> +}
> +
> static void end_swap_bio_read(struct bio *bio)
> {
> struct page *page = bio->bi_io_vec[0].bv_page;
> @@ -81,49 +129,7 @@ static void end_swap_bio_read(struct bio *bio)
> }
>
> SetPageUptodate(page);
> -
> - /*
> - * There is no guarantee that the page is in swap cache - the software
> - * suspend code (at least) uses end_swap_bio_read() against a non-
> - * swapcache page. So we must check PG_swapcache before proceeding with
> - * this optimization.
> - */
> - if (likely(PageSwapCache(page))) {
> - struct swap_info_struct *sis;
> -
> - sis = page_swap_info(page);
> - if (sis->flags & SWP_BLKDEV) {
> - /*
> - * The swap subsystem performs lazy swap slot freeing,
> - * expecting that the page will be swapped out again.
> - * So we can avoid an unnecessary write if the page
> - * isn't redirtied.
> - * This is good for real swap storage because we can
> - * reduce unnecessary I/O and enhance wear-leveling
> - * if an SSD is used as the as swap device.
> - * But if in-memory swap device (eg zram) is used,
> - * this causes a duplicated copy between uncompressed
> - * data in VM-owned memory and compressed data in
> - * zram-owned memory. So let's free zram-owned memory
> - * and make the VM-owned decompressed page *dirty*,
> - * so the page should be swapped out somewhere again if
> - * we again wish to reclaim it.
> - */
> - struct gendisk *disk = sis->bdev->bd_disk;
> - if (disk->fops->swap_slot_free_notify) {
> - swp_entry_t entry;
> - unsigned long offset;
> -
> - entry.val = page_private(page);
> - offset = swp_offset(entry);
> -
> - SetPageDirty(page);
> - disk->fops->swap_slot_free_notify(sis->bdev,
> - offset);
> -
Re: [PATCH v6 0/3] thermal: mediatek: Add cpu dynamic power cooling model.
On Tue, 2016-03-15 at 13:17 +0700, Viresh Kumar wrote: > On 15-03-16, 12:53, dawei chien wrote: > > On Thu, 2015-12-17 at 09:52 +0800, Viresh Kumar wrote: > > > On 16-12-15, 21:29, Dawei Chien wrote: > > > > Use Intelligent Power Allocation (IPA) technical to add dynamic power > > > > model > > > > for binding CPU thermal zone. The power allocator governor allocates > > > > power > > > > budget to control CPU temperature. > > > > > > > > Power Allocator governor is able to keep SOC temperature within a > > > > defined > > > > temperature range to avoid SOC overheat and keep it's performance. > > > > mt8173-cpufreq.c need to register its' own power model with power > > > > allocator > > > > thermal governor, so that power allocator governor can allocates > > > > suitable > > > > power budget to control CPU temperature. > > > > > > > > Binding document is refer to this patchset > > > > https://lkml.org/lkml/2015/11/30/239 > > > > > > > > Change since V5: > > > > 1. Remove thermal sensor ID from phandles > > > > > > Though you should have included this in the new version, but still > > > > > > Acked-by: Viresh Kumar > > > > > > -- > > > viresh > > > > Hi Viresh, > > Would you please pull this patch to your tree since following patch > > already pulled in, thank you. > > > > https://lkml.org/lkml/2015/11/30/239 > > Its Rafael, who is going to apply this one. > > Can you please resend it as he may not have it in patchworks? > Hi Rafael, Would you merge this patch to your tee, thank you. BR, Dawei
Re: Build error due to commit 458aa76d132dc ("mm/thp/migration: switch from flush_tlb_range to flush_pmd_tlb_range")
Guenter Roeck writes:
> [ text/plain ]
> Hi,
>
> Your commit 458aa76d132dc1 ("mm/thp/migration: switch from flush_tlb_range
> to flush_pmd_tlb_range") causes a build error when building
> arcv2:vdk_hs38_smp_defconfig.
>
> include/asm-generic/pgtable.h:799:45: note: in expansion of macro ‘BUILD_BUG’
> #define flush_pmd_tlb_range(vma, addr, end) BUILD_BUG()
> ^
> ./arch/arc/include/asm/tlbflush.h:37:13: note:
> in expansion of macro ‘flush_pmd_tlb_range’
>
> The build triggers the newly introduced BUILD_BUG().
>
> When building the image without the BUILD_BUG(), ie with no definition
> of flush_pmd_tlb_range(), the problem is gone. This suggests that the
> function is not needed for this build.
>
> I could submit a patch to remove the BUILD_BUG(), but maybe you had a reason
> for introducing it. Can you elaborate why you introduced the BUILD_BUG() ?
>
Isn't this going to be fixed by an update to ARC tree ?
http://article.gmane.org/gmane.linux.kernel.mm/148412
I also don't understand why we would hit that BUILD_BUG, if we are not
calling flush_pmd_tlb_range().
-aneesh
RE: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout
> -Original Message-
> From: Mathias Nyman [mailto:mathias.ny...@intel.com]
> Sent: Monday, March 21, 2016 2:46 PM
> To: Rajesh Bhagat ; Mathias Nyman
> ; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: gre...@linuxfoundation.org; Sriram Dash
> Subject: Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI
> commmand timeout
>
> On 21.03.2016 06:18, Rajesh Bhagat wrote:
> >
> >
> >>
> >> Hi
> >>
> >> I think clearing the whole command ring is a bit too much in this case.
> >> It may cause issues for all attached devices when one command times out.
> >>
> >
> > Hi Mathias,
> >
> > I understand your point, But I want to understand how would completion
> > handler be called if a command is timed out and xhci_abort_cmd_ring is
> > successful. In this case all the code would be waiting on completion
> > handler forever.
> >
> >
> > 2. xhci_handle_command_timeout -> xhci_abort_cmd_ring(failure) ->
> > xhci_cleanup_command_queue -> xhci_complete_del_and_free_cmd
> >
> > In our case command is timed out, Hence we hit the case #2 but
> > xhci_abort_cmd_ring is success which does not calls complete.
>
> xhci_abort_cmd_ring() will write CA bit (CMD_RING_ABORT) to CRCR register.
> This will generate a command completion event with status "command aborted"
> for
> the pending command.
> This event is then followed by a "command ring stopped" command completion
> event.
>
> See xHCI specs 5.4.5 and 4.6.1.2
>
> handle_cmd_completion() will check if cmd_comp_code == COMP_CMD_ABORT, goto
> event_handled, and call xhci_complete_del_and_free_cmd(cmd, cmd_comp_code) for
> the aborted command.
>
> If xHCI already processed the aborted command, we might only get a command
> ring
> stopped event, in this case handle_cmd_completion() will call
> xhci_handle_stopped_cmd_ring(xhci, cmd), which will turn the commands that
> were
> tagged for "abort" that still remain on the command ring to NO-OP commands.
>
> The completion callback will be called for these NO-OP command later when we
> get a
> command completion event for them.
>
Thanks Mathias for detailed explanation. Now I understand how completion
handler is
supposed to be called in this scenario.
But in our case, somehow we are not getting any event and handle_cmd_completion
function
is not getting called even after successful xhci_abort_cmd_ring when command
timed out.
Now, my point here is code prior to this patch xhci: rework command timeout and
cancellation,
Code would have returned in case command timed out in xhci_alloc_dev itself.
- /* XXX: how much time for xHC slot assignment? */
- timeleft = wait_for_completion_interruptible_timeout(
- command->completion,
- XHCI_CMD_DEFAULT_TIMEOUT);
- if (timeleft <= 0) {
- xhci_warn(xhci, "%s while waiting for a slot\n",
- timeleft == 0 ? "Timeout" : "Signal");
- /* cancel the enable slot request */
- ret = xhci_cancel_cmd(xhci, NULL, command->command_trb);
- return ret;
- }
+ wait_for_completion(command->completion);
But after this patch, we are waiting for hardware event, which is somehow not
generated
and causing a hang scenario.
IMO, The assumption that "xhci_abort_cmd_ring would always generate an event
and handle_cmd_completion would be called" will not be always be true if HW is
in bad state.
Please share your opinion.
> >> What kernel version, and what xhci vendor was this triggered on?
> >>
> >
> > We are using 4.1.8 kernel
> >
>
> Are you able to try a more recent version?
>
Using a newer kernel version would be bit difficult, but I would surely try it.
> -Mathias
RE: [f2fs-dev] [PATCH v2] f2fs: fix to convert inline directory correctly
Ping, Any problem in this patch? Thanks, > -Original Message- > From: Chao Yu [mailto:chao2...@samsung.com] > Sent: Monday, February 22, 2016 6:29 PM > To: Jaegeuk Kim > Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net > Subject: [f2fs-dev] [PATCH v2] f2fs: fix to convert inline directory correctly
Re: [PATCH 31/71] exofs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros
On 03/20/2016 08:40 PM, Kirill A. Shutemov wrote:
> PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time ago
> with promise that one day it will be possible to implement page cache with
> bigger chunks than PAGE_SIZE.
>
> This promise never materialized. And unlikely will.
>
> We have many places where PAGE_CACHE_SIZE assumed to be equal to
> PAGE_SIZE. And it's constant source of confusion on whether PAGE_CACHE_*
> or PAGE_* constant should be used in a particular case, especially on the
> border between fs and mm.
>
> Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
> breakage to be doable.
>
> Let's stop pretending that pages in page cache are special. They are not.
>
> The changes are pretty straight-forward:
>
> - << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> ;
>
> - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
>
> - page_cache_get() -> get_page();
>
> - page_cache_release() -> put_page();
>
> Signed-off-by: Kirill A. Shutemov
> Cc: Boaz Harrosh
ACK-by: Boaz Harrosh
Could you please push this through some other maintainer perhaps
the vfs tree?
Thank you Kirill
Boaz
> Cc: Benny Halevy
> ---
> fs/exofs/dir.c | 30 +++---
> fs/exofs/inode.c | 34 +-
> fs/exofs/namei.c | 4 ++--
> 3 files changed, 34 insertions(+), 34 deletions(-)
>
> diff --git a/fs/exofs/dir.c b/fs/exofs/dir.c
> index e5bb2abf77f9..547b93cbea63 100644
> --- a/fs/exofs/dir.c
> +++ b/fs/exofs/dir.c
> @@ -41,16 +41,16 @@ static inline unsigned exofs_chunk_size(struct inode
> *inode)
> static inline void exofs_put_page(struct page *page)
> {
> kunmap(page);
> - page_cache_release(page);
> + put_page(page);
> }
>
> static unsigned exofs_last_byte(struct inode *inode, unsigned long page_nr)
> {
> loff_t last_byte = inode->i_size;
>
> - last_byte -= page_nr << PAGE_CACHE_SHIFT;
> - if (last_byte > PAGE_CACHE_SIZE)
> - last_byte = PAGE_CACHE_SIZE;
> + last_byte -= page_nr << PAGE_SHIFT;
> + if (last_byte > PAGE_SIZE)
> + last_byte = PAGE_SIZE;
> return last_byte;
> }
>
> @@ -85,13 +85,13 @@ static void exofs_check_page(struct page *page)
> unsigned chunk_size = exofs_chunk_size(dir);
> char *kaddr = page_address(page);
> unsigned offs, rec_len;
> - unsigned limit = PAGE_CACHE_SIZE;
> + unsigned limit = PAGE_SIZE;
> struct exofs_dir_entry *p;
> char *error;
>
> /* if the page is the last one in the directory */
> - if ((dir->i_size >> PAGE_CACHE_SHIFT) == page->index) {
> - limit = dir->i_size & ~PAGE_CACHE_MASK;
> + if ((dir->i_size >> PAGE_SHIFT) == page->index) {
> + limit = dir->i_size & ~PAGE_MASK;
> if (limit & (chunk_size - 1))
> goto Ebadsize;
> if (!limit)
> @@ -138,7 +138,7 @@ bad_entry:
> EXOFS_ERR(
> "ERROR [exofs_check_page]: bad entry in directory(0x%lx): %s - "
> "offset=%lu, inode=0x%llu, rec_len=%d, name_len=%d\n",
> - dir->i_ino, error, (page->index< + dir->i_ino, error, (page->index< _LLU(le64_to_cpu(p->inode_no)),
> rec_len, p->name_len);
> goto fail;
> @@ -147,7 +147,7 @@ Eend:
> EXOFS_ERR("ERROR [exofs_check_page]: "
> "entry in directory(0x%lx) spans the page boundary"
> "offset=%lu, inode=0x%llx\n",
> - dir->i_ino, (page->index< + dir->i_ino, (page->index< _LLU(le64_to_cpu(p->inode_no)));
> fail:
> SetPageChecked(page);
> @@ -237,8 +237,8 @@ exofs_readdir(struct file *file, struct dir_context *ctx)
> {
> loff_t pos = ctx->pos;
> struct inode *inode = file_inode(file);
> - unsigned int offset = pos & ~PAGE_CACHE_MASK;
> - unsigned long n = pos >> PAGE_CACHE_SHIFT;
> + unsigned int offset = pos & ~PAGE_MASK;
> + unsigned long n = pos >> PAGE_SHIFT;
> unsigned long npages = dir_pages(inode);
> unsigned chunk_mask = ~(exofs_chunk_size(inode)-1);
> int need_revalidate = (file->f_version != inode->i_version);
> @@ -254,7 +254,7 @@ exofs_readdir(struct file *file, struct dir_context *ctx)
> if (IS_ERR(page)) {
> EXOFS_ERR("ERROR: bad page in directory(0x%lx)\n",
> inode->i_ino);
> - ctx->pos += PAGE_CACHE_SIZE - offset;
> + ctx->pos += PAGE_SIZE - offset;
> return PTR_ERR(page);
> }
> kaddr = page_address(page);
> @@ -262,7 +262,7 @@ exofs_readdir(struct file *file, struct dir_context *ctx)
> if (offset) {
> offset = exofs_validate_entry(kaddr, offset,
> chunk_mask);
> - ctx->pos = (n
Re: [BUG] packet loss with PROVE_LOCKING, bisected to EDAC fix
On Mon, Mar 21, 2016 at 09:42:09PM +, Chris Bainbridge wrote: > Hi, > > I was testing something on an old server (Dell T105 opteron) and noticed > packet loss after updating the kernel from 3.10 to 4.5. The test was: > > On Dell run: iperf -s > On another system: iperf3 -c dell -u -b 20M -l 1k -t 1000 > > This sends a 20mbit UDP stream to the Dell. It works fine normally (0% > packet loss), but when CONFIG_PROVE_LOCKING is enabled there is high > (35%) packet loss. (DEBUG_LOCKDEP also seems to cause packet loss) > > The packet loss bisected back to: > > commit 88d84ac97378c2f1d5fec9af1e8b7d9a662d6b00 > Author: Borislav Petkov > Date: Fri Jul 19 12:28:25 2013 +0200 > > EDAC: Fix lockdep splat Hmm, how would that cause a packet loss?! > I have confirmed that the commit preceding this (v3.11-rc1) is fine and > that 88d84a introduced the bug. Did you revert this commit ontop of 4.5 and reproduce again? Do you see the same packet loss? What kind of hw is that target system, can you send full dmesg and .config? Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
Re: Nonterministic hang during bootconsole/console handover on ath79
On Tue, 22 Mar 2016 00:02:57 +0100 Matthias Schiffer wrote: > Hi, > we're experiencing weird nondeterministic hangs during bootconsole/console > handover on some ath79 systems on OpenWrt. I've seen this issue myself on > kernel 3.18.23~3.18.27 on a AR7241-based system, but according to other > reports ([1], [2]) kernel 4.1.x is affected as well, and other SoCs like > QCA953x likewise. > > See the log below for the exact place it hangs; the log was taken in during > a good boot; a bad boot will just hang forever at the marked location. The > issue is extremely hard to debug, as changing the timing in any way (like > adding additional printk) will usually make it work without problems. (Even > recompiling the kernel with the same config, but different uname timestamp > will make the occurence more or less likely) > > My theory is the following: > > As soon as ttyS0 is detected and installed as the console, there are two > console drivers active on the serial port at the same time: early0 and > ttyS0. I suspect that the hang occurs when the primitive early0 > implementation prom_putchar_ar71xx waits indefinitely on THRE, Can you use EJTAG to prove your theory? -- Best regards, Antony Pavlov
Re: [PATCH v2 13/18] mm/compaction: support non-lru movable page migration
On Mon, Mar 21, 2016 at 03:31:02PM +0900, Minchan Kim wrote:
> We have allowed migration for only LRU pages until now and it was
> enough to make high-order pages. But recently, embedded system(e.g.,
> webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory)
> so we have seen several reports about troubles of small high-order
> allocation. For fixing the problem, there were several efforts
> (e,g,. enhance compaction algorithm, SLUB fallback to 0-order page,
> reserved memory, vmalloc and so on) but if there are lots of
> non-movable pages in system, their solutions are void in the long run.
>
> So, this patch is to support facility to change non-movable pages
> with movable. For the feature, this patch introduces functions related
> to migration to address_space_operations as well as some page flags.
>
> Basically, this patch supports two page-flags and two functions related
> to page migration. The flag and page->mapping stability are protected
> by PG_lock.
>
> PG_movable
> PG_isolated
>
> bool (*isolate_page) (struct page *, isolate_mode_t);
> void (*putback_page) (struct page *);
>
> Duty of subsystem want to make their pages as migratable are
> as follows:
>
> 1. It should register address_space to page->mapping then mark
> the page as PG_movable via __SetPageMovable.
>
> 2. It should mark the page as PG_isolated via SetPageIsolated
> if isolation is sucessful and return true.
>
> 3. If migration is successful, it should clear PG_isolated and
> PG_movable of the page for free preparation then release the
> reference of the page to free.
>
> 4. If migration fails, putback function of subsystem should
> clear PG_isolated via ClearPageIsolated.
I think that this feature needs a separate document to describe
requirement of each step in more detail. For example, #1 can be
possible without holding a lock? I'm not sure because you lock
the page when implementing zsmalloc page migration in 15th patch.
#3 also need more explanation. Before release, we need to
unregister address_space. I guess that it needs to be done
in migratepage() but there is no explanation.
>
> Cc: Vlastimil Babka
> Cc: Mel Gorman
> Cc: Hugh Dickins
> Cc: dri-de...@lists.freedesktop.org
> Cc: virtualizat...@lists.linux-foundation.org
> Signed-off-by: Gioh Kim
> Signed-off-by: Minchan Kim
> ---
> Documentation/filesystems/Locking | 4 +
> Documentation/filesystems/vfs.txt | 5 ++
> fs/proc/page.c | 3 +
> include/linux/fs.h | 2 +
> include/linux/migrate.h| 2 +
> include/linux/page-flags.h | 29
> include/uapi/linux/kernel-page-flags.h | 1 +
> mm/compaction.c| 14 +++-
> mm/migrate.c | 132
> +
> 9 files changed, 177 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/filesystems/Locking
> b/Documentation/filesystems/Locking
> index 619af9bfdcb3..0bb79560abb3 100644
> --- a/Documentation/filesystems/Locking
> +++ b/Documentation/filesystems/Locking
> @@ -195,7 +195,9 @@ unlocks and drops the reference.
> int (*releasepage) (struct page *, int);
> void (*freepage)(struct page *);
> int (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t offset);
> + bool (*isolate_page) (struct page *, isolate_mode_t);
> int (*migratepage)(struct address_space *, struct page *, struct page
> *);
> + void (*putback_page) (struct page *);
> int (*launder_page)(struct page *);
> int (*is_partially_uptodate)(struct page *, unsigned long, unsigned
> long);
> int (*error_remove_page)(struct address_space *, struct page *);
> @@ -219,7 +221,9 @@ invalidatepage: yes
> releasepage: yes
> freepage:yes
> direct_IO:
> +isolate_page:yes
> migratepage: yes (both)
> +putback_page:yes
> launder_page:yes
> is_partially_uptodate: yes
> error_remove_page: yes
> diff --git a/Documentation/filesystems/vfs.txt
> b/Documentation/filesystems/vfs.txt
> index b02a7d598258..4c1b6c3b4bc8 100644
> --- a/Documentation/filesystems/vfs.txt
> +++ b/Documentation/filesystems/vfs.txt
> @@ -592,9 +592,14 @@ struct address_space_operations {
> int (*releasepage) (struct page *, int);
> void (*freepage)(struct page *);
> ssize_t (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t
> offset);
> + /* isolate a page for migration */
> + bool (*isolate_page) (struct page *, isolate_mode_t);
> /* migrate the contents of a page to the specified target */
> int (*migratepage) (struct page *, struct page *);
> + /* put the page back to right list */
> + void (*putback_page) (struct page *);
> int (*launder_page) (struct page *);
> +
> int (*is_partially_uptodate) (struct page *, unsigned long,
>
Re: [RFC][PATCH v5 1/2] printk: Make printk() completely async
On (03/22/16 11:13), Byungchul Park wrote: [..] what about a "normal" case, when things are not going to explode printk(), but we have several lockups on the same lock (which is probably more likely than printk recursion)? suppose: - there are 8 CPUs on the system - 1 cpus owns the spin_lock for too long - 4 cpus are trying to lock the spin_lock w/o any success - so all 4 trigger spin_dump. what we have at the moment, is that all 4 CPUs will report a lockup, but with this static pointer only X (between 1 and 4, depending on the timing; on how fast spin_dump() will return (logbuf lock can be busy for a while); etc.) CPUs will do so. -ss
[PATCH 0/8] block: prepare for multipage bvecs
Hi, Interests[1] have been shown in multipage bvecs, so this patchset try to prepare for the support and do two things: 1) the 1st 4 patches use bvec iterator to implement iterate_bvec(), then we can drop the non-standard way for iterating bvec 2) remove BIO_MAX_SECTORS & BIO_MAX_SIZE, and now there is only one user for each. Once multipage bvecs is introduced, one bio may hold lots of sectors, and we should always use sort of BIO_MAX_VECS which should be introduced in future and is similiar with current BIO_MAX_PAGES. xfstests(-a auto) have been run and no regression found by this patchset against linus v4.5+. drivers/block/drbd/drbd_int.h | 4 +-- fs/xfs/xfs_buf.c | 2 +- include/linux/bio.h | 55 +-- include/linux/blk_types.h | 4 +-- include/linux/bvec_iter.h | 77 +++ lib/iov_iter.c| 31 +++-- 6 files changed, 94 insertions(+), 79 deletions(-) [1], http://marc.info/?w=2&r=1&s=++[LSF%2FMM+ATTEND]+block%3A+multipage+bvecs&q=t Thanks, Ming
[PATCH 4/8] iov_iter: use bvec iterator to implement iterate_bvec()
bvec has provided one iterator already, so not necessary
to invent a new wheel for this job.
Signed-off-by: Ming Lei
---
lib/iov_iter.c | 31 +++
1 file changed, 11 insertions(+), 20 deletions(-)
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 5fecddc..5e1b224 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -3,6 +3,7 @@
#include
#include
#include
+#include
#include
#define iterate_iovec(i, n, __v, __p, skip, STEP) {\
@@ -57,35 +58,25 @@
}
#define iterate_bvec(i, n, __v, __p, skip, STEP) { \
- size_t wanted = n; \
+ struct bvec_iter __bi, __start; \
+ __start.bi_size = n;\
+ __start.bi_bvec_done = skip;\
+ __start.bi_idx = 0; \
__p = i->bvec; \
- __v.bv_len = min_t(size_t, n, __p->bv_len - skip); \
- if (likely(__v.bv_len)) { \
- __v.bv_page = __p->bv_page; \
- __v.bv_offset = __p->bv_offset + skip; \
+ for_each_bvec(__v, __p, __bi, __start) {\
(void)(STEP); \
- skip += __v.bv_len; \
- n -= __v.bv_len;\
} \
- while (unlikely(n)) { \
- __p++; \
- __v.bv_len = min_t(size_t, n, __p->bv_len); \
- if (unlikely(!__v.bv_len)) \
- continue; \
- __v.bv_page = __p->bv_page; \
- __v.bv_offset = __p->bv_offset; \
- (void)(STEP); \
+ if (!__bi.bi_idx) \
+ skip += __v.bv_len; \
+ else\
skip = __v.bv_len; \
- n -= __v.bv_len;\
- } \
- n = wanted; \
}
#define iterate_all_kinds(i, n, v, I, B, K) { \
size_t skip = i->iov_offset;\
if (unlikely(i->type & ITER_BVEC)) {\
const struct bio_vec *bvec; \
- struct bio_vec v; \
+ struct bio_vec v = { 0 }; \
iterate_bvec(i, n, v, bvec, skip, (B)) \
} else if (unlikely(i->type & ITER_KVEC)) { \
const struct kvec *kvec;\
@@ -102,7 +93,7 @@
size_t skip = i->iov_offset;\
if (unlikely(i->type & ITER_BVEC)) {\
const struct bio_vec *bvec; \
- struct bio_vec v; \
+ struct bio_vec v = { 0 }; \
iterate_bvec(i, n, v, bvec, skip, (B)) \
if (skip == bvec->bv_len) { \
bvec++; \
--
1.9.1
[PATCH 1/8] block: move bvec iterator into include/linux/bvec_iter.h
bvec iterator helpers should be used to implement by
iterate_bvec():lib/iov_iter.c too, and move them into
one header, so that we can keep bvec iterator header
out of CONFIG_BLOCK. Then we can remove the inventing
of wheel in iterate_bvec().
Signed-off-by: Ming Lei
---
include/linux/bio.h | 55 +
include/linux/bvec_iter.h | 78 +++
2 files changed, 79 insertions(+), 54 deletions(-)
create mode 100644 include/linux/bvec_iter.h
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 88bc64f..4abc129 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -31,6 +31,7 @@
/* struct bio, bio_vec and BIO_* flags are defined in blk_types.h */
#include
+#include
#define BIO_DEBUG
@@ -40,10 +41,6 @@
#define BIO_BUG_ON
#endif
-#define BIO_MAX_PAGES 256
-#define BIO_MAX_SIZE (BIO_MAX_PAGES << PAGE_CACHE_SHIFT)
-#define BIO_MAX_SECTORS(BIO_MAX_SIZE >> 9)
-
/*
* upper 16 bits of bi_rw define the io priority of this bio
*/
@@ -57,29 +54,6 @@
(bio)->bi_rw |= ((unsigned long) (prio) << BIO_PRIO_SHIFT); \
} while (0)
-/*
- * various member access, note that bio_data should of course not be used
- * on highmem page vectors
- */
-#define __bvec_iter_bvec(bvec, iter) (&(bvec)[(iter).bi_idx])
-
-#define bvec_iter_page(bvec, iter) \
- (__bvec_iter_bvec((bvec), (iter))->bv_page)
-
-#define bvec_iter_len(bvec, iter) \
- min((iter).bi_size, \
- __bvec_iter_bvec((bvec), (iter))->bv_len - (iter).bi_bvec_done)
-
-#define bvec_iter_offset(bvec, iter) \
- (__bvec_iter_bvec((bvec), (iter))->bv_offset + (iter).bi_bvec_done)
-
-#define bvec_iter_bvec(bvec, iter) \
-((struct bio_vec) {\
- .bv_page= bvec_iter_page((bvec), (iter)), \
- .bv_len = bvec_iter_len((bvec), (iter)),\
- .bv_offset = bvec_iter_offset((bvec), (iter)), \
-})
-
#define bio_iter_iovec(bio, iter) \
bvec_iter_bvec((bio)->bi_io_vec, (iter))
@@ -193,33 +167,6 @@ static inline void *bio_data(struct bio *bio)
#define bio_for_each_segment_all(bvl, bio, i) \
for (i = 0, bvl = (bio)->bi_io_vec; i < (bio)->bi_vcnt; i++, bvl++)
-static inline void bvec_iter_advance(struct bio_vec *bv, struct bvec_iter
*iter,
-unsigned bytes)
-{
- WARN_ONCE(bytes > iter->bi_size,
- "Attempted to advance past end of bvec iter\n");
-
- while (bytes) {
- unsigned len = min(bytes, bvec_iter_len(bv, *iter));
-
- bytes -= len;
- iter->bi_size -= len;
- iter->bi_bvec_done += len;
-
- if (iter->bi_bvec_done == __bvec_iter_bvec(bv, *iter)->bv_len) {
- iter->bi_bvec_done = 0;
- iter->bi_idx++;
- }
- }
-}
-
-#define for_each_bvec(bvl, bio_vec, iter, start) \
- for (iter = (start);\
-(iter).bi_size && \
- ((bvl = bvec_iter_bvec((bio_vec), (iter))), 1); \
-bvec_iter_advance((bio_vec), &(iter), (bvl).bv_len))
-
-
static inline void bio_advance_iter(struct bio *bio, struct bvec_iter *iter,
unsigned bytes)
{
diff --git a/include/linux/bvec_iter.h b/include/linux/bvec_iter.h
new file mode 100644
index 000..cc43055
--- /dev/null
+++ b/include/linux/bvec_iter.h
@@ -0,0 +1,78 @@
+/*
+ * bvec iterator
+ *
+ * Copyright (C) 2001 Ming Lei
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public Licens
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-
+ */
+#ifndef __LINUX_BVEC_ITER_H
+#define __LINUX_BVEC_ITER_H
+
+#include
+
+#define BIO_MAX_PAGES 256
+#define BIO_MAX_SIZE (BIO_MAX_PAGES << PAGE_CACHE_SHIFT)
+#define BIO_MAX_SECTORS(BIO_MAX_SIZE >> 9)
+
+/*
+ * various member access, note that bio_data should of course not be used
+ * on highmem page vectors
+ */
+#define __bvec_iter_bvec(bvec, iter) (&(bvec)[(iter).bi_idx])
+
+#define bvec_iter_page(bve
[PATCH 3/8] block: mark 1st parameter of bvec_iter_advance as const
bvec_iter_advance() only writes the parameter of iterator,
so the base address of bvec can be marked as const safely.
Without the change, we can see compiling warning in the
following patch for implementing iterate_bvec(): lib/iov_iter.c
with bvec iterator.
Signed-off-by: Ming Lei
---
include/linux/bvec_iter.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/bvec_iter.h b/include/linux/bvec_iter.h
index cc43055..5798c21 100644
--- a/include/linux/bvec_iter.h
+++ b/include/linux/bvec_iter.h
@@ -49,7 +49,8 @@
.bv_offset = bvec_iter_offset((bvec), (iter)), \
})
-static inline void bvec_iter_advance(struct bio_vec *bv, struct bvec_iter
*iter,
+static inline void bvec_iter_advance(const struct bio_vec *bv,
+struct bvec_iter *iter,
unsigned bytes)
{
WARN_ONCE(bytes > iter->bi_size,
--
1.9.1
[PATCH 5/8] fs: xfs: replace BIO_MAX_SECTORS with BIO_MAX_PAGES
BIO_MAX_PAGES is used as maximum count of bvecs, so replace BIO_MAX_SECTORS with BIO_MAX_PAGES since BIO_MAX_SECTORS is to be removed. Signed-off-by: Ming Lei --- fs/xfs/xfs_buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c index 9a2191b..01ef6d2 100644 --- a/fs/xfs/xfs_buf.c +++ b/fs/xfs/xfs_buf.c @@ -1161,7 +1161,7 @@ xfs_buf_ioapply_map( next_chunk: atomic_inc(&bp->b_io_remaining); - nr_pages = BIO_MAX_SECTORS >> (PAGE_SHIFT - BBSHIFT); + nr_pages = BIO_MAX_PAGES; if (nr_pages > total_nr_pages) nr_pages = total_nr_pages; -- 1.9.1
[PATCH 2/8] block: make 'struct bvec_iter' not depend on CONFIG_BLOCK
We will use bvec iterator to implement iterate_bvec(): lib/iov_iter.c.
Signed-off-by: Ming Lei
---
include/linux/blk_types.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index 86a38ea..fd8527b 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -26,8 +26,6 @@ struct bio_vec {
unsigned intbv_offset;
};
-#ifdef CONFIG_BLOCK
-
struct bvec_iter {
sector_tbi_sector; /* device address in 512 byte
sectors */
@@ -39,6 +37,8 @@ struct bvec_iter {
current bvec */
};
+#ifdef CONFIG_BLOCK
+
/*
* main unit of I/O for the block layer and lower layers (ie drivers and
* stacking drivers)
--
1.9.1
[PATCH 6/8] block: bio: remove BIO_MAX_SECTORS
No one need this macro, so remove it. The motivation is for supporting multipage bvecs, in which we only know what the max count of bvecs is supported in the bio, instead of max size or max sectors. Signed-off-by: Ming Lei --- include/linux/bvec_iter.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/bvec_iter.h b/include/linux/bvec_iter.h index 5798c21..a979690 100644 --- a/include/linux/bvec_iter.h +++ b/include/linux/bvec_iter.h @@ -24,7 +24,6 @@ #define BIO_MAX_PAGES 256 #define BIO_MAX_SIZE (BIO_MAX_PAGES << PAGE_CACHE_SHIFT) -#define BIO_MAX_SECTORS(BIO_MAX_SIZE >> 9) /* * various member access, note that bio_data should of course not be used -- 1.9.1
[PATCH 8/8] block: bio: remove BIO_MAX_SIZE
No one need this macro now, so remove it. The motivation is for supporting multipage bvecs, in which we only know what the max count of bvecs is supported in the bio, instead of max bio size. Signed-off-by: Ming Lei --- include/linux/bvec_iter.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/bvec_iter.h b/include/linux/bvec_iter.h index a979690..8ddaacf 100644 --- a/include/linux/bvec_iter.h +++ b/include/linux/bvec_iter.h @@ -23,7 +23,6 @@ #include #define BIO_MAX_PAGES 256 -#define BIO_MAX_SIZE (BIO_MAX_PAGES << PAGE_CACHE_SHIFT) /* * various member access, note that bio_data should of course not be used -- 1.9.1
[PATCH 7/8] block: drbd: avoid to use BIO_MAX_SIZE
drbd is the only user of BIO_MAX_SIZE, so use BIO_MAX_PAGES
instead.
Signed-off-by: Ming Lei
---
drivers/block/drbd/drbd_int.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/drbd/drbd_int.h b/drivers/block/drbd/drbd_int.h
index c227fd4..10bfff1 100644
--- a/drivers/block/drbd/drbd_int.h
+++ b/drivers/block/drbd/drbd_int.h
@@ -1327,14 +1327,14 @@ struct bm_extent {
#endif
#endif
-/* BIO_MAX_SIZE is 256 * PAGE_CACHE_SIZE,
+/* Estimate max bio size as 256 * PAGE_CACHE_SIZE,
* so for typical PAGE_CACHE_SIZE of 4k, that is (1<<20) Byte.
* Since we may live in a mixed-platform cluster,
* we limit us to a platform agnostic constant here for now.
* A followup commit may allow even bigger BIO sizes,
* once we thought that through. */
#define DRBD_MAX_BIO_SIZE (1U << 20)
-#if DRBD_MAX_BIO_SIZE > BIO_MAX_SIZE
+#if DRBD_MAX_BIO_SIZE > (BIO_MAX_PAGES << PAGE_CACHE_SHIFT)
#error Architecture not supported: DRBD_MAX_BIO_SIZE > BIO_MAX_SIZE
#endif
#define DRBD_MAX_BIO_SIZE_SAFE (1U << 12) /* Works always = 4k */
--
1.9.1
[PATCH] driver: input :touchscreen : add Raydium I2C touch driver
Raydium I2C touch driver.
Signed-off-by: jeffrey.lin
---
drivers/input/touchscreen/Kconfig | 13 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/raydium_i2c_ts.c | 932 +
3 files changed, 946 insertions(+)
create mode 100644 drivers/input/touchscreen/raydium_i2c_ts.c
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 3f3f6ee..9adacf6 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -915,6 +915,19 @@ config TOUCHSCREEN_PCAP
To compile this driver as a module, choose M here: the
module will be called pcap_ts.
+config TOUCHSCREEN_RM_TS
+ tristate "Raydium I2C Touchscreen"
+ depends on I2C
+ help
+ Say Y here if you have Raydium series I2C touchscreen,
+ such as RM31100 , connected to your system.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called raydium_i2c_ts.
+
+
config TOUCHSCREEN_ST1232
tristate "Sitronix ST1232 touchscreen controllers"
depends on I2C
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
index 4941f2d..99e08cf 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_TOUCHSCREEN_USB_COMPOSITE) +=
usbtouchscreen.o
obj-$(CONFIG_TOUCHSCREEN_PCAP) += pcap_ts.o
obj-$(CONFIG_TOUCHSCREEN_PENMOUNT) += penmount.o
obj-$(CONFIG_TOUCHSCREEN_PIXCIR) += pixcir_i2c_ts.o
+obj-$(CONFIG_TOUCHSCREEN_RM_TS)+= raydium_i2c_ts.o
obj-$(CONFIG_TOUCHSCREEN_S3C2410) += s3c2410_ts.o
obj-$(CONFIG_TOUCHSCREEN_ST1232) += st1232.o
obj-$(CONFIG_TOUCHSCREEN_STMPE)+= stmpe-ts.o
diff --git a/drivers/input/touchscreen/raydium_i2c_ts.c
b/drivers/input/touchscreen/raydium_i2c_ts.c
new file mode 100644
index 000..d4184e2
--- /dev/null
+++ b/drivers/input/touchscreen/raydium_i2c_ts.c
@@ -0,0 +1,932 @@
+/*
+ * Raydium touchscreen I2C driver.
+ *
+ * Copyright (C) 2012-2014, Raydium Semiconductor Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2, and only version 2, as published by the
+ * Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Raydium reserves the right to make changes without further notice
+ * to the materials described herein. Raydium does not assume any
+ * liability arising out of the application described herein.
+ *
+ * Contact Raydium Semiconductor Corporation at www.rad-ic.com
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Device, Driver information */
+#define DEVICE_NAME"rm3"
+
+/* Slave I2C mode*/
+#define RM_BOOT_BLDR 0x02
+#define RM_BOOT_MAIN 0x03
+
+/*I2C command */
+#define CMD_QUERY_BANK 0x2B
+#define CMD_DATA_BANK 0x4D
+#define CMD_ENTER_SLEEP0x4E
+#define CMD_BOOT_ACK 0x0A
+#define CMD_BOOT_WRT 0x5B
+#define CMD_BOOT_CHK 0x0C
+#define CMD_BANK_SWITCH0xAA
+
+/* Touch relative info */
+#define MAX_RETRIES3
+#define MAX_FW_UPDATE_RETRIES 30
+#define MAX_TOUCH_NUM 10
+#define MAX_PACKET_SIZE60
+#define BOOT_DELAY_MS 100
+
+#define RAYDIUM_FW_PAGESIZE128
+#define RAYDIUM_POWERON_DELAY_USEC 500
+#define RAYDIUM_RESET_DELAY_MSEC 50
+
+#define ADDR_INDEX 0x03
+#define DATA_INDEX 0x04
+
+#define HEADER_SIZE4
+
+enum raydium_boot_mode {
+ RAYDIUM_TS_MAIN = 0,
+ RAYDIUM_TS_BLDR,
+};
+
+enum raydium_abs_idx {
+ POS_STATE = 0,/*1:touch, 0:no touch*/
+ POS_X,
+ POS_Y = 3,
+ POS_PRESSURE,
+ WIDTH_X,
+ WIDTH_Y,
+};
+
+struct raydium_info {
+ u32 hw_ver; /*device ver, __le32*/
+ u8 main_ver;
+ u8 sub_ver;
+ u16 ft_ver; /*test ver, __le16*/
+ u8 x_num;
+ u8 y_num;
+ u16 x_max; /*disp reso, __le16*/
+ u16 y_max; /*disp reso, __le16*/
+ u8 x_res; /* units/mm */
+ u8 y_res; /* units/mm */
+};
+
+struct raydium_object {
+ u32 data_bank_addr;
+ u8 pkg_size;
+ u8 tp_info_size;
+};
+
+/* struct raydium_data - represents state of Raydium touchscreen device */
+struct raydium_data {
+ struct i2c_client *client;
+ struct input_dev *input;
+
+ struct regulator *avdd;
+ struct regulator *vccio;
+ struct gpio_desc *reset_gpio;
+
+
Re: [PATCH 1/4] vfs: add file_dentry()
>> From: Miklos Szeredi
>>
>> This series fixes bugs in nfs and ext4 due to 4bacc9c9234c ("overlayfs: Make
>> f_path always point to the overlay and f_inode to the underlay").
>>
>> Regular files opened on overlayfs will result in the file being opened on
>> the underlying filesystem, while f_path points to the overlayfs
>> mount/dentry.
>>
>> This confuses filesystems which get the dentry from struct file and assume
>> it's theirs.
>>
>> Add a new helper, file_dentry() [*], to get the filesystem's own dentry
>> from the file. This simply compares file_inode(file->f_path.dentry) to
>> file_inode(file) and if they are equal returns file->f_path.dentry (this is
>> the common, non-overlayfs case).
>>
>> In the uncommon case (regular file on overlayfs) it will call into
>> overlayfs's ->d_native_dentry() to get the underlying dentry matching
>> file_inode(file).
>>
>> [*] If possible, it's better simply to use file_inode() instead.
Hopefully this is not so late as to be useless!
For this entire series:
Tested-by: Daniel Axtens
Regards,
Daniel
>>
>> Signed-off-by: Miklos Szeredi
>> Tested-by: Goldwyn Rodrigues
>> Reviewed-by: Trond Myklebust
>> Cc: # v4.2
>> Cc: David Howells
>> Cc: Al Viro
>> Cc: Theodore Ts'o
>> Cc: Daniel Axtens
>> ---
>> fs/open.c | 11 +++
>> fs/overlayfs/super.c | 16
>> include/linux/dcache.h | 1 +
>> include/linux/fs.h | 2 ++
>> 4 files changed, 30 insertions(+)
>
> I have this patch in the ext4.git tree, but I'd like to get an
> Acked-by from Al before I send a pull request to Linus.
>
> Al? Any objections to my sending in this change via the ext4 tree?
>
> - Ted
>
>>
>> diff --git a/fs/open.c b/fs/open.c
>> index 55bdc75e2172..6326c11eda78 100644
>> --- a/fs/open.c
>> +++ b/fs/open.c
>> @@ -831,6 +831,17 @@ char *file_path(struct file *filp, char *buf, int
>> buflen)
>> }
>> EXPORT_SYMBOL(file_path);
>>
>> +struct dentry *file_dentry(const struct file *file)
>> +{
>> +struct dentry *dentry = file->f_path.dentry;
>> +
>> +if (likely(d_inode(dentry) == file_inode(file)))
>> +return dentry;
>> +else
>> +return dentry->d_op->d_native_dentry(dentry, file_inode(file));
>> +}
>> +EXPORT_SYMBOL(file_dentry);
>> +
>> /**
>> * vfs_open - open the file at the given path
>> * @path: path to open
>> diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>> index 619ad4b016d2..5142aa2034c4 100644
>> --- a/fs/overlayfs/super.c
>> +++ b/fs/overlayfs/super.c
>> @@ -336,14 +336,30 @@ static int ovl_dentry_weak_revalidate(struct dentry
>> *dentry, unsigned int flags)
>> return ret;
>> }
>>
>> +static struct dentry *ovl_d_native_dentry(struct dentry *dentry,
>> + struct inode *inode)
>> +{
>> +struct ovl_entry *oe = dentry->d_fsdata;
>> +struct dentry *realentry = ovl_upperdentry_dereference(oe);
>> +
>> +if (realentry && inode == d_inode(realentry))
>> +return realentry;
>> +realentry = __ovl_dentry_lower(oe);
>> +if (realentry && inode == d_inode(realentry))
>> +return realentry;
>> +BUG();
>> +}
>> +
>> static const struct dentry_operations ovl_dentry_operations = {
>> .d_release = ovl_dentry_release,
>> .d_select_inode = ovl_d_select_inode,
>> +.d_native_dentry = ovl_d_native_dentry,
>> };
>>
>> static const struct dentry_operations ovl_reval_dentry_operations = {
>> .d_release = ovl_dentry_release,
>> .d_select_inode = ovl_d_select_inode,
>> +.d_native_dentry = ovl_d_native_dentry,
>> .d_revalidate = ovl_dentry_revalidate,
>> .d_weak_revalidate = ovl_dentry_weak_revalidate,
>> };
>> diff --git a/include/linux/dcache.h b/include/linux/dcache.h
>> index c4b5f4b3f8f8..99ecb6de636c 100644
>> --- a/include/linux/dcache.h
>> +++ b/include/linux/dcache.h
>> @@ -161,6 +161,7 @@ struct dentry_operations {
>> struct vfsmount *(*d_automount)(struct path *);
>> int (*d_manage)(struct dentry *, bool);
>> struct inode *(*d_select_inode)(struct dentry *, unsigned);
>> +struct dentry *(*d_native_dentry)(struct dentry *, struct inode *);
>> } cacheline_aligned;
>>
>> /*
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index ae681002100a..1091d9f43271 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -1234,6 +1234,8 @@ static inline struct inode *file_inode(const struct
>> file *f)
>> return f->f_inode;
>> }
>>
>> +extern struct dentry *file_dentry(const struct file *file);
>> +
>> static inline int locks_lock_file_wait(struct file *filp, struct file_lock
>> *fl)
>> {
>> return locks_lock_inode_wait(file_inode(filp), fl);
>> --
>> 2.1.4
>>
Re: [v8,09/10] tpm: Initialize TPM and get durations and timeouts
On Sun, Mar 13, 2016 at 06:54:39PM -0400, Stefan Berger wrote:
> Add the retrieval of TPM 1.2 durations and timeouts. Since this requires
> the startup of the TPM, do this for TPM 1.2 and TPM 2.
>
> Signed-off-by: Stefan Berger
> CC: linux-kernel@vger.kernel.org
> CC: linux-...@vger.kernel.org
> CC: linux-...@vger.kernel.org
>
> ---
> drivers/char/tpm/tpm_vtpm_proxy.c | 95 +++
> 1 file changed, 86 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c
> b/drivers/char/tpm/tpm_vtpm_proxy.c
> index 2bb2c8c..7fd686b 100644
> --- a/drivers/char/tpm/tpm_vtpm_proxy.c
> +++ b/drivers/char/tpm/tpm_vtpm_proxy.c
> @@ -45,8 +45,11 @@ struct proxy_dev {
> size_t req_len; /* length of queued TPM request */
> size_t resp_len; /* length of queued TPM response */
> u8 buffer[TPM_BUFSIZE]; /* request/response buffer */
> +
> + struct work_struct work; /* task that retrieves TPM timeouts */
> };
>
> +static struct workqueue_struct *workqueue;
>
> static void vtpm_proxy_delete_device(struct proxy_dev *proxy_dev);
>
> @@ -67,6 +70,15 @@ static ssize_t vtpm_proxy_fops_read(struct file *filp,
> char __user *buf,
> size_t len;
> int sig, rc;
>
> + mutex_lock(&proxy_dev->buf_lock);
> +
> + if (!(proxy_dev->state & STATE_OPENED_FLAG)) {
> + mutex_unlock(&proxy_dev->buf_lock);
> + return -EPIPE;
> + }
> +
> + mutex_unlock(&proxy_dev->buf_lock);
> +
> sig = wait_event_interruptible(proxy_dev->wq, proxy_dev->req_len != 0);
> if (sig)
> return -EINTR;
What if STATE_OPENED_FLAG is set after mutex_unlock()?
Is there some scenario where STATE_OPENED_FLAG would evaluate false
at this point?
Actually I couldn't find a scenario where this check would be needed
because:
* In vtpm_proxy_work() vtpm_proxy_fops_undo_open() is called after
sending TPM commands.
* vtpm_proxy_delete_device() calls vtpm_proxy_work_stop() as its
first statement.
Am I ignoring something?
/Jarkko
> @@ -110,6 +122,11 @@ static ssize_t vtpm_proxy_fops_write(struct file *filp,
> const char __user *buf,
>
> mutex_lock(&proxy_dev->buf_lock);
>
> + if (!(proxy_dev->state & STATE_OPENED_FLAG)) {
> + mutex_unlock(&proxy_dev->buf_lock);
> + return -EPIPE;
> + }
> +
> if (count > sizeof(proxy_dev->buffer) ||
> !(proxy_dev->state & STATE_WAIT_RESPONSE_FLAG)) {
> mutex_unlock(&proxy_dev->buf_lock);
> @@ -154,6 +171,9 @@ static unsigned int vtpm_proxy_fops_poll(struct file
> *filp, poll_table *wait)
> if (proxy_dev->req_len)
> ret |= POLLIN | POLLRDNORM;
>
> + if (!(proxy_dev->state & STATE_OPENED_FLAG))
> + ret |= POLLHUP;
> +
> mutex_unlock(&proxy_dev->buf_lock);
>
> return ret;
> @@ -341,6 +361,55 @@ static const struct tpm_class_ops vtpm_proxy_tpm_ops = {
> };
>
> /*
> + * Code related to the startup of the TPM 2 and startup of TPM 1.2 +
> + * retrieval of timeouts and durations.
> + */
> +
> +static void vtpm_proxy_work(struct work_struct *work)
> +{
> + struct proxy_dev *proxy_dev = container_of(work, struct proxy_dev,
> +work);
> + int rc;
> +
> + if (proxy_dev->flags & VTPM_PROXY_FLAG_TPM2)
> + rc = tpm2_startup(proxy_dev->chip, TPM2_SU_CLEAR);
> + else
> + rc = tpm_get_timeouts(proxy_dev->chip);
> +
> + if (rc)
> + goto err;
> +
> + rc = tpm_chip_register(proxy_dev->chip);
> + if (rc)
> + goto err;
> +
> + return;
> +
> +err:
> + vtpm_proxy_fops_undo_open(proxy_dev);
> +}
> +
> +/*
> + * vtpm_proxy_work_stop: make sure the work has finished
> + *
> + * This function is useful when user space closed the fd
> + * while the driver still determines timeouts.
> + */
> +static void vtpm_proxy_work_stop(struct proxy_dev *proxy_dev)
> +{
> + vtpm_proxy_fops_undo_open(proxy_dev);
> + flush_work(&proxy_dev->work);
> +}
> +
> +/*
> + * vtpm_proxy_work_start: Schedule the work for TPM 1.2 & 2 initialization
> + */
> +static inline void vtpm_proxy_work_start(struct proxy_dev *proxy_dev)
> +{
> + queue_work(workqueue, &proxy_dev->work);
> +}
> +
> +/*
> * Code related to creation and deletion of device pairs
> */
> static struct proxy_dev *vtpm_proxy_create_proxy_dev(void)
> @@ -355,6 +424,7 @@ static struct proxy_dev *vtpm_proxy_create_proxy_dev(void)
>
> init_waitqueue_head(&proxy_dev->wq);
> mutex_init(&proxy_dev->buf_lock);
> + INIT_WORK(&proxy_dev->work, vtpm_proxy_work);
>
> chip = tpm_chip_alloc(NULL, &vtpm_proxy_tpm_ops);
> if (IS_ERR(chip)) {
> @@ -425,9 +495,7 @@ static struct file *vtpm_proxy_create_device(
> if (proxy_dev->flags & VTPM_PROXY_FLAG_TPM2)
> proxy_dev->chip->flags |= TPM_CHIP_FLAG_TPM2;
>
> - rc = tpm_chip_reg
[PATCH] dt-bindings: input: add Raydium I2C touch driver bindings
Document the device tree binfings of Raydium I2C touch driver.
Signed-off-by: jeffrey.lin
---
.../devicetree/bindings/input/raydium_i2c_ts.txt| 21 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/raydium_i2c_ts.txt
diff --git a/Documentation/devicetree/bindings/input/raydium_i2c_ts.txt
b/Documentation/devicetree/bindings/input/raydium_i2c_ts.txt
new file mode 100644
index 000..d7631d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/raydium_i2c_ts.txt
@@ -0,0 +1,21 @@
+Raydium I2C touchscreen
+
+Required properties:
+- compatible:
+"raydium,rm3"
+
+- reg: The I2C address of the device
+- interrupts: interrupt to which the chip is connected
+See ../interrupt-controller/interrupts.txt
+Optional property:
+ - avdd-supply : Analog power supply needed to power device
+ - vccio-supply: IO Power source
+
+Example:
+
+ raydium_i2c@39 {
+ compatible = "raydium,rm3";\
+ reg = <0x39>;
+ interrupt-parent = <&gpio>;
+ interrupts = <0x0 IRQ_TYPE_EDGE_FALLING>;
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index af49e0f..5b6224b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -126,6 +126,7 @@ radxa Radxa
raidsonic RaidSonic Technology GmbH
ralink Mediatek/Ralink Technology Corp.
ramtronRamtron International
+raydium Raydium Semiconductor Corp.
realtek Realtek Semiconductor Corp.
renesasRenesas Electronics Corporation
ricoh Ricoh Co. Ltd.
--
2.1.2
RE: [LINUX PATCH 1/2] mtd: Added dummy entry in the spi_transfer structure.
Hi Mark,
>On Mon, Mar 21, 2016 at 05:50:08PM +0530, P L Sai Krishna wrote:
>> This patch does following things.
>> 1. Added dummy entry in the spi_transfer structure.
>> 2. Assigned dummy cycles to dummy member in the transfer structure
>> during read operation.
>
>Please try to follow the patch submission process covered in
>SubmittingPatches, in particular please use subject lines reflecting the style
>for the subsystem (which helps people identify relevant changes to
>review) and...
>
>> drivers/mtd/devices/m25p80.c | 1 +
>> include/linux/spi/spi.h | 2 ++
>> 2 files changed, 3 insertions(+)
>
>...split things up into individual patches, for example here you're both
>adding a
>new feature and adding a user of that feature in a single patch.
I will split the patch into two with appropriate commit messages.
>
>> + * @dummy: number of dummy cycles.
>
>This needs to be clearer about what a dummy cycle is and where it gets
>inserted. We probably also want a better name, just "dummy" makes it look
>like a padding field in the structure. How about dummy_cycles?
dummy_cycles is a better idea.
I will change it and add the usage of this in the description in a detailed
manner.
>
>> @@ -752,6 +753,7 @@ struct spi_transfer {
>> u8 bits_per_word;
>> u16 delay_usecs;
>> u32 speed_hz;
>> +u32 dummy;
>>
>> struct list_head transfer_list;
>> };
>
>This isn't enough to add the feature - a client driver trying to make use of
>this
>needs to be able to tell if the cycles are actually going to be inserted. I'd
>expect to see a capability flag that can be checked and some error checking so
>that if we try to do a transfer with dummy cycles and can't support it we don't
>silently ignore the dummy cycles, ideally also something that'll handle
>multiples of 8 bits with SPI controllers that don't otherwise support this
>feature.
Currently, all fast reads use 8 cycles or 1 byte of dummy. This generally works.
But it can be vary based on the flash and the type of read command.
Dummy bytes are taken care of in m25p80.c by adjusting the len field:
Length = size of (command + address + dummy byte)
There might be controllers (like ZynqMP GQSPI) that would be able to use
the information that dummy byte(s) were added and the precise number
of dummy cycles. This patch does not disturb the existing implementation
of adjusting length (as described above). It adds an additional optional
feature.
So there is no harm to controllers that can't support it - they can ignore it
and
still work with the existing "length adjustment" implementation.
If you think there value in adding a capability flag, please let me know.
Thanks for your review.
Regards,
Sai Krishna
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
Re: [PATCH 1/2] usb: dwc3: core: Introduce dwc3_device_reinit()
Hi, John Youn writes: > [ text/plain ] > On 3/18/2016 12:17 PM, John Youn wrote: >> On 3/16/2016 6:56 AM, Felipe Balbi wrote: >>> >>> heh, +john >>> >>> Felipe Balbi writes: [ text/plain ] Hi, Roger Quadros writes: > [ text/plain ] > We will need this function for a workaround. > The function issues a softreset only to the device > controller and performs minimal re-initialization > so that the device controller can be usable. > > As some code is similar to dwc3_core_init() take out > common code into dwc3_get_gctl_quirks(). > > We add a new member (prtcap_mode) to struct dwc3 to > keep track of the current mode in the PRTCAPDIR register. > > Signed-off-by: Roger Quadros I must say, I don't like this at all :-p There's ONE known silicon which needs this because of a poor silicon integration which took an IP with a known erratum where it can't be made to work on lower speeds and STILL was integrated without a superspeed PHY. There's a reason why I never tried to push this upstream myself ;-) I'm really thinking we might be better off adding a quirk flag to skip the metastability workaround and allow this ONE silicon to set the controller to lower speed. John, can you check with your colleagues if we would ever fall into STAR#9000525659 if we set maximum speed to high speed during driver probe and never touch it again ? I would assume we don't really fall into the metastability workaround, right ? We're not doing any sort of PM for dwc3... > > Hi Felipe, > > Do you mean to keep DCFG.speed to SS and set dwc->maximum_speed to HS? > I don't see an issue with that as long as we always ignore > dwc->maximum_speed when programming DCFG.speed for all affected > versions of the core. As long as the DCFG.speed = SS, you should not > hit the STAR. I actually mean changing DCFG.speed during driver probe and never touching it again. Would that still cause problems ? -- balbi signature.asc Description: PGP signature
Re: [PATCH RESEND] Revert "PCI: dra7xx: Mark driver as broken"
Hi Bjorn,
On Wednesday 09 March 2016 10:31 AM, Kishon Vijay Abraham I wrote:
>
>
> On Tuesday 08 March 2016 11:35 PM, Bjorn Helgaas wrote:
>> On Fri, Mar 04, 2016 at 03:59:19PM +0530, Kishon Vijay Abraham I wrote:
>>> From: Sekhar Nori
>>>
>>> This reverts commit <5c3b99d057525fe2befe6a7db9b1309035d93eee>
>>> ("PCI: dra7xx: Mark driver as broken").
>>>
>>> With support to de-assert PCIe reset present in kernel,
>>> DRA7x PCIe is not broken anymore.
>>>
>>> Signed-off-by: Sekhar Nori
>>> Signed-off-by: Kishon Vijay Abraham I
>>> ---
>>> Bjorn,
>>>
>>> This patch should be merged only after [1] hits linus tree.
>>>
>>> Thanks
>>> Kishon
>>>
>>> [1] -> git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git
>>> for-v4.6/omap-hwmod-b
>>
>> OK. Would you mind pinging me about this after [1] is merged to
>> Linus' tree? I don't want to put this in my "next" branch yet,
>> because I don't know whether Pauls branch or mine will be merged first
>> in the merge window. But after the merge window closes, I can
>> certainly include this in a "PCI fixes" pull request for inclusion in
>> v4.6.
>
> yes sure. I can do that.
The reset patch [2] has been merged to linus tree. This patch can be merged now.
Thanks
Kishon
[2] ->
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/mach-omap2/omap_hwmod_7xx_data.c?id=1c96bee4df1998b9dec3e2ef8f77e8436e29342b
>
> Thanks
> Kishon
>
>>
>> Bjorn
>>
>>> drivers/pci/host/Kconfig |1 -
>>> 1 file changed, 1 deletion(-)
>>>
>>> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
>>> index 75a6054..6d181ba 100644
>>> --- a/drivers/pci/host/Kconfig
>>> +++ b/drivers/pci/host/Kconfig
>>> @@ -5,7 +5,6 @@ config PCI_DRA7XX
>>> bool "TI DRA7xx PCIe controller"
>>> select PCIE_DW
>>> depends on OF && HAS_IOMEM && TI_PIPE3
>>> - depends on BROKEN
>>> help
>>> Enables support for the PCIe controller in the DRA7xx SoC. There
>>> are two instances of PCIe controller in DRA7xx. This controller can
>>> --
>>> 1.7.9.5
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH v6 0/2] printk: Make printk() completely async
Hi, On Tue 22-03-16 02:25:28, Sergey Senozhatsky wrote: > The patch set is based on slightly updated Jan Kara's patches. > > This patch set makes printk() completely asynchronous: new messages > are getting upended to the kernel printk buffer, but instead of 'direct' > printing the actual print job is performed by a dedicated kthread. > This has the advantage that printing always happens from a schedulable > context and thus we don't lockup any particular CPU or even interrupts. > > The patch set is against next-20160321 > > the series in total has 3 patches: > - printk: Make printk() completely async > - printk: Make wake_up_klogd_work_func() async > - printk: make console_unlock() async > > per discussion, "printk: make console_unlock() async" will be posted > later on. Patches look good to me. I don't think you need to mention the console_unlock() async patch when it is not part of the series. BTW, you seemed to have dropped my patch to skip if there are too many buffered messages when oops is in progress. Any reason for that? Honza -- Jan Kara SUSE Labs, CR
[PATCH] virtio-pci: use possible fallback queue size
Virtio 1.0 spec allows driver to modify queue size to reduce momery
requeirments. So the driver should write back the queue size actually
allocated, instead of the original value read from the common config
for the queue.
Signed-off-by: Liang Chen
Signed-off-by: Gavin Guo
Suggested-by: Jay Vosburgh
---
drivers/virtio/virtio_pci_common.h | 2 +-
drivers/virtio/virtio_pci_modern.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio_pci_common.h
b/drivers/virtio/virtio_pci_common.h
index 2cc2522..32ee993 100644
--- a/drivers/virtio/virtio_pci_common.h
+++ b/drivers/virtio/virtio_pci_common.h
@@ -36,7 +36,7 @@ struct virtio_pci_vq_info {
struct virtqueue *vq;
/* the number of entries in the queue */
- int num;
+ u16 num;
/* the virtual address of the ring queue */
void *queue;
diff --git a/drivers/virtio/virtio_pci_modern.c
b/drivers/virtio/virtio_pci_modern.c
index 7760fc1..7f9ccac 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -293,7 +293,7 @@ static size_t vring_pci_size(u16 num)
return PAGE_ALIGN(vring_size(num, SMP_CACHE_BYTES));
}
-static void *alloc_virtqueue_pages(int *num)
+static void *alloc_virtqueue_pages(u16 *num)
{
void *pages;
@@ -360,7 +360,7 @@ static struct virtqueue *setup_vq(struct virtio_pci_device
*vp_dev,
}
/* activate the queue */
- vp_iowrite16(num, &cfg->queue_size);
+ vp_iowrite16(info->num, &cfg->queue_size);
vp_iowrite64_twopart(virt_to_phys(info->queue),
&cfg->queue_desc_lo, &cfg->queue_desc_hi);
vp_iowrite64_twopart(virt_to_phys(virtqueue_get_avail(vq)),
--
1.9.1
[PATCH] ath9k: fix checkpatch.pl identation and sapce errors.
Signed-off-by: Ashwini Singh
---
drivers/net/wireless/ath/ath9k/ani.c|2 +-
drivers/net/wireless/ath/ath9k/antenna.c|2 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c |2 +-
drivers/net/wireless/ath/ath9k/ar9002_phy.c |2 +-
drivers/net/wireless/ath/ath9k/ar9003_aic.c |2 +-
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 20 ++--
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c |8
drivers/net/wireless/ath/ath9k/ar9003_mci.c |2 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c |4 ++--
drivers/net/wireless/ath/ath9k/ar9003_rtt.c |2 +-
drivers/net/wireless/ath/ath9k/ar9003_wow.c | 12 ++--
drivers/net/wireless/ath/ath9k/ath9k.h |6 +++---
drivers/net/wireless/ath/ath9k/beacon.c |6 +++---
drivers/net/wireless/ath/ath9k/common-init.c|2 +-
drivers/net/wireless/ath/ath9k/common.c |2 +-
drivers/net/wireless/ath/ath9k/eeprom.c |4 ++--
drivers/net/wireless/ath/ath9k/eeprom_4k.c |2 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c |4 ++--
drivers/net/wireless/ath/ath9k/htc_drv_beacon.c |2 +-
drivers/net/wireless/ath/ath9k/htc_drv_init.c |2 +-
drivers/net/wireless/ath/ath9k/hw.c |9 -
drivers/net/wireless/ath/ath9k/init.c |4 ++--
drivers/net/wireless/ath/ath9k/reg_mci.h| 14 +++---
drivers/net/wireless/ath/ath9k/reg_wow.h| 14 +++---
drivers/net/wireless/ath/ath9k/xmit.c | 12 ++--
25 files changed, 70 insertions(+), 71 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ani.c
b/drivers/net/wireless/ath/ath9k/ani.c
index 815efe9..6bbf80b 100644
--- a/drivers/net/wireless/ath/ath9k/ani.c
+++ b/drivers/net/wireless/ath/ath9k/ani.c
@@ -432,7 +432,7 @@ void ath9k_hw_ani_monitor(struct ath_hw *ah, struct
ath9k_channel *chan)
aniState->ofdmsTurn = true;
} else
return;
-
+
ath9k_ani_restart(ah);
}
}
diff --git a/drivers/net/wireless/ath/ath9k/antenna.c
b/drivers/net/wireless/ath/ath9k/antenna.c
index a366843..c6b4ec7 100644
--- a/drivers/net/wireless/ath/ath9k/antenna.c
+++ b/drivers/net/wireless/ath/ath9k/antenna.c
@@ -314,7 +314,7 @@ static void ath_select_ant_div_from_quick_scan(struct
ath_ant_comb *antcomb,
antcomb->rssi_first = main_rssi_avg;
antcomb->rssi_third = alt_rssi_avg;
- switch(antcomb->second_quick_scan_conf) {
+ switch (antcomb->second_quick_scan_conf) {
case ATH_ANT_DIV_COMB_LNA1:
antcomb->rssi_lna1 = alt_rssi_avg;
break;
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_hw.c
b/drivers/net/wireless/ath/ath9k/ar9002_hw.c
index d480d2f..b5db5f1 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_hw.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_hw.c
@@ -92,7 +92,7 @@ static int ar9002_hw_init_mode_regs(struct ath_hw *ah)
if (!AR_SREV_5416_22_OR_LATER(ah)) {
/* override CLKDRV value */
- INI_RA(addac, 31,1) = 0;
+ INI_RA(addac, 31, 1) = 0;
}
}
if (AR_SREV_9287_11_OR_LATER(ah)) {
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.c
b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
index db66245..298e621 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
@@ -458,7 +458,7 @@ static void ar9002_hw_set_bt_ant_diversity(struct ath_hw
*ah, bool enable)
regval = REG_READ(ah, AR_PHY_MULTICHAIN_GAIN_CTL);
regval &= (~(AR_PHY_9285_ANT_DIV_CTL_ALL));
-/*
+ /*
* Clear ant_fast_div_bias [14:9] since for WB195,
* the main LNA is always LNA1.
*/
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_aic.c
b/drivers/net/wireless/ath/ath9k/ar9003_aic.c
index 547cd46..e12a712 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_aic.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_aic.c
@@ -363,7 +363,7 @@ static bool ar9003_aic_cal_post_process(struct ath_hw *ah)
(start_idx - end_idx) +
aic_sram[start_idx].quad_path_gain_lin;
- } else if (start_idx >= 0){
+ } else if (start_idx >= 0) {
/* interpolation */
aic_sram[i].dir_path_gain_lin =
(((end_idx - i) *
aic_sram[start_idx].dir_path_gain_lin) +
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
index 0c39199..1ff5424 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
@@ -700,15 +700,15 @@ static bool ar9003_hw_calc_iq_corr(
