Re: [PATCH v6 4/4] crypto: AF_ALG: enable RNG interface compilation
Am Montag, 29. Dezember 2014, 21:41:58 schrieb Herbert Xu: Hi Herbert, > On Thu, Dec 25, 2014 at 11:00:39PM +0100, Stephan Mueller wrote: > > Enable compilation of the RNG AF_ALG support and provide a Kconfig > > option to compile the RNG AF_ALG support. > > > > Signed-off-by: Stephan Mueller > > Patch applied. May I ask you to push the change so that I can create an AEAD Makefile/Kconfig patch that applies cleanly? -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: iwlwifi-driver card doesn't work with 3.19-rc2+
>
> On Tue, 30 Dec 2014, Larry Finger wrote:
>
> > > > If wireless maintainers think otherwise, I'll send a revert
> > > > request to Linus for consideration.
> > >
> > > I wonder if the reaction would be like this one:
> > >
> > > https://lkml.org/lkml/2012/12/23/75
> > >
> > > :-)
> >
> > It would be a little like that.
> >
> > One thread of interest is https://lkml.org/lkml/2014/12/22/348. Commit
> > 24a0aa212ee2 ("cfg80211: make WEXT compatibility unselectable") made
> > it impossible to select the IPW2200. The patch to allow selecting the
> > IPW2200, which automatically selects CFG80211_WEXT has been added to
> > wireless-drivers, but it has not yet made it to mainline. Once it
> > does, then choosing to build the IPW2200 will provide a workaround.
> >
> > In my opinion, the need for the IPW2200 to have CFG80211_WEXT means
> > that the original commit will likely be reverted, but your voice will help.
>
> Ok, thanks a lot for another datapoint. I am sending revert patch to Linus
> tonight.
>
I don't see this as another datapoint. All it means is that there are ancient
drivers
that won't work at all with newer tools and that are taken into consideration
while
trying to deprecate an API.
Now - basically all your argument is on Johannes's comment: "deprecated enough".
I think we have a chicken and egg problem here. We can't break things towards
userland.
Good. But we do want to deprecate this API because lots of valid purely
technical reasons.
Unfortunately, I don't see what we could do to send a strong signal to
userspace tools developers
to have them work / plan a move to a modern API.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] coresight: fix typo in comment in of_coresight.c
Debugfs isn't used for coresight configuration, so the corresponding comments should be changed. Signed-off-by: Kaixu Xia --- drivers/coresight/of_coresight.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/coresight/of_coresight.c b/drivers/coresight/of_coresight.c index 5030c07..8bd524e 100644 --- a/drivers/coresight/of_coresight.c +++ b/drivers/coresight/of_coresight.c @@ -126,7 +126,7 @@ struct coresight_platform_data *of_get_coresight_platform_data( if (!pdata) return ERR_PTR(-ENOMEM); - /* Use device name as debugfs handle */ + /* Use device name as sysfs handle */ pdata->name = dev_name(dev); /* Get the number of input and output port for this component */ -- 1.8.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
> Subject: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable" > > This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a. > > It's causing severe userspace breakage. Namely, all the utilities from > wireless-utils which are relying on CONFIG_WEXT (which means tools like > 'iwconfig', 'iwlist', etc) are not working anymore. There is a 'iw' utility in > newer wireless-tools, which is supposed to be a replacement for all the > "deprecated" binaries, but it's far away from being massively adopted. > > Please see [1] for example of the userspace breakage this is causing. > > In addition to that, Larry Finger reports [2] that this patch is also causing > ipw2200 driver being impossible to build. > > To me this clearly shows that CONFIG_WEXT is far, far away from being > "deprecated enough" to be removed. > > [1] http://thread.gmane.org/gmane.linux.kernel/1857010 > [2] http://thread.gmane.org/gmane.linux.network/343688 > > Signed-off-by: Jiri Kosina Wait. I don't want to discuss the userspace API deprecation here but I do think that this patch should be applied to the proper tree if at all. The proper tree is mac80211.git. Now you are unhappy with what happens there and want to escalate - fine. But then, please do so following the natural hierarchy of the trees: net.git. Then mac80211.git's maintainer (Johannes) will be able to sync with your change more easily. Johannes doesn't need me as an advocate, but I feel that reverting a mac80211 patch in linux.git while we are only in -rc2 while everybody is on holiday leave is a bit unfair. > --- > net/wireless/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig index > 22ba971..29c8675 100644 > --- a/net/wireless/Kconfig > +++ b/net/wireless/Kconfig > @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB > Most distributions have a CRDA package. So if unsure, say N. > > config CFG80211_WEXT > - bool > + bool "cfg80211 wireless extensions compatibility" > depends on CFG80211 > select WEXT_CORE > help > -- > Jiri Kosina > SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mm: cma: /proc/cmainfo
On Wed, Dec 31, 2014 at 03:47:59PM +0900, Namhyung Kim wrote:
> Hello,
>
> On Wed, Dec 31, 2014 at 09:58:04AM +0900, Gioh Kim wrote:
> > 2014-12-30 오후 1:47에 Minchan Kim 이(가) 쓴 글:
> > >On Mon, Dec 29, 2014 at 11:52:58AM -0800, Laura Abbott wrote:
> > >>I've been meaning to write something like this for a while so I'm
> > >>happy to see an attempt made to fix this. I can't speak for the
> > >>author's reasons for wanting this information but there are
> > >>several reasons why I was thinking of something similar.
> > >>
> > >>The most common bug reports seen internally on CMA are 1) CMA is
> > >>too slow and 2) CMA failed to allocate memory. For #1, not all
> > >>allocations may be slow so it's useful to be able to keep track
> > >>of which allocations are taking too long. For #2, migration
> > >
> > >Then, I don't think we could keep all of allocations. What we need
> > >is only slow allocations. I hope we can do that with ftrace.
> > >
> > >ex)
> > >
> > ># cd /sys/kernel/debug/tracing
> > ># echo 1 > options/stacktrace
> > ># echo cam_alloc > set_ftrace_filter
> > ># echo your_threshold > tracing_thresh
> > >
> > >I know it doesn't work now but I think it's more flexible
> > >and general way to handle such issues(ie, latency of some functions).
> > >So, I hope we could enhance ftrace rather than new wheel.
> > >Ccing ftrace people.
> >
> > For CMA performance test or code flow check, ftrace is better.
> >
> > ex)
> > echo cma_alloc > /sys/kernel/debug/tracing/set_graph_function
> > echo function_graph > /sys/kernel/debug/tracing/current_tracer
> > echo funcgraph-proc > /sys/kernel/debug/tracing/trace_options
> > echo nosleep-time > /sys/kernel/debug/tracing/trace_options
> > echo funcgraph-tail > /sys/kernel/debug/tracing/trace_options
> > echo 1 > /sys/kernel/debug/tracing/tracing_on
> >
> > This can trace every cam_alloc and allocation time.
> > I think ftrace is better to debug latency.
> > If a buffer had allocated and had peak latency and freed,
> > we can check it.
>
> It'd be great if we can reuse the max latency tracing feature for the
> function graph tracer in order to track a latency problem of an
> arbitrary function more easily. I've written a PoC code that can be
> used like below..
>
> # cd /sys/kernel/debug/tracing
> # echo 0 > tracing_on
> # echo function_graph > current_tracer
> # echo funcgraph-latency > trace_options
> # echo cma_alloc > graph_latency_func
> # echo 1 > tracing_on
>
> Now the tracing_max_latency file has a max latency of the cma_alloc()
> in usec and the snapshot file contains a snapshot of all the codepath
> to the function at the time.
>
> Would anybody like to play with it? :)
Thanks, Namhyung. I did and feel it would be useful to check only
max latency data.
Anyway, off-topic:
IMO, it would be very useful to check latency of several functions which
has different threshold at the same time without helping other tools.
>
> Thanks,
> Namhyung
>
>
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index 0eddfeb05fee..4a3d5ed2802c 100644
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -723,6 +723,7 @@ extern char trace_find_mark(unsigned long long duration);
> #define TRACE_GRAPH_PRINT_ABS_TIME 0x20
> #define TRACE_GRAPH_PRINT_IRQS 0x40
> #define TRACE_GRAPH_PRINT_TAIL 0x80
> +#define TRACE_GRAPH_MAX_LATENCY 0x100
> #define TRACE_GRAPH_PRINT_FILL_SHIFT 28
> #define TRACE_GRAPH_PRINT_FILL_MASK (0x3 << TRACE_GRAPH_PRINT_FILL_SHIFT)
>
> diff --git a/kernel/trace/trace_functions_graph.c
> b/kernel/trace/trace_functions_graph.c
> index ba476009e5de..7fc3e21d1354 100644
> --- a/kernel/trace/trace_functions_graph.c
> +++ b/kernel/trace/trace_functions_graph.c
> @@ -8,6 +8,7 @@
> */
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -44,6 +45,10 @@ void ftrace_graph_stop(void)
>
> /* When set, irq functions will be ignored */
> static int ftrace_graph_skip_irqs;
> +/* When set, record max latency of a given function */
> +static int ftrace_graph_max_latency;
> +
> +static unsigned long ftrace_graph_latency_func;
>
> struct fgraph_cpu_data {
> pid_t last_pid;
> @@ -84,6 +89,8 @@ static struct tracer_opt trace_opts[] = {
> { TRACER_OPT(funcgraph-irqs, TRACE_GRAPH_PRINT_IRQS) },
> /* Display function name after trailing } */
> { TRACER_OPT(funcgraph-tail, TRACE_GRAPH_PRINT_TAIL) },
> + /* Record max latency of a given function } */
> + { TRACER_OPT(funcgraph-latency, TRACE_GRAPH_MAX_LATENCY) },
> { } /* Empty entry */
> };
>
> @@ -389,6 +396,22 @@ trace_graph_function(struct trace_array *tr,
> __trace_graph_function(tr, ip, flags, pc);
> }
>
> +#ifdef CONFIG_TRACER_MAX_TRACE
> +static bool report_latency(struct trace_array *tr,
> +struct ftrace_graph_ret *trace)
> +{
> + unsigned long long delta = trace->rettime - trace->calltime;
> +
> + if
[PATCH v4] x86/boot/early_serial_console: Remove unnecessary check
There is already the same check before.
Signed-off-by: Alexander Kuleshov
---
arch/x86/boot/early_serial_console.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/early_serial_console.c
b/arch/x86/boot/early_serial_console.c
index 5df2869..2b1c403 100644
--- a/arch/x86/boot/early_serial_console.c
+++ b/arch/x86/boot/early_serial_console.c
@@ -74,8 +74,8 @@ static void parse_earlyprintk(void)
static const int bases[] = { 0x3f8, 0x2f8 };
int idx = 0;
- if (!strncmp(arg + pos, "ttyS", 4))
- pos += 4;
+ /* += strlen("ttyS"); */
+ pos += 4;
if (arg[pos++] == '1')
idx = 1;
--
2.2.1.202.g44ae4ee.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] arch/nios2 fixes for 3.19-rc3
Hi Linus, There are 2 arch/nios2 fixes for 3.19. Please consider pulling. Happy new year. Regards Ley Foon The following changes since commit b7392d2247cfe6771f95d256374f1a8e6a6f48d6: Linux 3.19-rc2 (2014-12-28 16:49:37 -0800) are available in the git repository at: git://git.rocketboards.org/linux-socfpga-next.git tags/nios2-fixes-v3.19-rc3 for you to fetch changes up to 1b0f44923e186b2f9383b3260f6b5fbfc77b9e4a: nios2: Use preempt_schedule_irq (2014-12-31 11:04:58 +0800) nios2 fixes for v3.19-rc3 - fix compilation error when enable CONFIG_PREEMPT - initialize cpuinfo.mmu variable supplied by the device tree Tobias Klauser (1): nios2: Use preempt_schedule_irq Walter Goossens (1): nios2: Initialize cpuinfo.mmu arch/nios2/kernel/cpuinfo.c | 1 + arch/nios2/kernel/entry.S | 20 ++-- 2 files changed, 3 insertions(+), 18 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fbdev: geocode: remove unneeded NULL check
the check for info is not required as we are checking it immediately
after gx1fb_init_fbinfo() and returnig -ENOMEM if it is NULL.
Signed-off-by: Sudip Mukherjee
---
drivers/video/fbdev/geode/gx1fb_core.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/geode/gx1fb_core.c
b/drivers/video/fbdev/geode/gx1fb_core.c
index 2794ba1..9bee874 100644
--- a/drivers/video/fbdev/geode/gx1fb_core.c
+++ b/drivers/video/fbdev/geode/gx1fb_core.c
@@ -374,10 +374,8 @@ static int gx1fb_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
release_mem_region(gx1_gx_base() + 0x8300, 0x100);
}
- if (info) {
- fb_dealloc_cmap(>cmap);
- framebuffer_release(info);
- }
+ fb_dealloc_cmap(>cmap);
+ framebuffer_release(info);
return ret;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mm: cma: /proc/cmainfo
Hello,
On Wed, Dec 31, 2014 at 09:58:04AM +0900, Gioh Kim wrote:
> 2014-12-30 오후 1:47에 Minchan Kim 이(가) 쓴 글:
> >On Mon, Dec 29, 2014 at 11:52:58AM -0800, Laura Abbott wrote:
> >>I've been meaning to write something like this for a while so I'm
> >>happy to see an attempt made to fix this. I can't speak for the
> >>author's reasons for wanting this information but there are
> >>several reasons why I was thinking of something similar.
> >>
> >>The most common bug reports seen internally on CMA are 1) CMA is
> >>too slow and 2) CMA failed to allocate memory. For #1, not all
> >>allocations may be slow so it's useful to be able to keep track
> >>of which allocations are taking too long. For #2, migration
> >
> >Then, I don't think we could keep all of allocations. What we need
> >is only slow allocations. I hope we can do that with ftrace.
> >
> >ex)
> >
> ># cd /sys/kernel/debug/tracing
> ># echo 1 > options/stacktrace
> ># echo cam_alloc > set_ftrace_filter
> ># echo your_threshold > tracing_thresh
> >
> >I know it doesn't work now but I think it's more flexible
> >and general way to handle such issues(ie, latency of some functions).
> >So, I hope we could enhance ftrace rather than new wheel.
> >Ccing ftrace people.
>
> For CMA performance test or code flow check, ftrace is better.
>
> ex)
> echo cma_alloc > /sys/kernel/debug/tracing/set_graph_function
> echo function_graph > /sys/kernel/debug/tracing/current_tracer
> echo funcgraph-proc > /sys/kernel/debug/tracing/trace_options
> echo nosleep-time > /sys/kernel/debug/tracing/trace_options
> echo funcgraph-tail > /sys/kernel/debug/tracing/trace_options
> echo 1 > /sys/kernel/debug/tracing/tracing_on
>
> This can trace every cam_alloc and allocation time.
> I think ftrace is better to debug latency.
> If a buffer had allocated and had peak latency and freed,
> we can check it.
It'd be great if we can reuse the max latency tracing feature for the
function graph tracer in order to track a latency problem of an
arbitrary function more easily. I've written a PoC code that can be
used like below..
# cd /sys/kernel/debug/tracing
# echo 0 > tracing_on
# echo function_graph > current_tracer
# echo funcgraph-latency > trace_options
# echo cma_alloc > graph_latency_func
# echo 1 > tracing_on
Now the tracing_max_latency file has a max latency of the cma_alloc()
in usec and the snapshot file contains a snapshot of all the codepath
to the function at the time.
Would anybody like to play with it? :)
Thanks,
Namhyung
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 0eddfeb05fee..4a3d5ed2802c 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -723,6 +723,7 @@ extern char trace_find_mark(unsigned long long duration);
#define TRACE_GRAPH_PRINT_ABS_TIME 0x20
#define TRACE_GRAPH_PRINT_IRQS 0x40
#define TRACE_GRAPH_PRINT_TAIL 0x80
+#define TRACE_GRAPH_MAX_LATENCY 0x100
#define TRACE_GRAPH_PRINT_FILL_SHIFT 28
#define TRACE_GRAPH_PRINT_FILL_MASK(0x3 << TRACE_GRAPH_PRINT_FILL_SHIFT)
diff --git a/kernel/trace/trace_functions_graph.c
b/kernel/trace/trace_functions_graph.c
index ba476009e5de..7fc3e21d1354 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -8,6 +8,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -44,6 +45,10 @@ void ftrace_graph_stop(void)
/* When set, irq functions will be ignored */
static int ftrace_graph_skip_irqs;
+/* When set, record max latency of a given function */
+static int ftrace_graph_max_latency;
+
+static unsigned long ftrace_graph_latency_func;
struct fgraph_cpu_data {
pid_t last_pid;
@@ -84,6 +89,8 @@ static struct tracer_opt trace_opts[] = {
{ TRACER_OPT(funcgraph-irqs, TRACE_GRAPH_PRINT_IRQS) },
/* Display function name after trailing } */
{ TRACER_OPT(funcgraph-tail, TRACE_GRAPH_PRINT_TAIL) },
+ /* Record max latency of a given function } */
+ { TRACER_OPT(funcgraph-latency, TRACE_GRAPH_MAX_LATENCY) },
{ } /* Empty entry */
};
@@ -389,6 +396,22 @@ trace_graph_function(struct trace_array *tr,
__trace_graph_function(tr, ip, flags, pc);
}
+#ifdef CONFIG_TRACER_MAX_TRACE
+static bool report_latency(struct trace_array *tr,
+ struct ftrace_graph_ret *trace)
+{
+ unsigned long long delta = trace->rettime - trace->calltime;
+
+ if (!ftrace_graph_max_latency)
+ return false;
+
+ if (ftrace_graph_latency_func != trace->func)
+ return false;
+
+ return tr->max_latency < delta;
+}
+#endif
+
void __trace_graph_return(struct trace_array *tr,
struct ftrace_graph_ret *trace,
unsigned long flags,
@@ -428,6 +451,22 @@ void trace_graph_return(struct ftrace_graph_ret *trace)
if (likely(disabled == 1)) {
pc = preempt_count();
[PATCH] [BUGFIX] perf-probe: Fix to fall back to find probe point in symbols
Fix to fall back to find a probe point in symbols if perf fails
to find it in debuginfo.
This can happen when the target function is an alias of another
function. Such alias doesn't have an entry in debuginfo but in
symbols.
David Ahern reported this problem in https://lkml.org/lkml/2014/12/29/355
I ensured the problem and deeper investigation discovers it.
-
eu-readelf --debug-dump=info /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so
| grep \"malloc\" -A6
name (strp) "malloc"
decl_file(data1) 25
decl_line(data2) 466
prototyped (flag_present)
type (ref4) [ 81b5]
declaration (flag_present)
[ 8f58] formal_parameter
--
name (strp) "malloc"
decl_file(data1) 23
decl_line(data2) 466
prototyped (flag_present)
type (ref4) [ 9f4a]
declaration (flag_present)
sibling (ref4) [ bb29]
...
-
All these entires have no instances (all of them are declarations)
This is why the perf probe failed to find it in debuginfo.
However, there are some malloc instances in symbols.
-
eu-readelf --symbols /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so | grep
malloc$
1181: 00080700 5332 FUNCLOCAL DEFAULT 12 _int_malloc
4537: 000831d0339 FUNCLOCAL DEFAULT 12
__GI___libc_malloc
5545: 000831d0339 FUNCLOCAL DEFAULT 12 __malloc
6063: 000831d0339 FUNCGLOBAL DEFAULT 12 malloc
7302: 000831d0339 FUNCGLOBAL DEFAULT 12 __libc_malloc
-
As you an see, malloc and __libc_malloc have same address, and actually
__libc_malloc has an entry in debuginfo. So you can set up a probe on
__libc_malloc.
To fix this problem shortly, perf probe simply falls back to find probe
point(malloc) in symbols if it is not found in debuginfo.
Signed-off-by: Masami Hiramatsu
Reported-by: David Ahern
---
tools/perf/util/probe-event.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 28eb141..7f9b863 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -495,9 +495,11 @@ static int try_to_find_probe_trace_events(struct
perf_probe_event *pev,
}
if (ntevs == 0) { /* No error but failed to find probe point. */
- pr_warning("Probe point '%s' not found.\n",
+ pr_warning("Probe point '%s' not found in debuginfo.\n",
synthesize_perf_probe_point(>point));
- return -ENOENT;
+ if (need_dwarf)
+ return -ENOENT;
+ return 0;
}
/* Error path : ntevs < 0 */
pr_debug("An error occurred in debuginfo analysis (%d).\n", ntevs);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bug#772807: binfmt-support: unable to close /proc/sys/fs/binfmt_misc/register: Invalid argument
On 12 Dec 2014 06:01, Al Viro wrote:
> On Fri, Dec 12, 2014 at 02:51:55PM +1030, Arthur Marsh wrote:
> > 6b899c4e9a049dfca759d990bd53b14f81c3626c is the first bad commit
> > commit 6b899c4e9a049dfca759d990bd53b14f81c3626c
> > Author: Mike Frysinger
> > Date: Wed Dec 10 15:52:08 2014 -0800
> >
> > binfmt_misc: add comments & debug logs
> >
> > When trying to develop a custom format handler, the errors returned all
> > effectively get bucketed as EINVAL with no kernel messages. The other
> > errors (ENOMEM/EFAULT) are internal/obvious and basic. Thus any time a
> > bad handler is rejected, the developer has to walk the dense code and
> > try to guess where it went wrong. Needing to dive into kernel code is
> > itself a fairly high barrier for a lot of people.
> >
> > To improve this situation, let's deploy extensive pr_debug markers at
> > logical parse points, and add comments to the dense parsing logic. It
> > let's you see exactly where the parsing aborts, the string the kernel
> > received (useful when dealing with shell code), how it translated the
> > buffers to binary data, and how it will apply the mask at runtime.
>
> ... and looking at it shows the following garbage:
> p[-1] = '\0';
> - if (!e->magic[0])
> + if (p == e->magic)
>
> That code makes no sense whatsoever - if p *was* equal to e->magic, the
> assignment before it would be obviously broken. And a few lines later we
> have another chunk just like that.
>
> Moreover, if you look at further context, you'll see that it's
> e->magic = p;
> p = scanarg(p, del);
> if (!p)
> sod off
> p[-1] = '\0';
> if (p == e->magic)
> sod off
> Now, that condition could be true only if scanarg(p, del) would return p,
> right? Let's take a look at scanarg():
> static char *scanarg(char *s, char del)
> {
> char c;
>
> while ((c = *s++) != del) {
> if (c == '\\' && *s == 'x') {
> s++;
> if (!isxdigit(*s++))
> return NULL;
> if (!isxdigit(*s++))
> return NULL;
> }
> }
> return s;
> }
>
> See that s++ in the loop condition? There's no way in hell it would *not*
> increment s. If we return non-NULL, we know that c was equal to del *and*
> c is equal to previous_value_of_s[0], i.e. s[-1]. IOW, return value points
> to the byte following the first instance of delimeter starting at the
> argument.
>
> And p[-1] = '\0' replaces delimiter with NUL. IOW, the checks used to be
> correct. And got buggered.
the checks are not correct. magic & mask are binary fields hence checking for
a
NUL byte to indicate string parsing failed makes no sense. your patch restores
the bug i attempted to fix -- if i wanted to ignore the first byte of the file
by setting the mask or magic to 0, then binfmt_misc will wrongly reject it.
the current code does reject some bad inputs -- namely, when the magic or mask
is not specified. i was counting on the scanarg not incrementing the pointer
in
that case, but as you pointed out, that doesn't work since the func always
increments the pointer. i'll see if i can handle both cases.
> Subject: unfuck fs/binfmt_misc.c
>
> Undo some of the "prettifying" braindamage.
commit 7d65cf10e3d7747033b83fa18c5f3d2a498f66bc has merged at this point, but
the attribution to e6084d4 is wrong. of course coding style changes &
functional changes shouldn't be done which is why i didn't do it. the change
you're referring to above has nothing to do e6084d4 as it was added before that
in 6b899c4e9a049dfca759d990bd53b14f81c3626c (where i added extended debug
output). arguably those few non-debug related lines shouldn't be in that
commit, but it's a long cry from style changes.
-mike
signature.asc
Description: Digital signature
Re: [PATCH] tty: 8250: Add 64byte UART support for FSL platforms
On Tue, 2014-12-30 at 15:08 +0530, Vijay Rai wrote:
> Some of FSL SoCs like T1040 has new version of UART controller which
> can support 64byte FiFo.
> To enable 64 byte support, following needs to be done:
> -FCR[EN64] needs to be programmed to 1 to enable it.
> -Also, when FCR[EN64]==1, RTL bits to be used as below
> to define various Receive Trigger Levels:
> -FCR[RTL] = 00 1 byte
> -FCR[RTL] = 01 16 bytes
> -FCR[RTL] = 10 32 bytes
> -FCR[RTL] = 11 56 bytes
> -tx_loadsz is set to 32-bytes instead of 64-bytes to implement
> workaround of errata A-008006 which states that tx_loadsz should
> be configured less than Maximum supported fifo bytes
Why 32 and not 63?
> Signed-off-by: Vijay Rai
> Signed-off-by: Priyanka Jain
> Signed-off-by: Poonam Aggrwal
> ---
> drivers/tty/serial/8250/8250_core.c | 20 +++-
> include/uapi/linux/serial_core.h|3 ++-
> include/uapi/linux/serial_reg.h |3 ++-
> 3 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_core.c
> b/drivers/tty/serial/8250/8250_core.c
> index 11c6685..565748c 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -329,6 +329,14 @@ static const struct serial8250_config uart_config[] = {
> .fcr= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
> .flags = UART_CAP_FIFO | UART_CAP_AFE,
> },
> + [PORT_16550A_FSL64] = {
> + .name = "16550A_FSL64",
> + .fifo_size = 64,
> + .tx_loadsz = 32,
Put a comment here mentioning the erratum.
> diff --git a/include/uapi/linux/serial_core.h
> b/include/uapi/linux/serial_core.h
> index c172180..a3b4491 100644
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -55,7 +55,8 @@
> #define PORT_ALTR_16550_F64 27 /* Altera 16550 UART with 64 FIFOs */
> #define PORT_ALTR_16550_F128 28 /* Altera 16550 UART with 128 FIFOs */
> #define PORT_RT2880 29 /* Ralink RT2880 internal UART */
> -#define PORT_MAX_825029 /* max port ID */
> +#define PORT_16550A_FSL64 30 /* Freescale 16550 UART with 64 FIFOs */
> +#define PORT_MAX_825031 /* max port ID */
Why are you adding 2 to PORT_MAX_8250 when you only add one new type?
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: Add entry for dell-laptop sysfs interface
Hi, On Wed, Dec 03, 2014 at 06:41:33PM +0100, Gabriele Mazzotta wrote: > Add the documentation for the new sysfs interface of dell-laptop > that allows to configure the keyboard illumination on Dell systems. > > Signed-off-by: Gabriele Mazzotta > Signed-off-by: Pali Rohár > --- > .../ABI/testing/sysfs-platform-dell-laptop | 60 > ++ > 1 file changed, 60 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-laptop > > diff --git a/Documentation/ABI/testing/sysfs-platform-dell-laptop > b/Documentation/ABI/testing/sysfs-platform-dell-laptop > new file mode 100644 > index 000..7969443 > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-platform-dell-laptop > @@ -0,0 +1,60 @@ > +What:/sys/class/leds/dell::kbd_backlight/als_setting > +Date:December 2014 > +KernelVersion: 3.19 > +Contact: Gabriele Mazzotta , > + Pali Rohár > +Description: > + This file allows to control the automatic keyboard > + illumination mode on some systems that have an ambient > + light sensor. Write 1 to this file to enable the auto > + mode, 0 to disable it. [...] This entry appears wrong, or at least incomplete. My system boots with a default value of 18, and the 'set' implementation accepts any value from 0 to 255. According to the comments in dell-laptop.c, the value actually means something different than on/off: cbArg3, byte0 Desired setting of ALS value that turns the light on or off. Admittedly, I'm not clear on what the intended interface is, as I've never had the ALS / keyboard backlight controls all working properly on my laptop in the first place, but I thought this would be the right place to ask about getting the documentation and driver in sync. NB: I came across this because (1) I'd really like to be able to turn the keyboard backlight on, the timeout off, and the ALS off; and (2) I noticed there was a new driver patch in 3.19 (nice! thanks!), where previously there must have been some kind of half-functional working driver -- I could get backlight control, but it always timed out too quickly. It seems like /sys/.../als_setting is documented to handle the latter part of (1), but its implementation does not match. Thanks, Brian P.S. The author of this page [1] might be interested in these new driver additions. [1] http://www.cs.bham.ac.uk/~axs/laptop/dell-e6410-fn-keys.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCHv2 2/8] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
This patch adds the documentation for generic exynos memory bus frequency
driver.
Cc: MyungJoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
.../devicetree/bindings/devfreq/exynos-busfreq.txt | 184 +
1 file changed, 184 insertions(+)
create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
new file mode 100644
index 000..c601e88
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt
@@ -0,0 +1,184 @@
+
+* Generic Exynos Memory Bus device
+
+The Samsung Exynos SoCs have many memory buses for data transfer between DRAM
+memory and MMC/sub-IP in SoC. Almost Exynos SoCs have the common architecture
+for memory buses. Generally, Exynos SoC express the memory bus by using memory
+bus group and block. The memory bus group has one more memory bus blocks and
+OPP table (including frequency and voltage for DVFS), regulator, devfreq-event
+devices. Each memory bus block has a clock for own memory bus speen and
+frequency table for DVFS. There are a little different among Exynos SoCs
+because each Exynos SoC has the different sub-IP and differnt memory bus.
+So, this difference should be specified in devicetree file.
+
+Required properties for memory bus group:
+- compatible: Should be "samsung,exynos-memory-bus".
+- operating-points: the OPP table including frequency/voltage information to
+ support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+- devfreq-events: the devfreq-event device to monitor the curret state of
+ memory bus group.
+- vdd-mem-supply: the regulator to provide memory bus group with the voltage.
+
+Required properties for memory bus block:
+- clock-names : the name of clock used by the memory bus, "memory-bus".
+- clocks : phandles for clock specified in "clock-names" property.
+- #clock-cells: should be 1.
+- frequency: the frequency table to support DVFS feature.
+
+Example1 : Memory bus group/block in exynos3250.dtsi are listed below.
+ Exynos3250 has two memory bus group (MIF, INT group). MIF memory bus
+ group includes one memory bus block between DRAM and eMMC. Also, INT
+ memory bus group includes eight memory bus blocks which support each
+ sub-IPs between DRAM and sub-IPs.
+
+ memory_bus_mif: memory_bus@0 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 40 875000
+ 20 80
+ 133000 80
+ 10 80
+ 5 80>;
+ status = "disabled";
+
+ blocks {
+ dmc_block: memory_bus_block1 {
+ clocks = <_dmc CLK_DIV_DMC>;
+ clock-names = "memory-bus";
+ frequency = <
+ 40
+ 20
+ 133000
+ 10
+ 5>;
+ };
+ };
+ };
+
+ memory_bus_int: memory_bus@1 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 40 95
+ 20 95
+ 133000 925000
+ 10 85
+ 8 85
+ 5 85>;
+
+ status = "disabled";
+
+ blocks {
+ peri_block: memory_bus_block1 {
+ clocks = < CLK_DIV_ACLK_100>;
+ clock-names = "memory-bus";
+ frequency = <
+ 10
+ 10
+ 10
+ 10
+ 5
+ 5>;
+ };
+
+ display_block: memory_bus_block2 {
+ clocks = < CLK_DIV_ACLK_160>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 10
+ 8
+ 8
+ 5>;
+ };
+
+ isp_block: memory_bus_block3 {
+ clocks = < CLK_DIV_ACLK_200>;
+ clock-names =
[RFC PATCHv2 7/8] ARM: dts: Add memory bus node for Exynos3250-based Rinato board
This patch adds the Exynos3250 memory-bus node which includes the regulator
and devfreq-event phandle. The devfreq-event phandle is used for the
governor of devfreq device and provide the current usage state of
MIF (Memory Interface) / INT (Internal) memory bus group.
Cc: Kukjin Kim
Cc: Myungjoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos3250-rinato.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 60948ae..6722555 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -564,6 +564,18 @@
};
};
+_bus_mif {
+ devfreq-events = <_dmc0_3>, <_dmc1_3>;
+ vdd-mem-supply = <_reg>;
+ status = "okay";
+};
+
+_bus_int {
+ devfreq-events = <_leftbus_3>, <_rightbus_3>;
+ vdd-mem-supply = <_reg>;
+ status = "okay";
+};
+
{
clock-frequency = <2400>;
};
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCHv2 1/8] devfreq: exynos: Add generic exynos memory bus frequency driver
This patch adds the generic exynos bus frequency driver for memory bus
with DEVFREQ framework. The Samsung Exynos SoCs have the common architecture
for memory bus between DRAM memory and MMC/sub IP in SoC. This driver can
support the memory bus frequency driver for Exynos SoCs.
Each memory bus block has a clock for memory bus speed and frequency
table which is changed according to the utilization of memory bus on runtime.
And then each memory bus group has the one more memory bus blocks and
OPP table (including frequency and voltage), regulator, devfreq-event
devices.
There are a little difference about the number of memory bus because each Exynos
SoC have the different sub-IP and different memory bus speed. In spite of this
difference among Exynos SoCs, we can support almost Exynos SoC by adding
unique data of memory bus to devicetree file.
Cc: Myungjoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/Kconfig | 15 +
drivers/devfreq/Makefile | 1 +
drivers/devfreq/exynos-busfreq.c | 588 +++
3 files changed, 604 insertions(+)
create mode 100644 drivers/devfreq/exynos-busfreq.c
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 21f8f17..f1003eb 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -65,6 +65,21 @@ config DEVFREQ_GOV_USERSPACE
comment "DEVFREQ Drivers"
+config ARM_EXYNOS_BUS_DEVFREQ
+ bool "EXYNOS Memory Bus DEVFREQ Driver"
+ depends on ARCH_EXYNOS
+ select DEVFREQ_GOV_SIMPLE_ONDEMAND
+ select DEVFREQ_EVENT_EXYNOS_PPMU
+ select PM_DEVFREQ_EVENT
+ select PM_OPP
+ help
+ This adds the common DEVFREQ driver for Exynos Memory bus. Exynos
+ Memory bus has one more group of memory bus (e.g, MIF and INT block).
+ Each memory bus group could contain many memoby bus block. It reads
+ PPMU counters of memory controllers by using DEVFREQ-event device
+ and adjusts the operating frequencies and voltages with OPP support.
+ This does not yet operate with optimal voltages.
+
config ARM_EXYNOS4_BUS_DEVFREQ
bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) &&
!ARCH_MULTIPLATFORM
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index c449336..2b82a4c 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o
obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o
# DEVFREQ Drivers
+obj-$(CONFIG_ARCH_EXYNOS) += exynos-busfreq.o
obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos/
obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos/
diff --git a/drivers/devfreq/exynos-busfreq.c b/drivers/devfreq/exynos-busfreq.c
new file mode 100644
index 000..3c92541
--- /dev/null
+++ b/drivers/devfreq/exynos-busfreq.c
@@ -0,0 +1,588 @@
+/*
+ * Generic Exynos Memory Bus Frequency driver with DEVFREQ Framework
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author : Chanwoo Choi
+ *
+ * This driver is based on exynos4_bus.c, which was written
+ * by MyungJoo Ham , Samsung Electronics.
+ *
+ * This driver support Exynos Memory Bus frequency feature by using in DEVFREQ
+ * framework. This version supprots Exynos3250/Exynos4 series/Exynos5260 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BUS_SATURATION_RATIO 40
+#define SAFEVOLT 5
+
+struct exynos_memory_bus_opp_info {
+ unsigned long rate;
+ unsigned long volt;
+};
+
+struct exynos_memory_bus_block {
+ struct clk *clk;
+ struct exynos_memory_bus_opp_info *freq_table;
+};
+
+struct exynos_memory_bus_data {
+ /* devfreq device to monitor and control memory bus group */
+ struct device *dev;
+ struct devfreq *devfreq;
+
+ struct exynos_memory_bus_opp_info *freq_table;
+ unsigned int freq_count;
+ struct regulator *regulator;
+ struct mutex lock;
+
+ struct exynos_memory_bus_opp_info curr_opp;
+
+ struct exynos_memory_bus_block *block;
+ unsigned int block_count;
+
+ /* devfreq-event device to get current state of memory bus group */
+ struct devfreq_event_dev **edev;
+ unsigned int edev_count;
+};
+
+/*
+ * Initialize the memory bus group/block by parsing dt node in the devicetree
+ */
+static int of_init_memory_bus(struct device_node *np,
+ struct exynos_memory_bus_data *data)
+{
+ struct device *dev = data->dev;
+ struct dev_pm_opp *opp;
+ unsigned long rate, volt;
+ int i, ret,
[RFC PATCHv2 4/8] clk: samsung: exynos4: Add divider clock id for memory bus frequency
This patch adds the divider clock id for Exynos4 memory bus frequency.
The clock id is used fo DVFS (Dynamic Voltage/Frequency Scaling)
feature of exynos memory bus frequency.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
---
drivers/clk/samsung/clk-exynos4.c | 10 +-
include/dt-bindings/clock/exynos4.h | 7 ++-
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 88e8c6b..51462e8 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -703,12 +703,12 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
__initdata = {
/* list of divider clocks supported in all exynos4 soc's */
static struct samsung_div_clock exynos4_div_clks[] __initdata = {
- DIV(0, "div_gdl", "mout_gdl", DIV_LEFTBUS, 0, 3),
+ DIV(CLK_DIV_GDL, "div_gdl", "mout_gdl", DIV_LEFTBUS, 0, 3),
DIV(0, "div_gpl", "div_gdl", DIV_LEFTBUS, 4, 3),
DIV(0, "div_clkout_leftbus", "mout_clkout_leftbus",
CLKOUT_CMU_LEFTBUS, 8, 6),
- DIV(0, "div_gdr", "mout_gdr", DIV_RIGHTBUS, 0, 3),
+ DIV(CLK_DIV_GDR, "div_gdr", "mout_gdr", DIV_RIGHTBUS, 0, 3),
DIV(0, "div_gpr", "div_gdr", DIV_RIGHTBUS, 4, 3),
DIV(0, "div_clkout_rightbus", "mout_clkout_rightbus",
CLKOUT_CMU_RIGHTBUS, 8, 6),
@@ -781,10 +781,10 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
CLK_SET_RATE_PARENT, 0),
DIV(0, "div_clkout_top", "mout_clkout_top", CLKOUT_CMU_TOP, 8, 6),
- DIV(0, "div_acp", "mout_dmc_bus", DIV_DMC0, 0, 3),
+ DIV(CLK_DIV_ACP, "div_acp", "mout_dmc_bus", DIV_DMC0, 0, 3),
DIV(0, "div_acp_pclk", "div_acp", DIV_DMC0, 4, 3),
DIV(0, "div_dphy", "mout_dphy", DIV_DMC0, 8, 3),
- DIV(0, "div_dmc", "mout_dmc_bus", DIV_DMC0, 12, 3),
+ DIV(CLK_DIV_DMC, "div_dmc", "mout_dmc_bus", DIV_DMC0, 12, 3),
DIV(0, "div_dmcd", "div_dmc", DIV_DMC0, 16, 3),
DIV(0, "div_dmcp", "div_dmcd", DIV_DMC0, 20, 3),
DIV(0, "div_pwi", "mout_pwi", DIV_DMC1, 8, 4),
@@ -829,7 +829,7 @@ static struct samsung_div_clock exynos4x12_div_clks[]
__initdata = {
DIV_F(CLK_DIV_MCUISP1, "div_mcuisp1", "div_mcuisp0", E4X12_DIV_ISP1,
8, 3, CLK_GET_RATE_NOCACHE, 0),
DIV(CLK_SCLK_FIMG2D, "sclk_fimg2d", "mout_g2d", DIV_DMC1, 0, 4),
- DIV(0, "div_c2c", "mout_c2c", DIV_DMC1, 4, 3),
+ DIV(CLK_DIV_C2C, "div_c2c", "mout_c2c", DIV_DMC1, 4, 3),
DIV(0, "div_c2c_aclk", "div_c2c", DIV_DMC1, 12, 3),
};
diff --git a/include/dt-bindings/clock/exynos4.h
b/include/dt-bindings/clock/exynos4.h
index 34fe28c..c4b1676 100644
--- a/include/dt-bindings/clock/exynos4.h
+++ b/include/dt-bindings/clock/exynos4.h
@@ -262,8 +262,13 @@
#define CLK_DIV_MCUISP1453 /* Exynos4x12 only */
#define CLK_DIV_ACLK200454 /* Exynos4x12 only */
#define CLK_DIV_ACLK400_MCUISP 455 /* Exynos4x12 only */
+#define CLK_DIV_ACP456
+#define CLK_DIV_DMC457
+#define CLK_DIV_C2C458 /* Exynos4x12 only */
+#define CLK_DIV_GDL459
+#define CLK_DIV_GDR460
/* must be greater than maximal clock id */
-#define CLK_NR_CLKS456
+#define CLK_NR_CLKS461
#endif /* _DT_BINDINGS_CLOCK_EXYNOS_4_H */
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCHv2 3/8] ARM: dts: Add memory bus node for Exynos3250
This patch adds the memory bus node for Exynos3250 SoC. Exynos3250 has
following memory buses to translate data between DRAM and eMMC/sub-IPs.
Following list specifies the detailed relation between memory bus clock and DMC
IP in MIF (Memory Interface) block:
- DMC clock : DMC (Dynamic Memory Controller)
Following list specifies the detailed relation between memory bus clock and
sub-IPs in INT (Internal) block:
- ACLK100 clock : PERIL
- ACLK160 clock : LCD0
- ACLK200 clock : FSYS
- ACLK266 clock : ISP
- GDL/GDR clock : leftbus/rightbus
- SCLK_MFC clock : MFC
Cc: Kukjin Kim
Cc: Myungjoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos3250.dtsi | 125 ++
1 file changed, 125 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 9ed1260..3eaed53 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -99,6 +99,131 @@
};
};
+ memory_bus_mif: memory_bus@0 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 40 875000
+ 20 80
+ 133000 80
+ 10 80
+ 5 80>;
+ status = "disabled";
+
+ blocks {
+ dmc_block: memory_bus_block1 {
+ clocks = <_dmc CLK_DIV_DMC>;
+ clock-names = "memory-bus";
+ frequency = <
+ 40
+ 20
+ 133000
+ 10
+ 5>;
+ };
+ };
+ };
+
+ memory_bus_int: memory_bus@1 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 40 95
+ 20 95
+ 133000 925000
+ 10 85
+ 8 85
+ 5 85>;
+
+ status = "disabled";
+
+ blocks {
+ peril_block: memory_bus_block1 {
+ clocks = < CLK_DIV_ACLK_100>;
+ clock-names = "memory-bus";
+ frequency = <
+ 10
+ 10
+ 10
+ 10
+ 5
+ 5>;
+ };
+
+ lcd0_block: memory_bus_block2 {
+ clocks = < CLK_DIV_ACLK_160>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 10
+ 8
+ 8
+ 5>;
+ };
+
+ fsys_block: memory_bus_block3 {
+ clocks = < CLK_DIV_ACLK_200>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 20
+ 10
+ 8
+ 5
+ 5>;
+ };
+
+ isp_block: memory_bus_block4 {
+ clocks = < CLK_DIV_ACLK_266>;
+ clock-names = "memory-bus";
+ frequency = <
+ 30
+ 20
+ 133000
+
Re: [PATCH] staging: lustre: linux-prim.c: fix sparse warnings about static declaration
On Tue, Dec 30, 2014 at 07:04:35PM -0800, Serguey Parkhomovsky wrote: > On Tue, Dec 30, 2014 at 02:35:18PM -0800, Jeremiah Mahler wrote: > > > > If you look at the source code just below these functions you will find: > > > > EXPORT_SYMBOL(libcfs_arch_init); > > EXPORT_SYMBOL(libcfs_arch_cleanup); > > > > So making these static is incorrect because they are being used outside > > of this file. > > > > Thanks for the review, and sorry about the noise; I'll be more careful next > time. these tools are there to help you find the problems in the code.but after that we need to use our own judgement to decide. in this case the solution is to declare them in libcfs.h and please atleast buildtest your patch before sending. If you would have compiled this patch then you could have seen 2 new warnings: "WARNING: "libcfs_arch_init" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] undefined!" "WARNING: "libcfs_arch_cleanup" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] undefined!" thanks sudip > > Serguey > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCHv2 5/8] ARM: dts: Add memory bus node for Exynos4x12
This patch adds the memory bus node for Exynos4x12 SoC. Exynos4x12 SoC has
two memory bus to translate data between DRAM and eMMC/sub-IPs.
Following list specifies the detailed relation between memory bus clock and DMC
IP in MIF (Memory Interface) block:
- DMC/ACP clock : DMC (Dynamic Memory Controller)
Following list specifies the detailed relation between memory bus clock and
sub-IPs in INT (Internal) block:
- ACLK100 clock : PERIL/PERIR/MFC(PCLK)
- ACLK160 clock : CAM/TV/LCD
- ACLK133 clock : FSYS
- GDL/GDR clock : leftbus/rightbus
- SCLK_MFC clock : MFC
Cc: Kukjin Kim
Cc: Myungjoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4x12.dtsi | 121 ++
1 file changed, 121 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 93b7040..44f6272 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -31,6 +31,127 @@
mshc0 = _0;
};
+ memory_bus_mif: memory_bus@0 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 40 110
+ 20 100
+ 16 95
+ 133000 95
+ 10 95>;
+ status = "disabled";
+
+ blocks {
+ dmc_block: memory_bus_block1 {
+ clocks = < CLK_DIV_DMC>;
+ clock-names = "memory-bus";
+ frequency = <
+ 40
+ 20
+ 16
+ 133000
+ 10>;
+ };
+
+ acp_block: memory_bus_block2 {
+ clocks = < CLK_DIV_ACP>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 133000
+ 133000
+ 10>;
+ };
+
+ c2c_block: memory_bus_block3 {
+ clocks = < CLK_DIV_C2C>;
+ clock-names = "memory-bus";
+ frequency = <
+ 40
+ 20
+ 16
+ 133000
+ 10>;
+ };
+ };
+ };
+
+ memory_bus_int: memory_bus@1 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 20 100
+ 16 95
+ 133000 925000
+ 10 90>;
+
+ status = "disabled";
+
+ blocks {
+ peri_block: memory_bus_block1 {
+ clocks = < CLK_ACLK100>;
+ clock-names = "memory-bus";
+ frequency = <
+ 10
+ 10
+ 10
+ 10>;
+ };
+
+ fsys_block: memory_bus_block2 {
+ clocks = < CLK_ACLK133>;
+ clock-names = "memory-bus";
+ frequency = <
+ 133000
+ 133000
+ 10
+ 10>;
+ };
+
+ display_block: memory_bus_block3 {
+ clocks = < CLK_ACLK160>;
+ clock-names = "memory-bus";
+ frequency = <
+ 16
+ 16
+ 133000
+ 10>;
+ };
+
+ leftbus_block: memory_bus_block4 {
+ clocks = < CLK_DIV_GDL>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 133000
+ 10>;
+
[RFC PATCHv2 0/8] devfreq: Add generic exynos memory-bus frequency driver
This patch-set adds the generic exynos bus frequency driver for memory bus with DEVFREQ framework. The Samsung Exynos SoCs have the common architecture for memory bus between DRAM memory and MMC/sub IP in SoC. This driver can support the memory bus frequency driver for Exynos SoCs. Each memory bus block has a clock for memory bus speed and frequency table which is changed according to the utilization of memory bus on runtime. And then each memory bus group has the one more memory bus blocks and OPP table (including frequency and voltage), regulator, devfreq-event devices. There are a little difference about the number of memory bus because each Exynos SoC have the different sub-IP and different memory bus speed. In spite of this difference among Exynos SoCs, we can support almost Exynos SoC by adding unique data of memory bus to devicetree file. This patch-set has the dependency on following patch-set[1]: [1] [PATCHv6 0/9] devfreq: Add devfreq-event class to provide raw data for devfreq device - https://lkml.org/lkml/2014/12/28/139 Changes from v1: - This patchset is rebased on v3.19-rc2. - Fix bug after wake-up from suspend state. If devfreq device fail to get event, exynos-busfreq retry to set the event for starting. - Add memory bus group of Exynos4x12/Exynos4210 - Add divider clock id for Exynos4 memory bus frequency - Support memory bus frequency driver on Exynos4412-based TRATS2 board Chanwoo Choi (8): devfreq: exynos: Add generic exynos memory bus frequency driver devfreq: exynos: Add documentation for generic exynos memory bus frequency driver ARM: dts: Add memory bus node for Exynos3250 clk: samsung: exynos4: Add divider clock id for memory bus frequency ARM: dts: Add memory bus node for Exynos4x12 ARM: dts: Add memory bus node for Exynos4210 ARM: dts: Add memory bus node for Exynos3250-based Rinato board ARM: dts: Add memory bus node for Exynos4412-based TRATS2 board .../devicetree/bindings/devfreq/exynos-busfreq.txt | 184 +++ arch/arm/boot/dts/exynos3250-rinato.dts| 12 + arch/arm/boot/dts/exynos3250.dtsi | 125 + arch/arm/boot/dts/exynos4210.dtsi | 93 arch/arm/boot/dts/exynos4412-trats2.dts| 12 + arch/arm/boot/dts/exynos4x12.dtsi | 121 + drivers/clk/samsung/clk-exynos4.c | 10 +- drivers/devfreq/Kconfig| 15 + drivers/devfreq/Makefile | 1 + drivers/devfreq/exynos-busfreq.c | 588 + include/dt-bindings/clock/exynos4.h| 7 +- 11 files changed, 1162 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-busfreq.txt create mode 100644 drivers/devfreq/exynos-busfreq.c -- 1.8.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCHv2 8/8] ARM: dts: Add memory bus node for Exynos4412-based TRATS2 board
This patch adds the Exynos4412 memory-bus node which includes the regulator
and devfreq-event phandle. The devfreq-event phandle is used for the
governor of devfreq device and provide the current usage state of
MIF (Memory Interface) / INT (Internal) memory bus group.
Cc: Kukjin Kim
Cc: Myungjoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4412-trats2.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index bee0eed..21ba25e 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -917,6 +917,18 @@
};
};
+_bus_mif {
+ devfreq-events = <_dmc0_3>, <_dmc1_3>;
+ vdd-mem-supply = <_reg>;
+ status = "okay";
+};
+
+_bus_int {
+ devfreq-events = <_leftbus_3>, <_rightbus_3>;
+ vdd-mem-supply = <_reg>;
+ status = "okay";
+};
+
_0 {
pinctrl-names = "default";
pinctrl-0 = <>;
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCHv2 6/8] ARM: dts: Add memory bus node for Exynos4210
This patch adds the memory bus node for Exynos4210 SoC. Exynos4210 SoC has
one memory bus to translate data between DRAM and eMMC/sub-IPs because
Exynos4210 must need only one regulator for memory bus.
Following list specifies the detailed relation between memory bus clock and
sub-IPs:
- DMC/ACP clock : DMC (Dynamic Memory Controller)
- ACLK200 clock : LCD0
- ACLK100 clock : PERIL/PERIR/MFC(PCLK)
- ACLK160 clock : CAM/TV/LCD0/LCD1
- ACLK133 clock : FSYS/GPS
- GDL/GDR clock : leftbus/rightbus
- SCLK_MFC clock : MFC
Cc: Kukjin Kim
Cc: Myungjoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4210.dtsi | 93 +++
1 file changed, 93 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index b2598de..c039409 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -48,6 +48,99 @@
};
};
+ memory_bus: memory_bus@0 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 40 115
+ 267000 105
+ 133000 1025000>;
+ status = "disabled";
+
+ blocks {
+ dmc_block: memory_bus_block1 {
+ clocks = < CLK_DIV_DMC>;
+ clock-names = "memory-bus";
+ frequency = <
+ 40
+ 267000
+ 133000>;
+ };
+
+ acp_block: memory_bus_block2 {
+ clocks = < CLK_DIV_ACP>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 133000>;
+ };
+
+ peri_block: memory_bus_block3 {
+ clocks = < CLK_ACLK100>;
+ clock-names = "memory-bus";
+ frequency = <
+ 10
+ 10
+ 10>;
+ };
+
+ fsys_block: memory_bus_block4 {
+ clocks = < CLK_ACLK133>;
+ clock-names = "memory-bus";
+ frequency = <
+ 133000
+ 133000
+ 10>;
+ };
+
+ display_block: memory_bus_block5 {
+ clocks = < CLK_ACLK160>;
+ clock-names = "memory-bus";
+ frequency = <
+ 16
+ 133000
+ 10>;
+ };
+
+ lcd0_block: memory_bus_block6 {
+ clocks = < CLK_ACLK200>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 10>;
+ };
+
+ leftbus_block: memory_bus_block7 {
+ clocks = < CLK_DIV_GDL>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 10>;
+ };
+
+ rightbus_block: memory_bus_block8 {
+ clocks = < CLK_DIV_GDR>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 10>;
+ };
+
+ mfc_block: memory_bus_block9 {
+ clocks = < CLK_SCLK_MFC>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 10>;
+ };
+ };
+ };
+
pmu_system_controller: system-controller@1002 {
clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
Re: [PATCH] tick/powerclamp: Remove tick_nohz_idle abuse
Hi Jacob, On 12/23/2014 08:27 AM, Jacob Pan wrote: > On Sat, 20 Dec 2014 07:01:12 +0530 > Preeti U Murthy wrote: > >> On 12/20/2014 01:26 AM, Thomas Gleixner wrote: >>> On Fri, 19 Dec 2014, Jacob Pan wrote: >>> On Thu, 18 Dec 2014 22:12:57 +0100 (CET) Thomas Gleixner wrote: > On Thu, 18 Dec 2014, Jacob Pan wrote: >> OK I agree, also as I mentioned earlier, Peter already has a >> patch for consolidated idle loop and remove >> tick_nohz_idle_enter/exit call from powerclamp driver. I have >> been working on a few tweaks to maintain the functionality and >> efficiency with the consolidated idle loop. We can apply the >> patches on top of yours. > > No. This is equally wrong as I pointed out before. The 'unified' > idle loop is still fake and just pretending to be idle. > In terms of efficiency, the consolidated idle loop will allow turning off sched tick during idle injection period. If we just take out the tick_nohz_idle_xxx call, the effectiveness of powerclamp is going down significantly. I am not arguing the design but from fixing regression perspective or short term solution. >>> >>> There is no perspective. Period. >>> >>> Its violates every rightful assumption of the nohz_IDLE_* code and >>> just ever worked by chance. There is so much subtle wreckage lurking >>> there that the only sane solution is to forbid it. End of story. >>> >>> Thanks, >>> >>> tglx >>> >> Hi Jacob, >> >> Like Thomas pointed out, we can design a sane solution for powerclamp. >> Idle injection is nothing but throttling of runqueue. If the runqueue >> is throttled, no fair tasks will be selected and the natural choice >> in the absence of tasks from any other sched class is the idle task. >> >> The idle loop will automatically be called and the nohz state will >> also fall in place. The cpu is really idle now: the runqueue has no >> tasks and the task running on the cpu is the idle thread. The >> throttled tasks are on a separate list. >> >> When the period of idle injection is over, we unthrottle the runqueue. >> All this being taken care of my a non-deferrable timer. This design >> ensures that the intention of powerclamp is not hampered while at the >> same time maintaining a sane state for nohz; you will get the >> efficiency you want. >> >> Of course there may be corner cases and challenges around >> synchronization of package idle, which I am sure we can work around >> with a better design such as the above. I am working on that patchset >> and will post out in a day. You can take a look and let us know the >> pieces we are missing. >> >> I find that implementing the above design is not too hard. >> > Hi Preeti, > Yeah, it seems to be a good approach. looking forward to work with you > on this. Timer may scale better for larger systems. One question, will > timer irq gets unpredictable delays if run by ksoftirqd? I am sorry I could not respond earlier; I was on vacation as well. Yes, we may have a problem here. Let alone synchronization between cpus in performing clamping, there are two other functionality issues that I see. 1. Since periodic timers get executed in the softirq context, scheduler_tick() would have passed by by then. i.e. hrtimer_interrupt() |__tick_sched_handle() |__scheduler_tick() |__raise_softirq(TIMER_SOFTIRQ) ksoftirqd runs on local_bh_enable()-->powerclamp_timer handler runs Although runqueues are throttled in the powerclamp timer handler, it has to wait till the next scheduler tick to select an idle task to run. A precious 4-10ms depending on the config would have passed by then. 2. For the same reason as 1, when the ksoftirqd has to run on the cpus during the tick after the one in which throttling is enabled, cpus are unavailable to run the daemon because they are throttled. However there is no other way to unthrottle the runqueues now except by running the ksoftirqd; a chicken and egg problem. I think both the above problems could be solved by using hrtimers instead of periodic timers to perform clamping/unclamping, since hrtimers are serviced in the interrupt context. But we cannot initialize/start/modify hrtimers on a remote cpu. We will end up using IPIs for handling the hrtimers during start/end of powerclamp or modification of the idle duration of clamping, which is not a tempting option either. So I am currently stuck at this point. I would be glad to have some suggestions. Thanks Regards Preeti U Murthy > BTW, I may not be able to respond quickly during the holidays. If > things workout, it may benefit ACPI PAD driver as well. > > > Thanks, > > Jacob >> Regards >> Preeti U Murthy >> > > [Jacob Pan] > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] perf list: Fix --raw-dump option
Hi Taesoo,
On Tue, Dec 30, 2014 at 10:36:55PM -0500, Taesoo Kim wrote:
> Currently, 'perf list --raw-dump' requires extra arguments
> (e.g., hw) to invoke, which breaks bash/zsh completion
> (perf-completion.sh).
>
> $ perf list --raw-dump
> Error: unknown option `raw-dump'
>
> usage: perf list [hw|sw|cache|tracepoint|pmu|event_glob]
>
> After,
>
> $ perf list --raw-dump
> cpu-cycles instructions cache-references cache-misses ...
>
> Signed-off-by: Taesoo Kim
Acked-by: Namhyung Kim
Thanks,
Namhyung
> ---
> tools/perf/builtin-list.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
> index 011195e..198f3c3 100644
> --- a/tools/perf/builtin-list.c
> +++ b/tools/perf/builtin-list.c
> @@ -19,7 +19,9 @@
> int cmd_list(int argc, const char **argv, const char *prefix __maybe_unused)
> {
> int i;
> - const struct option list_options[] = {
> + bool raw_dump = false;
> + struct option list_options[] = {
> + OPT_BOOLEAN(0, "raw-dump", _dump, "Dump raw events"),
> OPT_END()
> };
> const char * const list_usage[] = {
> @@ -27,11 +29,18 @@ int cmd_list(int argc, const char **argv, const char
> *prefix __maybe_unused)
> NULL
> };
>
> + set_option_flag(list_options, 0, "raw-dump", PARSE_OPT_HIDDEN);
> +
> argc = parse_options(argc, argv, list_options, list_usage,
>PARSE_OPT_STOP_AT_NON_OPTION);
>
> setup_pager();
>
> + if (raw_dump) {
> + print_events(NULL, true);
> + return 0;
> + }
> +
> if (argc == 0) {
> print_events(NULL, false);
> return 0;
> @@ -53,8 +62,6 @@ int cmd_list(int argc, const char **argv, const char
> *prefix __maybe_unused)
> print_hwcache_events(NULL, false);
> else if (strcmp(argv[i], "pmu") == 0)
> print_pmu_events(NULL, false);
> - else if (strcmp(argv[i], "--raw-dump") == 0)
> - print_events(NULL, true);
> else {
> char *sep = strchr(argv[i], ':'), *s;
> int sep_idx;
> --
> 2.2.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] video / backlight: add two APIs for drivers to use
It is useful to get the backlight device's pointer and use it to set
backlight in some cases(the following patch will make use of it) so add
the two APIs and export them.
Signed-off-by: Aaron Lu
---
drivers/video/backlight/backlight.c | 44 -
include/linux/backlight.h | 2 ++
2 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index bddc8b17a4d8..bea749329236 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -164,28 +164,19 @@ static ssize_t brightness_show(struct device *dev,
return sprintf(buf, "%d\n", bd->props.brightness);
}
-static ssize_t brightness_store(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t count)
+int backlight_device_set_brightness(struct backlight_device *bd, int
brightness)
{
- int rc;
- struct backlight_device *bd = to_backlight_device(dev);
- unsigned long brightness;
-
- rc = kstrtoul(buf, 0, );
- if (rc)
- return rc;
-
- rc = -ENXIO;
+ int rc = -ENXIO;
mutex_lock(>ops_lock);
if (bd->ops) {
if (brightness > bd->props.max_brightness)
rc = -EINVAL;
else {
- pr_debug("set brightness to %lu\n", brightness);
+ pr_debug("set brightness to %u\n", brightness);
bd->props.brightness = brightness;
backlight_update_status(bd);
- rc = count;
+ rc = 0;
}
}
mutex_unlock(>ops_lock);
@@ -194,6 +185,23 @@ static ssize_t brightness_store(struct device *dev,
return rc;
}
+EXPORT_SYMBOL(backlight_device_set_brightness);
+
+static ssize_t brightness_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ int rc;
+ struct backlight_device *bd = to_backlight_device(dev);
+ unsigned long brightness;
+
+ rc = kstrtoul(buf, 0, );
+ if (rc)
+ return rc;
+
+ rc = backlight_device_set_brightness(bd, brightness);
+
+ return rc ? rc : count;
+}
static DEVICE_ATTR_RW(brightness);
static ssize_t type_show(struct device *dev, struct device_attribute *attr,
@@ -380,7 +388,7 @@ struct backlight_device *backlight_device_register(const
char *name,
}
EXPORT_SYMBOL(backlight_device_register);
-bool backlight_device_registered(enum backlight_type type)
+struct backlight_device *backlight_device_get_by_type(enum backlight_type type)
{
bool found = false;
struct backlight_device *bd;
@@ -394,7 +402,13 @@ bool backlight_device_registered(enum backlight_type type)
}
mutex_unlock(_dev_list_mutex);
- return found;
+ return found ? bd : NULL;
+}
+EXPORT_SYMBOL(backlight_device_get_by_type);
+
+bool backlight_device_registered(enum backlight_type type)
+{
+ return backlight_device_get_by_type(type) ? true : false;
}
EXPORT_SYMBOL(backlight_device_registered);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index adb14a8616df..c59a020df3f8 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -140,6 +140,8 @@ extern void backlight_force_update(struct backlight_device
*bd,
extern bool backlight_device_registered(enum backlight_type type);
extern int backlight_register_notifier(struct notifier_block *nb);
extern int backlight_unregister_notifier(struct notifier_block *nb);
+extern struct backlight_device *backlight_device_get_by_type(enum
backlight_type type);
+extern int backlight_device_set_brightness(struct backlight_device *bd, int
brightness);
#define to_backlight_device(obj) container_of(obj, struct backlight_device,
dev)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] video / backlight: remove the backlight_device_registered API
Since we will need the backlight_device_get_by_type API, we can use it
instead of the backlight_device_registered API whenever necessary so
remove the backlight_device_registered API.
Signed-off-by: Aaron Lu
---
drivers/acpi/video.c| 2 +-
drivers/video/backlight/backlight.c | 6 --
include/linux/backlight.h | 1 -
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 1eaadff2e198..98d3f0de811e 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -246,7 +246,7 @@ static bool acpi_video_use_native_backlight(void)
bool acpi_video_verify_backlight_support(void)
{
if (acpi_osi_is_win8() && acpi_video_use_native_backlight() &&
- backlight_device_registered(BACKLIGHT_RAW))
+ backlight_device_get_by_type(BACKLIGHT_RAW))
return false;
return acpi_video_backlight_support();
}
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index bea749329236..aec173d9e1ee 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -406,12 +406,6 @@ struct backlight_device *backlight_device_get_by_type(enum
backlight_type type)
}
EXPORT_SYMBOL(backlight_device_get_by_type);
-bool backlight_device_registered(enum backlight_type type)
-{
- return backlight_device_get_by_type(type) ? true : false;
-}
-EXPORT_SYMBOL(backlight_device_registered);
-
/**
* backlight_device_unregister - unregisters a backlight device object.
* @bd: the backlight device object to be unregistered and freed.
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index c59a020df3f8..287a4460054c 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -137,7 +137,6 @@ extern void devm_backlight_device_unregister(struct device
*dev,
struct backlight_device *bd);
extern void backlight_force_update(struct backlight_device *bd,
enum backlight_update_reason reason);
-extern bool backlight_device_registered(enum backlight_type type);
extern int backlight_register_notifier(struct notifier_block *nb);
extern int backlight_unregister_notifier(struct notifier_block *nb);
extern struct backlight_device *backlight_device_get_by_type(enum
backlight_type type);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Support INT3406 Display thermal device
The display thermal device represents the LED/LCD display panel that may or may not include touch support. The main function of the display thermal device is to allow control of the display brightness in order to address a thermal condition or to reduce power consumed by display device. Due to the way this thermal device changes brightness level is said to be deprecated so we are using the raw interface to do the actual backlight change. This requires the backlight core support so two new APIs are added and exported in patch 1/3. With this, the previous API backlight_device_registered can be removed and this is done in patch 2/3. Patch 3/3 adds the new int3406 thermal driver. Happy new year and best wishes! Aaron Lu (3): video / backlight: add two APIs for drivers to use video / backlight: remove the backlight_device_registered API Thermal: introduce INT3406 thermal driver drivers/acpi/video.c | 79 drivers/thermal/Kconfig | 26 +-- drivers/thermal/int340x_thermal/Kconfig | 41 drivers/thermal/int340x_thermal/Makefile | 1 + drivers/thermal/int340x_thermal/int3406_thermal.c | 229 ++ drivers/video/backlight/backlight.c | 40 ++-- include/acpi/video.h | 20 ++ include/linux/backlight.h | 3 +- 8 files changed, 362 insertions(+), 77 deletions(-) create mode 100644 drivers/thermal/int340x_thermal/Kconfig create mode 100644 drivers/thermal/int340x_thermal/int3406_thermal.c -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] Thermal: introduce INT3406 thermal driver
INT3406 ACPI device object resembles an ACPI video output device, but its
_BCM is said to be deprecated and should not be used. So we will make
use of the raw interface to do the actual cooling. Due to this, the APIs
from backlight core are used to achieve this. Also, to re-use some of the
ACPI video module's code, one function has been exported.
Signed-off-by: Aaron Lu
---
drivers/acpi/video.c | 77
drivers/thermal/Kconfig | 26 +--
drivers/thermal/int340x_thermal/Kconfig | 41
drivers/thermal/int340x_thermal/Makefile | 1 +
drivers/thermal/int340x_thermal/int3406_thermal.c | 229 ++
include/acpi/video.h | 20 ++
6 files changed, 335 insertions(+), 59 deletions(-)
create mode 100644 drivers/thermal/int340x_thermal/Kconfig
create mode 100644 drivers/thermal/int340x_thermal/int3406_thermal.c
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 98d3f0de811e..8229a3e0e372 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -187,19 +187,6 @@ struct acpi_video_device_cap {
u8 _DDC:1; /* Return the EDID for this device */
};
-struct acpi_video_brightness_flags {
- u8 _BCL_no_ac_battery_levels:1; /* no AC/Battery levels in _BCL */
- u8 _BCL_reversed:1; /* _BCL package is in a reversed order
*/
- u8 _BQC_use_index:1;/* _BQC returns an index value */
-};
-
-struct acpi_video_device_brightness {
- int curr;
- int count;
- int *levels;
- struct acpi_video_brightness_flags flags;
-};
-
struct acpi_video_device {
unsigned long device_id;
struct acpi_video_device_flags flags;
@@ -345,7 +332,7 @@ static const struct thermal_cooling_device_ops
video_cooling_ops = {
*/
static int
-acpi_video_device_lcd_query_levels(struct acpi_video_device *device,
+acpi_video_device_lcd_query_levels(acpi_handle handle,
union acpi_object **levels)
{
int status;
@@ -355,7 +342,7 @@ acpi_video_device_lcd_query_levels(struct acpi_video_device
*device,
*levels = NULL;
- status = acpi_evaluate_object(device->dev->handle, "_BCL", NULL,
);
+ status = acpi_evaluate_object(handle, "_BCL", NULL, );
if (!ACPI_SUCCESS(status))
return status;
obj = (union acpi_object *)buffer.pointer;
@@ -728,29 +715,18 @@ static int acpi_video_bqc_quirk(struct acpi_video_device
*device,
return 0;
}
-
-/*
- * Arg:
- * device : video output device (LCD, CRT, ..)
- *
- * Return Value:
- * Maximum brightness level
- *
- * Allocate and initialize device->brightness.
- */
-
-static int
-acpi_video_init_brightness(struct acpi_video_device *device)
+int acpi_video_get_levels(struct acpi_device *device,
+ struct acpi_video_device_brightness **dev_br)
{
union acpi_object *obj = NULL;
int i, max_level = 0, count = 0, level_ac_battery = 0;
- unsigned long long level, level_old;
union acpi_object *o;
struct acpi_video_device_brightness *br = NULL;
int result = -EINVAL;
u32 value;
- if (!ACPI_SUCCESS(acpi_video_device_lcd_query_levels(device, ))) {
+ if (!ACPI_SUCCESS(acpi_video_device_lcd_query_levels(device->handle,
+ ))) {
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Could not query available "
"LCD brightness level\n"));
goto out;
@@ -823,6 +799,39 @@ acpi_video_init_brightness(struct acpi_video_device
*device)
"Found unordered _BCL package"));
br->count = count;
+ *dev_br = br;
+ result = 0;
+
+out:
+ kfree(obj);
+ return result;
+out_free:
+ kfree(br);
+ goto out;
+}
+EXPORT_SYMBOL(acpi_video_get_levels);
+
+/*
+ * Arg:
+ * device : video output device (LCD, CRT, ..)
+ *
+ * Return Value:
+ * Maximum brightness level
+ *
+ * Allocate and initialize device->brightness.
+ */
+
+static int
+acpi_video_init_brightness(struct acpi_video_device *device)
+{
+ int i, max_level = 0;
+ unsigned long long level, level_old;
+ struct acpi_video_device_brightness *br = NULL;
+ int result = -EINVAL;
+
+ result = acpi_video_get_levels(device->dev, );
+ if (result)
+ return result;
device->brightness = br;
/* _BQC uses INDEX while _BCL uses VALUE in some laptops */
@@ -865,17 +874,13 @@ set_level:
goto out_free_levels;
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "found %d brightness levels\n", count - 2));
- kfree(obj);
- return result;
+ "found %d brightness levels\n", br->count - 2));
+ return 0;
out_free_levels:
[alsa-devel][PATCH 1/4] ASoC: wm8960: Let wm8960 codec driver manage its own MCLK
When we want to use wm8960 codec, we should enable its MCLK in machine driver.
It's reasonable for wm8960 codec driver to manage its own MCLK.
When current bias_level is SND_SOC_BIAS_ON, it is preparing for a transition
away from ON. In this case, disable the codec mclk. When current bias_level
is not SND_SOC_BIAS_ON, it preparing for a transition to ON. In this case,
enable the codec mclk.
Signed-off-by: Zidan Wang
---
sound/soc/codecs/wm8960.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c
index 031a1ae..1a5f47b 100644
--- a/sound/soc/codecs/wm8960.c
+++ b/sound/soc/codecs/wm8960.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -117,6 +118,7 @@ static bool wm8960_volatile(struct device *dev, unsigned
int reg)
}
struct wm8960_priv {
+ struct clk *mclk;
struct regmap *regmap;
int (*set_bias_level)(struct snd_soc_codec *,
enum snd_soc_bias_level level);
@@ -618,6 +620,7 @@ static int wm8960_set_bias_level_out3(struct snd_soc_codec
*codec,
enum snd_soc_bias_level level)
{
struct wm8960_priv *wm8960 = snd_soc_codec_get_drvdata(codec);
+ int ret;
switch (level) {
case SND_SOC_BIAS_ON:
@@ -626,6 +629,20 @@ static int wm8960_set_bias_level_out3(struct snd_soc_codec
*codec,
case SND_SOC_BIAS_PREPARE:
/* Set VMID to 2x50k */
snd_soc_update_bits(codec, WM8960_POWER1, 0x180, 0x80);
+
+ if (!IS_ERR(wm8960->mclk)) {
+ if (codec->dapm.bias_level == SND_SOC_BIAS_ON)
+ clk_disable_unprepare(wm8960->mclk);
+ else {
+ ret = clk_prepare_enable(wm8960->mclk);
+ if (ret) {
+ dev_err(codec->dev,
+ "Failed to enable MCLK: %d\n",
+ ret);
+ return ret;
+ }
+ }
+ }
break;
case SND_SOC_BIAS_STANDBY:
@@ -661,6 +678,7 @@ static int wm8960_set_bias_level_out3(struct snd_soc_codec
*codec,
/* Disable VMID and VREF, let them discharge */
snd_soc_write(codec, WM8960_POWER1, 0);
+
msleep(600);
break;
}
@@ -674,7 +692,7 @@ static int wm8960_set_bias_level_capless(struct
snd_soc_codec *codec,
enum snd_soc_bias_level level)
{
struct wm8960_priv *wm8960 = snd_soc_codec_get_drvdata(codec);
- int reg;
+ int reg, ret;
switch (level) {
case SND_SOC_BIAS_ON:
@@ -715,9 +733,22 @@ static int wm8960_set_bias_level_capless(struct
snd_soc_codec *codec,
WM8960_VREF, WM8960_VREF);
msleep(100);
+
+ if (!IS_ERR(wm8960->mclk)) {
+ ret = clk_prepare_enable(wm8960->mclk);
+ if (ret) {
+ dev_err(codec->dev,
+ "Failed to enable MCLK: %d\n",
+ ret);
+ return ret;
+ }
+ }
break;
case SND_SOC_BIAS_ON:
+ if (!IS_ERR(wm8960->mclk))
+ clk_disable_unprepare(wm8960->mclk);
+
/* Enable anti-pop mode */
snd_soc_update_bits(codec, WM8960_APOP1,
WM8960_POBCTRL | WM8960_SOFT_ST |
@@ -728,6 +759,7 @@ static int wm8960_set_bias_level_capless(struct
snd_soc_codec *codec,
/* Disable VMID and VREF */
snd_soc_update_bits(codec, WM8960_POWER1,
WM8960_VREF | WM8960_VMID_MASK, 0);
+
break;
case SND_SOC_BIAS_OFF:
@@ -1002,6 +1034,12 @@ static int wm8960_i2c_probe(struct i2c_client *i2c,
if (wm8960 == NULL)
return -ENOMEM;
+ wm8960->mclk = devm_clk_get(>dev, "codec_mclk");
+ if (IS_ERR(wm8960->mclk)) {
+ if (PTR_ERR(wm8960->mclk) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ }
+
wm8960->regmap = devm_regmap_init_i2c(i2c, _regmap);
if (IS_ERR(wm8960->regmap))
return PTR_ERR(wm8960->regmap);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[alsa-devel][PATCH 3/4] ASoC: wm8960: use pr_debug instead of pr_err
In machine driver, we should find a appropriate sysclk for codec driver,
and will use codec set_dai_pll to judge if pll can generate such sysclk.
When sample rate changed, we should look for a useful bclk, lrclk division
ratio, and will try set_dai_pll for several times. So use pr_debug so that
don't generate much error logs.
Signed-off-by: Zidan Wang
---
sound/soc/codecs/wm8960.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c
index 86a5489..cb42385 100644
--- a/sound/soc/codecs/wm8960.c
+++ b/sound/soc/codecs/wm8960.c
@@ -914,7 +914,7 @@ static int pll_factors(unsigned int source, unsigned int
target,
pll_div->pre_div = 0;
if ((Ndiv < 6) || (Ndiv > 12)) {
- pr_err("WM8960 PLL: Unsupported N=%d\n", Ndiv);
+ pr_debug("WM8960 PLL: Unsupported N=%d\n", Ndiv);
return -EINVAL;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[alsa-devel][PATCH 4/4] ASoC: wm8960: Fix capture sample rate from 11250 to 11025
wm8960 codec can't support sample rate 11250, it must be 11025.
Signed-off-by: Zidan Wang
---
sound/soc/codecs/wm8960.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c
index cb42385..68790f1 100644
--- a/sound/soc/codecs/wm8960.c
+++ b/sound/soc/codecs/wm8960.c
@@ -560,7 +560,7 @@ static struct {
{ 22050, 2 },
{ 24000, 2 },
{ 16000, 3 },
- { 11250, 4 },
+ { 11025, 4 },
{ 12000, 4 },
{ 8000, 5 },
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[alsa-devel][PATCH 2/4] ASoC: wm8960: Let wm8960 driver configure its bit clock and frame clock
wm8960 codec driver missing configure its bit clock and frame clock, so add
support for it. It will calculate a appropriate frequency dividing ratio
according to the system clock, bit clock and frame clock, then set the
corresponding registers.
Signed-off-by: Zidan Wang
---
sound/soc/codecs/wm8960.c | 108 ++
1 file changed, 108 insertions(+)
diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c
index 1a5f47b..86a5489 100644
--- a/sound/soc/codecs/wm8960.c
+++ b/sound/soc/codecs/wm8960.c
@@ -127,6 +127,8 @@ struct wm8960_priv {
struct snd_soc_dapm_widget *out3;
bool deemph;
int playback_fs;
+ int bclk;
+ int sysclk;
struct wm8960_data pdata;
};
@@ -563,6 +565,79 @@ static struct {
{ 8000, 5 },
};
+/* Multiply 256 for internal 256 div */
+static const int dac_divs[] = { 256, 384, 512, 768, 1024, 1408, 1536 };
+
+/* Multiply 10 to eliminate decimials */
+static const int bclk_divs[] = {
+ 10, 15, 20, 30, 40, 55, 60, 80, 110,
+ 120, 160, 220, 240, 320, 320, 320
+};
+
+static void wm8960_configure_clocking(struct snd_soc_codec *codec,
+ int stream, int lrclk)
+{
+ struct wm8960_priv *wm8960 = snd_soc_codec_get_drvdata(codec);
+ u16 iface1 = snd_soc_read(codec, WM8960_IFACE1);
+ u16 iface2 = snd_soc_read(codec, WM8960_IFACE2);
+ int i, j;
+
+ if (!(iface1 & (1<<6))) {
+ dev_dbg(codec->dev,
+ "Codec is slave mode, no need to configure clock\n");
+ return;
+ }
+
+ if (!wm8960->sysclk) {
+ dev_dbg(codec->dev, "No SYSCLK configured\n");
+ return;
+ }
+
+ if (!wm8960->bclk || !lrclk) {
+ dev_dbg(codec->dev, "No audio clocks configured\n");
+ return;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(dac_divs); ++i) {
+ if (wm8960->sysclk == lrclk * dac_divs[i]) {
+ for (j = 0; j < ARRAY_SIZE(bclk_divs); ++j) {
+ if (wm8960->sysclk == wm8960->bclk *
+ bclk_divs[j] / 10) {
+ /* configure frame clock */
+ if (iface2 & (1<<6))
+ /* If ADCLRC configure as GPIO
+* pin, DACLRC pin is used as
+* a frame clock for ADCs and
+* DACs */
+ snd_soc_update_bits(codec,
+ WM8960_CLOCK1,
+ 0x7 << 3,
+ i << 3);
+ else if (SNDRV_PCM_STREAM_PLAYBACK
+ == stream)
+ snd_soc_update_bits(codec,
+ WM8960_CLOCK1,
+ 0x7 << 3,
+ i << 3);
+ else if (SNDRV_PCM_STREAM_CAPTURE
+ == stream)
+ snd_soc_update_bits(codec,
+ WM8960_CLOCK1,
+ 0x7 << 6,
+ i << 6);
+
+ /* configure bit clock */
+ snd_soc_update_bits(codec,
+ WM8960_CLOCK2, 0xf, j);
+ return;
+ }
+ }
+ }
+ }
+
+ dev_err(codec->dev, "Unsupported sysclk %d\n", wm8960->sysclk);
+}
+
static int wm8960_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
@@ -572,6 +647,10 @@ static int wm8960_hw_params(struct snd_pcm_substream
*substream,
u16 iface = snd_soc_read(codec, WM8960_IFACE1) & 0xfff3;
int i;
+ wm8960->bclk = snd_soc_params_to_bclk(params);
+ if (params_channels(params) == 1)
+ wm8960->bclk *= 2;
+
/* bit size */
switch (params_width(params)) {
case 16:
@@ -602,6 +681,10 @@ static int wm8960_hw_params(struct snd_pcm_substream
*substream,
/* set iface */
snd_soc_write(codec, WM8960_IFACE1, iface);
+
+
Crypto Fixes for 3.19
Hi Linus: This push fixes a use-after-free crash in the user-space crypto API. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git or master.kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6.git Rabin Vincent (1): crypto: af_alg - fix backlog handling crypto/af_alg.c |3 +++ 1 file changed, 3 insertions(+) Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] perf list: Fix --raw-dump option
Currently, 'perf list --raw-dump' requires extra arguments
(e.g., hw) to invoke, which breaks bash/zsh completion
(perf-completion.sh).
$ perf list --raw-dump
Error: unknown option `raw-dump'
usage: perf list [hw|sw|cache|tracepoint|pmu|event_glob]
After,
$ perf list --raw-dump
cpu-cycles instructions cache-references cache-misses ...
Signed-off-by: Taesoo Kim
---
tools/perf/builtin-list.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 011195e..198f3c3 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -19,7 +19,9 @@
int cmd_list(int argc, const char **argv, const char *prefix __maybe_unused)
{
int i;
- const struct option list_options[] = {
+ bool raw_dump = false;
+ struct option list_options[] = {
+ OPT_BOOLEAN(0, "raw-dump", _dump, "Dump raw events"),
OPT_END()
};
const char * const list_usage[] = {
@@ -27,11 +29,18 @@ int cmd_list(int argc, const char **argv, const char
*prefix __maybe_unused)
NULL
};
+ set_option_flag(list_options, 0, "raw-dump", PARSE_OPT_HIDDEN);
+
argc = parse_options(argc, argv, list_options, list_usage,
PARSE_OPT_STOP_AT_NON_OPTION);
setup_pager();
+ if (raw_dump) {
+ print_events(NULL, true);
+ return 0;
+ }
+
if (argc == 0) {
print_events(NULL, false);
return 0;
@@ -53,8 +62,6 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
print_hwcache_events(NULL, false);
else if (strcmp(argv[i], "pmu") == 0)
print_pmu_events(NULL, false);
- else if (strcmp(argv[i], "--raw-dump") == 0)
- print_events(NULL, true);
else {
char *sep = strchr(argv[i], ':'), *s;
int sep_idx;
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ARM: dts: sun9i: Allwinner A80 dtsi - missing clock-frequency property
On Wed, Dec 31, 2014 at 8:37 AM, Heinrich Schuchardt wrote: > When booting Linux 3.19-rc2 on a Merrii Optimusboard using > arch/arm/boot/dts/sun9i-a80-optimus.dts adn arch/arm/boot/dts/sun9i-a80.dtsi > I get errors > [0.061192] /cpus/cpu@0 missing clock-frequency property > [0.061209] /cpus/cpu@1 missing clock-frequency property > [0.061223] /cpus/cpu@2 missing clock-frequency property > [0.061237] /cpus/cpu@3 missing clock-frequency property > [0.061251] /cpus/cpu@100 missing clock-frequency property > [0.061266] /cpus/cpu@101 missing clock-frequency property > [0.061283] /cpus/cpu@102 missing clock-frequency property > [0.061300] /cpus/cpu@103 missing clock-frequency property The clock-frequency property is in no way connected to clocks or cpufreq on Linux. It is solely used to generate a topology map for multi-cluster systems. Personally I prefer the cpu-topology bindings on arm64, but this is what we have. > The dtsi was provided by patch > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4ab328f06e305bf3ea254f4e3c94bb4d820998c1 > > According to file pack/chips/sun9iw1p1/optimus/sys_config.fex supplied in > the OptimusBoard SDK the big cluster can run at up to 1800 MHz, and > the LITTLE cluster can run at up to 1200 MHz,depending on the CPU voltage: > > big > 1.08V (1608Mhz, 1800Mhz] > 1.00V (1536Mhz, 1608Mhz] > 0.96V (1440Mhz, 1536Mhz] > 0.90V (1296Mhz, 1440Mhz] > 0.84V ( 0Mhz, 1296Mhz] > > LITTLE > 1.02V (1128Mhz, 1200Mhz] > 0.96V (1008Mhz, 1128Mhz] > 0.90V ( 864Mhz, 1008Mhz] > 0.84V ( 0Mhz, 864Mhz] > > I guess the proper way to specify the data is the one described in > Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt cpufreq requires a bit more than just specifying the operating points. Moreover, SMP is not supported on sun9i yet. For DVFS we also need support for the PMICs. > Other boards might run at other frequencies. Hence we might want to put this > information into the board file > arch/arm/boot/dts/sun9i-a80-optimus.dts. We can also give a default set of OPP in the dtsi, and any boards having special voltage requirements can override them or use the voltage-derivation property (not sure that's the name). > Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt, > arch/arm/boot/dts/exynos5260.dtsi, and > arch/arm/boot/dts/exynos5420.dtsi, all assume that > cpu@0-cpu@3 are A15 (big) and cpu@101-cpu@103 are A7 (LITTLE). > > Shouldn't arch/arm/boot/dts/sun9i-a80.dtsi stick to this convention? This is not some convention. The values match what the hardware says in the MPIDR. ChenYu > The scripts to create the uImage and to reproduce the problem are in > https://github.com/xypron/kernel-optimusboard/tree/35d06c020f6584b5023e0e4bef67cc5a625f65bb > > Best regards > > Heinrich Schuchardt > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: lustre: linux-prim.c: fix sparse warnings about static declaration
On Tue, Dec 30, 2014 at 02:35:18PM -0800, Jeremiah Mahler wrote: > > If you look at the source code just below these functions you will find: > > EXPORT_SYMBOL(libcfs_arch_init); > EXPORT_SYMBOL(libcfs_arch_cleanup); > > So making these static is incorrect because they are being used outside > of this file. > Thanks for the review, and sorry about the noise; I'll be more careful next time. Serguey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nios2: Use preempt_schedule_irq
On Tue, Dec 30, 2014 at 10:02 PM, Tobias Klauser wrote:
> Follow aa0d53260596 ("ia64: Use preempt_schedule_irq") and use
> preempt_schedule_irq instead of enabling/disabling interrupts and messing
> around
> with PREEMPT_ACTIVE in the nios2 low-level preemption code ourselves. Also get
> rid of the now needless re-check for TIF_NEED_RESCHED, preempt_schedule_irq
> will already take care of rescheduling.
>
> This also fixes the following build error when building with CONFIG_PREEMPT:
>
> arch/nios2/kernel/built-in.o: In function `need_resched':
> arch/nios2/kernel/entry.S:374: undefined reference to `PREEMPT_ACTIVE'
>
> Cc: Thomas Gleixner
> Signed-off-by: Tobias Klauser
> ---
Acked-by: Ley Foon Tan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mm: cma: /proc/cmainfo
2014-12-31 오전 11:18에 Minchan Kim 이(가) 쓴 글: Hey, Gioh On Wed, Dec 31, 2014 at 09:58:04AM +0900, Gioh Kim wrote: 2014-12-30 오후 1:47에 Minchan Kim 이(가) 쓴 글: On Mon, Dec 29, 2014 at 11:52:58AM -0800, Laura Abbott wrote: On 12/28/2014 6:36 PM, Minchan Kim wrote: Hello, On Fri, Dec 26, 2014 at 05:39:01PM +0300, Stefan I. Strogin wrote: Hello all, Here is a patch set that adds /proc/cmainfo. When compiled with CONFIG_CMA_DEBUG /proc/cmainfo will contain information about about total, used, maximum free contiguous chunk and all currently allocated contiguous buffers in CMA regions. The information about allocated CMA buffers includes pid, comm, allocation latency and stacktrace at the moment of allocation. It just says what you are doing but you didn't say why we need it. I can guess but clear description(ie, the problem what you want to solve with this patchset) would help others to review, for instance, why we need latency, why we need callstack, why we need new wheel rather than ftrace and so on. Thanks. I've been meaning to write something like this for a while so I'm happy to see an attempt made to fix this. I can't speak for the author's reasons for wanting this information but there are several reasons why I was thinking of something similar. The most common bug reports seen internally on CMA are 1) CMA is too slow and 2) CMA failed to allocate memory. For #1, not all allocations may be slow so it's useful to be able to keep track of which allocations are taking too long. For #2, migration Then, I don't think we could keep all of allocations. What we need is only slow allocations. I hope we can do that with ftrace. ex) # cd /sys/kernel/debug/tracing # echo 1 > options/stacktrace # echo cam_alloc > set_ftrace_filter # echo your_threshold > tracing_thresh I know it doesn't work now but I think it's more flexible and general way to handle such issues(ie, latency of some functions). So, I hope we could enhance ftrace rather than new wheel. Ccing ftrace people. For CMA performance test or code flow check, ftrace is better. ex) echo cma_alloc > /sys/kernel/debug/tracing/set_graph_function echo function_graph > /sys/kernel/debug/tracing/current_tracer echo funcgraph-proc > /sys/kernel/debug/tracing/trace_options echo nosleep-time > /sys/kernel/debug/tracing/trace_options echo funcgraph-tail > /sys/kernel/debug/tracing/trace_options echo 1 > /sys/kernel/debug/tracing/tracing_on I didn't know such detail. Thanks for the tip, Gioh. This can trace every cam_alloc and allocation time. I think ftrace is better to debug latency. If a buffer had allocated and had peak latency and freed, we can check it. Agree. But ftrace doesn't provide current status how many buffers we have and what address it is. So I think debugging information is useful. I didn't say debug information is useless. If we need to know snapshot of cma at the moment, describe why we need it and send a patch to implement the idea rather than dumping lots of information is always better. Yes, you're right. I mean this patch is useful to me. I sometimes need to check each drivers has buffers that are correctly located and aligned. Futhermore, if we really need to have such information, we need more data (ex, how many of pages were migrated out, how many pages were dropped without migrated, how many pages were written back, how many pages were retried with the page lock and so on). In this case, event trace would be better. failure is fairly common but it's still important to rule out a memory leak from a dma client. Seeing all the allocations is also very useful for memory tuning (e.g. how big does the CMA region need to be, which clients are actually allocating memory). Memory leak is really general problem and could we handle it with page_owner? ftrace is certainly usable for tracing CMA allocation callers and latency. ftrace is still only a fixed size buffer though so it's possible for information to be lost if other logging is enabled. Sorry, I don't get with only above reasons why we need this. :( For most of the CMA use cases, there is a very high cost if the proper debugging information is not available so the more that can be guaranteed the better. It's also worth noting that the SLUB allocator has a sysfs interface for showing allocation callers when CONFIG_SLUB_DEBUG is enabled. Thanks, Laura -- Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- To unsubscribe
Re: [PATCH v3 2/2] regulator: rk808: add dvs support
On 12/31/2014 01:04 AM, Mark Brown wrote: On Tue, Dec 30, 2014 at 11:07:14AM +0800, Chris Zhong wrote: On 12/30/2014 01:25 AM, Mark Brown wrote: So, this seems a bit odd. What we appear to be doing here is alternating between the two different voltage setting registers which is all well and good but makes me wonder why we're bothering - it's a bit more work than just sticking with one. We do get... you mean check the old_selector and selector? I think _regulator_do_set_voltage have done it. No, I mean that we may as well just always write to the same register and save a bunch of code. No, when we pull down DVSn pin, the voltage value is from RK808_BUCK1_ON_VSEL_REG, and when we pull up DVSn pin, the voltage value if from RK808_BUCK1_ON_VSEL_REG+2. We want to this dvs function for a better voltage wave, avoid overshoot, if someone do not need this function, they could remove the setting of DVSn pin in dts file, and at that time, rk808_regulator will use a same register for setting voltage. ...this but unless the voltage typically ramps much faster than spec it's never clear to me that we're actually winning by polling the pin instead of just dead reckoning the time, it's more work for the CPU to poll the GPIO than to sleep after all. Actually, it's slower than spec, so I think getting this dvsok pin state is safer than delay. Well, that suggests that the spec is wrong which ought to be fixed anyway oughtn't it? Or are you saying that the delay is inconsistent as well as slower than advertised? the spec said 2/4/6/10 mv/us, but the ramp will change depending on the load. So I think the dvsok pin is more accurate, since it It will soon change, once the regulator is completed. the delay is a fixed time. it is faster than dvsok pin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mm: cma: /proc/cmainfo
Hey, Gioh On Wed, Dec 31, 2014 at 09:58:04AM +0900, Gioh Kim wrote: > > > 2014-12-30 오후 1:47에 Minchan Kim 이(가) 쓴 글: > >On Mon, Dec 29, 2014 at 11:52:58AM -0800, Laura Abbott wrote: > >>On 12/28/2014 6:36 PM, Minchan Kim wrote: > >>>Hello, > >>> > >>>On Fri, Dec 26, 2014 at 05:39:01PM +0300, Stefan I. Strogin wrote: > Hello all, > > Here is a patch set that adds /proc/cmainfo. > > When compiled with CONFIG_CMA_DEBUG /proc/cmainfo will contain information > about about total, used, maximum free contiguous chunk and all currently > allocated contiguous buffers in CMA regions. The information about > allocated > CMA buffers includes pid, comm, allocation latency and stacktrace at the > moment of allocation. > >>> > >>>It just says what you are doing but you didn't say why we need it. > >>>I can guess but clear description(ie, the problem what you want to > >>>solve with this patchset) would help others to review, for instance, > >>>why we need latency, why we need callstack, why we need new wheel > >>>rather than ftrace and so on. > >>> > >>>Thanks. > >>> > >> > >> > >>I've been meaning to write something like this for a while so I'm > >>happy to see an attempt made to fix this. I can't speak for the > >>author's reasons for wanting this information but there are > >>several reasons why I was thinking of something similar. > >> > >>The most common bug reports seen internally on CMA are 1) CMA is > >>too slow and 2) CMA failed to allocate memory. For #1, not all > >>allocations may be slow so it's useful to be able to keep track > >>of which allocations are taking too long. For #2, migration > > > >Then, I don't think we could keep all of allocations. What we need > >is only slow allocations. I hope we can do that with ftrace. > > > >ex) > > > ># cd /sys/kernel/debug/tracing > ># echo 1 > options/stacktrace > ># echo cam_alloc > set_ftrace_filter > ># echo your_threshold > tracing_thresh > > > >I know it doesn't work now but I think it's more flexible > >and general way to handle such issues(ie, latency of some functions). > >So, I hope we could enhance ftrace rather than new wheel. > >Ccing ftrace people. > > For CMA performance test or code flow check, ftrace is better. > > ex) > echo cma_alloc > /sys/kernel/debug/tracing/set_graph_function > echo function_graph > /sys/kernel/debug/tracing/current_tracer > echo funcgraph-proc > /sys/kernel/debug/tracing/trace_options > echo nosleep-time > /sys/kernel/debug/tracing/trace_options > echo funcgraph-tail > /sys/kernel/debug/tracing/trace_options > echo 1 > /sys/kernel/debug/tracing/tracing_on I didn't know such detail. Thanks for the tip, Gioh. > > This can trace every cam_alloc and allocation time. > I think ftrace is better to debug latency. > If a buffer had allocated and had peak latency and freed, > we can check it. Agree. > > But ftrace doesn't provide current status how many buffers we have and what > address it is. > So I think debugging information is useful. I didn't say debug information is useless. If we need to know snapshot of cma at the moment, describe why we need it and send a patch to implement the idea rather than dumping lots of information is always better. > > > > > > >Futhermore, if we really need to have such information, we need more data > >(ex, how many of pages were migrated out, how many pages were dropped > >without migrated, how many pages were written back, how many pages were > >retried with the page lock and so on). > >In this case, event trace would be better. > > > > > >>failure is fairly common but it's still important to rule out > >>a memory leak from a dma client. Seeing all the allocations is > >>also very useful for memory tuning (e.g. how big does the CMA > >>region need to be, which clients are actually allocating memory). > > > >Memory leak is really general problem and could we handle it with > >page_owner? > > > >> > >>ftrace is certainly usable for tracing CMA allocation callers and > >>latency. ftrace is still only a fixed size buffer though so it's > >>possible for information to be lost if other logging is enabled. > > > >Sorry, I don't get with only above reasons why we need this. :( > > > >>For most of the CMA use cases, there is a very high cost if the > >>proper debugging information is not available so the more that > >>can be guaranteed the better. > >> > >>It's also worth noting that the SLUB allocator has a sysfs > >>interface for showing allocation callers when CONFIG_SLUB_DEBUG > >>is enabled. > >> > >>Thanks, > >>Laura > >> > >>-- > >>Qualcomm Innovation Center, Inc. > >>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > >>a Linux Foundation Collaborative Project > >> > >>-- > >>To unsubscribe, send a message with 'unsubscribe linux-mm' in > >>the body to majord...@kvack.org. For more info on Linux MM, > >>see: http://www.linux-mm.org/ . > >>Don't email: mailto:"d...@kvack.org;> em...@kvack.org > > > > -- > To unsubscribe,
[PATCH 1/2] lib/bitmap.c: Change prototype of bitmap_copy_le
Make the prototype of bitmap_copy_le the same as bitmap_copy's. All
other bitmap_* functions take unsigned long* parameters; there's no
reason this should be special.
The only current user is the static inline uwb_mas_bm_copy_le, which
already does the void* laundering, so the end users can pass their u8
or __le32 buffers without a cast.
Furthermore, this allows us to simply let bitmap_copy_le be an alias
for bitmap_copy on little-endian; see next patch.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 2 +-
lib/bitmap.c | 9 -
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 202e4034fe26..bd1748919872 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -170,7 +170,7 @@ extern void bitmap_fold(unsigned long *dst, const unsigned
long *orig,
extern int bitmap_find_free_region(unsigned long *bitmap, unsigned int bits,
int order);
extern void bitmap_release_region(unsigned long *bitmap, unsigned int pos, int
order);
extern int bitmap_allocate_region(unsigned long *bitmap, unsigned int pos, int
order);
-extern void bitmap_copy_le(void *dst, const unsigned long *src, int nbits);
+extern void bitmap_copy_le(unsigned long *dst, const unsigned long *src,
unsigned int nbits);
extern int bitmap_ord_to_pos(const unsigned long *bitmap, int n, int bits);
extern int bitmap_print_to_pagebuf(bool list, char *buf,
const unsigned long *maskp, int nmaskbits);
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 324ea9eab8c1..5ded9180528b 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -1207,16 +1207,15 @@ EXPORT_SYMBOL(bitmap_allocate_region);
*
* Require nbits % BITS_PER_LONG == 0.
*/
-void bitmap_copy_le(void *dst, const unsigned long *src, int nbits)
+void bitmap_copy_le(unsigned long *dst, const unsigned long *src, unsigned int
nbits)
{
- unsigned long *d = dst;
- int i;
+ unsigned int i;
for (i = 0; i < nbits/BITS_PER_LONG; i++) {
if (BITS_PER_LONG == 64)
- d[i] = cpu_to_le64(src[i]);
+ dst[i] = cpu_to_le64(src[i]);
else
- d[i] = cpu_to_le32(src[i]);
+ dst[i] = cpu_to_le32(src[i]);
}
}
EXPORT_SYMBOL(bitmap_copy_le);
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] lib/bitmap.c: Elide bitmap_copy_le on little-endian
On little-endian, there's no reason to have an extra, presumably less
efficient, way of copying a bitmap.
Signed-off-by: Rasmus Villemoes
---
include/linux/bitmap.h | 4
lib/bitmap.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index bd1748919872..a1977e153e63 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -170,7 +170,11 @@ extern void bitmap_fold(unsigned long *dst, const unsigned
long *orig,
extern int bitmap_find_free_region(unsigned long *bitmap, unsigned int bits,
int order);
extern void bitmap_release_region(unsigned long *bitmap, unsigned int pos, int
order);
extern int bitmap_allocate_region(unsigned long *bitmap, unsigned int pos, int
order);
+#ifdef __BIG_ENDIAN
extern void bitmap_copy_le(unsigned long *dst, const unsigned long *src,
unsigned int nbits);
+#else
+#define bitmap_copy_le bitmap_copy
+#endif
extern int bitmap_ord_to_pos(const unsigned long *bitmap, int n, int bits);
extern int bitmap_print_to_pagebuf(bool list, char *buf,
const unsigned long *maskp, int nmaskbits);
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 5ded9180528b..8014996b1531 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -1207,6 +1207,7 @@ EXPORT_SYMBOL(bitmap_allocate_region);
*
* Require nbits % BITS_PER_LONG == 0.
*/
+#ifdef __BIG_ENDIAN
void bitmap_copy_le(unsigned long *dst, const unsigned long *src, unsigned int
nbits)
{
unsigned int i;
@@ -1219,3 +1220,4 @@ void bitmap_copy_le(unsigned long *dst, const unsigned
long *src, unsigned int n
}
}
EXPORT_SYMBOL(bitmap_copy_le);
+#endif
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 答复：[PATCH] perf core: Use KSTK_ESP() instead of pt_regs->sp while output user regs
On Tue, Dec 30, 2014 at 3:29 PM, Andy Lutomirski wrote: > On Dec 30, 2014 11:03 AM, "Peter Zijlstra" wrote: >> >> On Thu, Dec 25, 2014 at 07:48:28AM -0800, Andy Lutomirski wrote: >> > On a quick look, there are plenty of other bugs in there besides just >> > the stack pointer issue. The ABI check that uses TIF_IA32 in the perf >> > core is completely wrong. TIF_IA32 may be equal to the actual >> > userspace bitness by luck, but, if so, that's more or less just luck. >> > And there's a user_mode test that should be user_mode_vm. >> > >> > Also, it's not just sp that's wrong. There are various places that >> > you can interrupt in which many of the registers have confusing >> > locations. You could try using the cfi unwind data, but that's >> > unlikely to work for regs like cs and ss, and, during context switch, >> > this has very little chance of working. >> > >> > What's the point of this feature? Honestly, my suggestion would be to >> > delete it instead of trying to fix it. It's also not clear to me that >> > there aren't serious security problems here -- it's entirely possible >> > for sensitive *kernel* values to and up in task_pt_regs at certain >> > times, and if you run during context switch and there's no code to >> > suppress this dump during context switch, then you could be showing >> > regs that belong to the wrong task. >> >> Of course the people who actually wrote the code are not on CC :/ >> >> There's two users of this iirc; >> >> 1) the dwarf stack unwinder thingy, which basically dumps the userspace >> regs and the top of userspace stack on 'event'. >> > > Given how the x86_64* entry code works, using task_pt_regs from > anywhere except explicitly supported contexts (including exceptions > that originated in userspace and a small handful of system calls) is > asking for trouble. NMI context is especially bad. > > How important is this feature, and which registers matter? It might > be possible to use a dwarf unwinder on the kernel call stack to get > most of the regs from most contexts, and it might also be possible to > make small changes to the entry code to make it possible to get some > of the registers reliably, but it's not currently possible to safely > use task_pt_regs *at all* from NMI context unless you've at least > blacklisted a handful of origin RIP values that give dangerously bogus > results. (Using do_nmi's regs parameter if user_mode_vm(regs) is a > different story.) It's actually worse than just knowing the interrupted kernel RIP. If the call chain goes usermode -> IST exception -> NMI, then task_pt_regs is entirely uninitialized. Assuming all the CFI annotations are correct, the unwinder could still do it from the kernel. Note that, as far as I know, Jan Beulich is the only person who uses the unwinder on kernel code. Jan, how do you do this? > > * I'm not nearly as familiar with the 32-bit entry code, so I don't > know whether we have the same issues there. > >> 2) the recent sample_regs_intr, which dumps the register set at >> 'event', be it kernel or userspace. >> > > What's wrong with the PMI's pt_regs for that? If we interrupted the > kernel, they'll be kernel regs (with all their attendant security > issues) and, if we interrupted userspace, then they'll be the full, > correct userspace registers. > > --Andy > >> >> The first is somewhat usable when lacking framepointers while still >> desiring some unwind information, the second is useful to things like >> call argument profiling and the like. -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] timerfd: export defines to userspace
Since userspace is expected to call timerfd syscalls directly with these
flags/ioctls, make sure we export them so they don't have to duplicate
the values themselves.
Signed-off-by: Mike Frysinger
---
include/linux/timerfd.h | 20 +---
include/uapi/linux/Kbuild| 1 +
include/uapi/linux/timerfd.h | 36
3 files changed, 38 insertions(+), 19 deletions(-)
create mode 100644 include/uapi/linux/timerfd.h
diff --git a/include/linux/timerfd.h b/include/linux/timerfd.h
index bd36ce4..bab0b1a 100644
--- a/include/linux/timerfd.h
+++ b/include/linux/timerfd.h
@@ -8,23 +8,7 @@
#ifndef _LINUX_TIMERFD_H
#define _LINUX_TIMERFD_H
-/* For O_CLOEXEC and O_NONBLOCK */
-#include
-
-/* For _IO helpers */
-#include
-
-/*
- * CAREFUL: Check include/asm-generic/fcntl.h when defining
- * new flags, since they might collide with O_* ones. We want
- * to re-use O_* flags that couldn't possibly have a meaning
- * from eventfd, in order to leave a free define-space for
- * shared O_* flags.
- */
-#define TFD_TIMER_ABSTIME (1 << 0)
-#define TFD_TIMER_CANCEL_ON_SET (1 << 1)
-#define TFD_CLOEXEC O_CLOEXEC
-#define TFD_NONBLOCK O_NONBLOCK
+#include
#define TFD_SHARED_FCNTL_FLAGS (TFD_CLOEXEC | TFD_NONBLOCK)
/* Flags for timerfd_create. */
@@ -32,6 +16,4 @@
/* Flags for timerfd_settime. */
#define TFD_SETTIME_FLAGS (TFD_TIMER_ABSTIME | TFD_TIMER_CANCEL_ON_SET)
-#define TFD_IOC_SET_TICKS _IOW('T', 0, u64)
-
#endif /* _LINUX_TIMERFD_H */
diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index 8523f9b..62ac5e7 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -384,6 +384,7 @@ header-y += tcp_metrics.h
header-y += telephony.h
header-y += termios.h
header-y += time.h
+header-y += timerfd.h
header-y += times.h
header-y += timex.h
header-y += tiocl.h
diff --git a/include/uapi/linux/timerfd.h b/include/uapi/linux/timerfd.h
new file mode 100644
index 000..6fcfaa8
--- /dev/null
+++ b/include/uapi/linux/timerfd.h
@@ -0,0 +1,36 @@
+/*
+ * include/linux/timerfd.h
+ *
+ * Copyright (C) 2007 Davide Libenzi
+ *
+ */
+
+#ifndef _UAPI_LINUX_TIMERFD_H
+#define _UAPI_LINUX_TIMERFD_H
+
+#include
+
+/* For O_CLOEXEC and O_NONBLOCK */
+#include
+
+/* For _IO helpers */
+#include
+
+/*
+ * CAREFUL: Check include/asm-generic/fcntl.h when defining
+ * new flags, since they might collide with O_* ones. We want
+ * to re-use O_* flags that couldn't possibly have a meaning
+ * from eventfd, in order to leave a free define-space for
+ * shared O_* flags.
+ *
+ * Also make sure to update the masks in include/linux/timerfd.h
+ * when adding new flags.
+ */
+#define TFD_TIMER_ABSTIME (1 << 0)
+#define TFD_TIMER_CANCEL_ON_SET (1 << 1)
+#define TFD_CLOEXEC O_CLOEXEC
+#define TFD_NONBLOCK O_NONBLOCK
+
+#define TFD_IOC_SET_TICKS _IOW('T', 0, __u64)
+
+#endif /* _UAPI_LINUX_TIMERFD_H */
--
2.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: blk-mq: should elv_iosched_store return ENXIO/EINVAL?
On 12/30/2014 04:37 PM, Sebastian Herbszt wrote:
Hello,
setting an invalid elevator without blk-mq results in an error:
# cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
# echo foo > /sys/block/sda/queue/scheduler
-bash: echo: write error: Invalid argument
# dmesg
[ 328.767088] elevator: type foo not found
[ 328.767097] elevator: switch to foo
failed
With blk-mq no error is returned:
# cat /sys/block/sda/queue/scheduler
none
# echo foo > /sys/block/sda/queue/scheduler
# echo $?
0
block/elevator.c got
988 ssize_t elv_iosched_store(struct request_queue *q, const char *name,
989 size_t count)
990 {
991 int ret;
992
993 if (!q->elevator)
994 return count;
995
996 ret = __elevator_change(q, name);
and
952 static int __elevator_change(struct request_queue *q, const char *name)
953 {
954 char elevator_name[ELV_NAME_MAX];
955 struct elevator_type *e;
956
957 if (!q->elevator)
958 return -ENXIO;
959
960 strlcpy(elevator_name, name, sizeof(elevator_name));
961 e = elevator_get(strstrip(elevator_name), true);
962 if (!e) {
963 printk(KERN_ERR "elevator: type %s not found\n",
elevator_name);
964 return -EINVAL;
965 }
So !q->elevator is checked in elv_iosched_store and __elevator_change.
Should elv_iosched_store return ENXIO or EINVAL or should __elevator_change
handle this?
I agree the behavior is strange, but it actually matches what would
happen for a make_request_fn based driver in this or earlier kernels. So
there is a worry of changing the API if we modify it in general. The
safe change would be to have these two lines before the q->elevator check:
if (q->mq_ops)
return -EINVAL;
since that's new enough not to be a "real" API change. If we do that, we
could let it slide into the general !q->elevator case after a few revisions.
Or we can just leave it as-is. If you read back the value after writing
to it, it will always return "none".
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Dec 31
Hi all, There will only be intermittent releases of linux-next between now and Jan 5. Changes since 20141226: New trees: wireless-drivers, wireless-drivers-next The rcu tree still had its build failure for which I reverted a commit. Non-merge commits (relative to Linus' tree): 842 900 files changed, 26249 insertions(+), 14327 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 236 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (2c90331cf5ed Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (f114040e3ea6 Linux 3.18-rc1) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (3f4aa45ceea5 ARM: 8226/1: cacheflush: get rid of restarting block) Merging m68k-current/for-linus (f0b99a643e96 m68k/mm: Eliminate memset after alloc_bootmem_pages) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused force_32bit_msi quirk) Merging powerpc-merge-mpe/fixes (1be6f10f6f9c Revert "powerpc: Secondary CPUs must set cpu_callin_map after setting active and online") Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() needs to disable interrupts.) Merging net/master (2c90331cf5ed Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging ipsec/master (f855691975bb xfrm6: Fix the nexthdr offset in _decode_session6.) Merging sound-current/for-linus (62f64a880af2 ALSA: pcm: Fix kerneldoc for params_*() functions) Merging pci-current/for-linus (97bf6af1f928 Linux 3.19-rc1) Merging wireless/master (97bf6af1f928 Linux 3.19-rc1) Merging wireless-drivers/master (eb46e2215fc6 Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth) Merging driver-core.current/driver-core-linus (97bf6af1f928 Linux 3.19-rc1) Merging tty.current/tty-linus (97bf6af1f928 Linux 3.19-rc1) Merging usb.current/usb-linus (b3ee8bdcd243 Merge tag 'fixes-for-v3.19-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging usb-gadget-fixes/fixes (6785a1034461 usb: gadget: udc: atmel: fix possible IN hang issue) Merging usb-serial-fixes/usb-linus (97bf6af1f928 Linux 3.19-rc1) Merging staging.current/staging-linus (97bf6af1f928 Linux 3.19-rc1) Merging char-misc.current/char-misc-linus (97bf6af1f928 Linux 3.19-rc1) Merging input-current/for-linus (cceeb872d60f Input: hil_kbd - fix incorrect use of init_completion) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (7e77bdebff5c crypto: af_alg - fix backlog handling) Merging ide/master (f96fe225677b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (094cb98179f1 of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap) Merging rr-fixes/fixes (3438cf549d2f param: fix crash on bad kernel arguments) Merging vfio-fixes/for-linus (239a87020b26 Merge branch 'for-joerg/arm-smmu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus) Merging kselftest-fixes/fixes (6898b627aab6
[PATCH] serial: omap_8250: Fix RTS handling
The OMAP3 UART ignores MCR[1] (ie., UART_MCR_RTS) when in autoRTS
mode (UPF_HARD_FLOW + CRTSCTS). This makes it impossible for either
the serial core or userspace to manually flow control the sender.
Disable autoRTS mode when RTS is lowered and restore the previous
mode when RTS is raised.
Note that the OMAP3 UART provides no mechanism for switching from
autoRTS mode without corrupting incoming data; to access the
necessary register, the line control settings must be set to 8-e-2
and thus any data received during that time will be interpreted with
those settings. This corruption has been observed in practice.
Cc: Sebastian Andrzej Siewior
Signed-off-by: Peter Hurley
---
drivers/tty/serial/8250/8250_core.c | 12 +++-
drivers/tty/serial/8250/8250_omap.c | 25 ++---
include/linux/serial_8250.h | 1 +
include/linux/serial_core.h | 1 +
4 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 11c6685..3bfcfdb 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1924,7 +1924,7 @@ static unsigned int serial8250_get_mctrl(struct uart_port
*port)
return ret;
}
-static void serial8250_set_mctrl(struct uart_port *port, unsigned int mctrl)
+void serial8250_do_set_mctrl(struct uart_port *port, unsigned int mctrl)
{
struct uart_8250_port *up = up_to_u8250p(port);
unsigned char mcr = 0;
@@ -1944,6 +1944,14 @@ static void serial8250_set_mctrl(struct uart_port *port,
unsigned int mctrl)
serial_port_out(port, UART_MCR, mcr);
}
+EXPORT_SYMBOL_GPL(serial8250_do_set_mctrl);
+
+static void serial8250_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+ if (port->set_mctrl)
+ return port->set_mctrl(port, mctrl);
+ return serial8250_do_set_mctrl(port, mctrl);
+}
static void serial8250_break_ctl(struct uart_port *port, int break_state)
{
@@ -3605,6 +3613,8 @@ int serial8250_register_8250_port(struct uart_8250_port
*up)
/* Possibly override set_termios call */
if (up->port.set_termios)
uart->port.set_termios = up->port.set_termios;
+ if (up->port.set_mctrl)
+ uart->port.set_mctrl = up->port.set_mctrl;
if (up->port.startup)
uart->port.startup = up->port.startup;
if (up->port.shutdown)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 96b69bf..428f384 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -106,6 +106,27 @@ static u32 uart_read(struct uart_8250_port *up, u32 reg)
return readl(up->port.membase + (reg << up->port.regshift));
}
+static void omap8250_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+ struct uart_8250_port *up = up_to_u8250p(port);
+ struct omap8250_priv *priv = up->port.private_data;
+ u8 lcr;
+
+ serial8250_do_set_mctrl(port, mctrl);
+
+ /*
+* Turn off autoRTS if RTS is lowered and restore autoRTS setting
+* if RTS is raised
+*/
+ lcr = serial_in(up, UART_LCR);
+ serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
+ if (mctrl & TIOCM_RTS)
+ serial_out(up, UART_EFR, priv->efr);
+ else
+ serial_out(up, UART_EFR, priv->efr & ~UART_EFR_RTS);
+ serial_out(up, UART_LCR, lcr);
+}
+
/*
* Work Around for Errata i202 (2430, 3430, 3630, 4430 and 4460)
* The access to uart register after MDR1 Access
@@ -400,9 +421,6 @@ static void omap_8250_set_termios(struct uart_port *port,
if (termios->c_cflag & CRTSCTS && up->port.flags & UPF_HARD_FLOW) {
/* Enable AUTORTS and AUTOCTS */
priv->efr |= UART_EFR_CTS | UART_EFR_RTS;
-
- /* Ensure MCR RTS is asserted */
- up->mcr |= UART_MCR_RTS;
} else if (up->port.flags & UPF_SOFT_FLOW) {
/*
* IXON Flag:
@@ -1007,6 +1025,7 @@ static int omap8250_probe(struct platform_device *pdev)
up.capabilities |= UART_CAP_RPM;
#endif
up.port.set_termios = omap_8250_set_termios;
+ up.port.set_mctrl = omap8250_set_mctrl;
up.port.pm = omap_8250_pm;
up.port.startup = omap_8250_startup;
up.port.shutdown = omap_8250_shutdown;
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index e02acf0..245b959 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -126,6 +126,7 @@ extern int serial8250_do_startup(struct uart_port *port);
extern void serial8250_do_shutdown(struct uart_port *port);
extern void serial8250_do_pm(struct uart_port *port, unsigned int state,
unsigned int oldstate);
+extern void serial8250_do_set_mctrl(struct uart_port *port, unsigned int
mctrl);
[PATCH 00/19] lib: Some #include cleanups
I'm contemplating doing some tree-wide spring cleaning, mostly
consisting of removing redundant includes, but also refactoring some
large and heterogeneous headers into smaller pieces.
This patch series consists of low-hanging fruit I picked from
lib/. I've verified that "objdump -d lib/builtin.o" produces identical
output for {allyes,allno,def}config, but this is of course only for
x86_64. There's a small but measurable build time improvement: A
defconfig build of lib/ from a clean tree is consistently .5 seconds
(2 %) faster with these patches. There are lots of other apparently
unused headers in lib/*.c, but I've only removed those where it
actually ends up disappearing from the .cmd dependency file (since
that's where the potential build gain lies, and helps prove that the
header is indeed redundant).
I expect there is much larger speedups to gain from removing includes
from .h files, but that is of course at the same time a huge can of
worms, involving boatloads of tree-wide patches updating users to
include what they use directly. So before I start doing that, I'd like
to hear if people think it would be futile.
Rasmus Villemoes (19):
lib/interval_tree.c: Simplify includes
lib/sort.c: Use simpler includes
lib/dynamic_queue_limits.c: Simplify includes
lib/halfmd4.c: Simplify includes
lib/idr.c: Remove redundant include
lib/genalloc.c: Remove redundant include
lib/list_sort.c: Rearrange includes
lib/md5.c: Simplify include
lib/llist.c: Remove redundant include
lib/kobject_uevent.c: Remove redundant include
lib/nlattr.c: Remove redundant include
lib/plist.c: Remove redundant include
lib/radix-tree.c: Change to simpler include
lib/show_mem.c: Remove redundant include
lib/sort.c: Move include inside #if 0
lib/stmp_device.c: Replace module.h include
lib/strncpy_from_user.c: Replace module.h include
lib/percpu_ida.c: Remove redundant includes
lib/lcm.c: Replace include
include/linux/cryptohash.h | 2 ++
lib/dynamic_queue_limits.c | 4 ++--
lib/genalloc.c | 1 -
lib/halfmd4.c | 2 +-
lib/idr.c | 1 -
lib/interval_tree.c| 4 ++--
lib/kobject_uevent.c | 1 -
lib/lcm.c | 2 +-
lib/list_sort.c| 7 +--
lib/llist.c| 1 -
lib/md5.c | 2 +-
lib/nlattr.c | 1 -
lib/percpu_ida.c | 3 ---
lib/plist.c| 1 -
lib/radix-tree.c | 2 +-
lib/show_mem.c | 1 -
lib/sort.c | 6 +++---
lib/stmp_device.c | 3 ++-
lib/strncpy_from_user.c| 3 ++-
19 files changed, 22 insertions(+), 25 deletions(-)
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/19] lib/dynamic_queue_limits.c: Simplify includes
The file doesn't use anything from ctype.h. Instead of module.h, just use export.h for EXPORT_SYMBOL. The latter requires the user to include compiler.h, so do that explicitly instead of relying on some other header pulling it in. Signed-off-by: Rasmus Villemoes --- lib/dynamic_queue_limits.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/dynamic_queue_limits.c b/lib/dynamic_queue_limits.c index 0777c5a45fa0..f346715e2255 100644 --- a/lib/dynamic_queue_limits.c +++ b/lib/dynamic_queue_limits.c @@ -3,12 +3,12 @@ * * Copyright (c) 2011, Tom Herbert */ -#include #include -#include #include #include #include +#include +#include #define POSDIFF(A, B) ((int)((A) - (B)) > 0 ? (A) - (B) : 0) #define AFTER_EQ(A, B) ((int)((A) - (B)) >= 0) -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/19] lib/interval_tree.c: Simplify includes
The file uses nothing from init.h, and also doesn't need the full module.h machinery; export.h is sufficient. The latter requires the user to ensure compiler.h is included, so do that explicitly instead of relying on some other header pulling it in. Signed-off-by: Rasmus Villemoes --- lib/interval_tree.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/interval_tree.c b/lib/interval_tree.c index f367f9ad544c..c85f6600a5f8 100644 --- a/lib/interval_tree.c +++ b/lib/interval_tree.c @@ -1,7 +1,7 @@ -#include #include #include -#include +#include +#include #define START(node) ((node)->start) #define LAST(node) ((node)->last) -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/19] lib/halfmd4.c: Simplify includes
We only need EXPORT_SYMBOL, so compiler.h and export.h suffice. This means linux/types.h is no longer implicitly included, so add an include of uapi/linux/types.h to linux/cryptohash.h for __u32. Other users of cryptohash.h cannot be affected, since they must already have been including uapi/linux/types.h in order for gcc not to complain about unknown types. Signed-off-by: Rasmus Villemoes --- include/linux/cryptohash.h | 2 ++ lib/halfmd4.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/cryptohash.h b/include/linux/cryptohash.h index 2cd9f1cf9fa3..f4754282c9c2 100644 --- a/include/linux/cryptohash.h +++ b/include/linux/cryptohash.h @@ -1,6 +1,8 @@ #ifndef __CRYPTOHASH_H #define __CRYPTOHASH_H +#include + #define SHA_DIGEST_WORDS 5 #define SHA_MESSAGE_BYTES (512 /*bits*/ / 8) #define SHA_WORKSPACE_WORDS 16 diff --git a/lib/halfmd4.c b/lib/halfmd4.c index 66d0ee8b7776..a8fe6274a13c 100644 --- a/lib/halfmd4.c +++ b/lib/halfmd4.c @@ -1,4 +1,4 @@ -#include +#include #include #include -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/19] lib/md5.c: Simplify include
md5.c doesn't use anything from kernel.h, except that that pulls in compiler.h, which is needed for the export.h to work. Signed-off-by: Rasmus Villemoes --- lib/md5.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/md5.c b/lib/md5.c index 958a3c15923c..bb0cd01d356d 100644 --- a/lib/md5.c +++ b/lib/md5.c @@ -1,4 +1,4 @@ -#include +#include #include #include -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/19] lib/sort.c: Use simpler includes
sort.c doesn't use facilities from kernel.h, but does use some types defined in linux/types.h. Include the latter directly instead of relying on some other header doing it. Similarly, include linux/export.h directly instead of through module.h. This removes 80 lines from the dependency file .sort.o.cmd. Signed-off-by: Rasmus Villemoes --- lib/sort.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/sort.c b/lib/sort.c index 926d00429ed2..14fc1dfadb3f 100644 --- a/lib/sort.c +++ b/lib/sort.c @@ -4,8 +4,8 @@ * Jan 23 2005 Matt Mackall */ -#include -#include +#include +#include #include #include -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/19] lib/list_sort.c: Rearrange includes
Memory allocation only happens in the self test, just as random numbers are only used there. So move the inclusion of slab.h inside the CONFIG_TEST_LIST_SORT. We don't need module.h and all of the stuff it carries with it, so replace with export.h and compiler.h. Unfortunately, the ARRAY_SIZE macro from kernel.h requires the user to ensure bug.h is also included (for BUILD_BUG_ON_ZERO, used by __must_be_array). We used to get that through some maze of nested includes, but just include it explicitly. linux/string.h is then only included implicitly through kernel.h->printk.h->dynamic_debug.h, but only if !CONFIG_DYNAMIC_DEBUG, so just include it explicitly (for memset). objdump -d says the generated code is the same, and wc -l says that lib/.list_sort.o.cmd went from 579 to 165 lines. Signed-off-by: Rasmus Villemoes --- lib/list_sort.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lib/list_sort.c b/lib/list_sort.c index 12bcba1c8612..b29015102698 100644 --- a/lib/list_sort.c +++ b/lib/list_sort.c @@ -2,9 +2,11 @@ #define pr_fmt(fmt) "list_sort_test: " fmt #include -#include +#include +#include +#include +#include #include -#include #include #define MAX_LIST_LENGTH_BITS 20 @@ -146,6 +148,7 @@ EXPORT_SYMBOL(list_sort); #ifdef CONFIG_TEST_LIST_SORT +#include #include /* -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/19] lib/llist.c: Remove redundant include
This file doesn't seem to use anything provided by linux/interrupt.h or anything recursively included through that. Removing it produces byte-identical output, while reducing .llist.o.cmd from 541 to 156 lines. Signed-off-by: Rasmus Villemoes --- lib/llist.c | 1 - 1 file changed, 1 deletion(-) diff --git a/lib/llist.c b/lib/llist.c index f76196d07409..0b0e9779d675 100644 --- a/lib/llist.c +++ b/lib/llist.c @@ -24,7 +24,6 @@ */ #include #include -#include #include -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/19] lib/idr.c: Remove redundant include
idr.c doesn't seem to use anything from hardirq.h (or anything included from that). Removing it produces identical objdump -d output, and gives 44 fewer lines in the .idr.o.cmd dependency file. Signed-off-by: Rasmus Villemoes --- lib/idr.c | 1 - 1 file changed, 1 deletion(-) diff --git a/lib/idr.c b/lib/idr.c index e654aebd5f80..5335c43adf46 100644 --- a/lib/idr.c +++ b/lib/idr.c @@ -30,7 +30,6 @@ #include #include #include -#include #define MAX_IDR_SHIFT (sizeof(int) * 8 - 1) #define MAX_IDR_BIT(1U << MAX_IDR_SHIFT) -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/19] lib/nlattr.c: Remove redundant include
nlattr.c doesn't seem to rely on anything from netdevice.h. Removing
it yields identical objdump -d output for each of {allyes,allno,def}config,
and eliminates more than 200 lines from the generated dependency file.
Signed-off-by: Rasmus Villemoes
---
lib/nlattr.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/nlattr.c b/lib/nlattr.c
index 9c3e85ff0a6c..76a1b59523ab 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include
#include
#include
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/19] lib/radix-tree.c: Change to simpler include
The comment helpfully explains why hardirq.h is included, but since
2d4b84739f0a ("hardirq: Split preempt count mask definitions")
in_interrupt() has been provided by preempt_mask.h. Use that instead,
saving around 40 lines in the generated dependency file.
Signed-off-by: Rasmus Villemoes
---
lib/radix-tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/radix-tree.c b/lib/radix-tree.c
index 3291a8e37490..3d2aa27b845b 100644
--- a/lib/radix-tree.c
+++ b/lib/radix-tree.c
@@ -33,7 +33,7 @@
#include
#include
#include
-#include /* in_interrupt() */
+#include /* in_interrupt() */
/*
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/19] lib/show_mem.c: Remove redundant include
show_mem.c doesn't use anything from nmi.h. Removing it yields
identical objdump -d output for each of {allyes,allno,def}config and
eliminates more than 100 lines in the dependency file.
Signed-off-by: Rasmus Villemoes
---
lib/show_mem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/show_mem.c b/lib/show_mem.c
index 7de89f4a36cf..adc98e1825ba 100644
--- a/lib/show_mem.c
+++ b/lib/show_mem.c
@@ -6,7 +6,6 @@
*/
#include
-#include
#include
#include
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/19] lib/plist.c: Remove redundant include
Removing the include of linux/spinlock.h produces byte-identical
output for {allno,def}config, and identical objdump -d output for
allyesconfig. In the former two cases, more than a 100 lines are
eliminated from the generated dependency file.
Signed-off-by: Rasmus Villemoes
---
lib/plist.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/plist.c b/lib/plist.c
index d408e774b746..3a30c53db061 100644
--- a/lib/plist.c
+++ b/lib/plist.c
@@ -25,7 +25,6 @@
#include
#include
-#include
#ifdef CONFIG_DEBUG_PI_LIST
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/19] lib/stmp_device.c: Replace module.h include
stmp_device.c only needs EXPORT_SYMBOL, so just include compiler.h and export.h instead of the whole module.h machinery. Signed-off-by: Rasmus Villemoes --- lib/stmp_device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/stmp_device.c b/lib/stmp_device.c index 8ac9bcc4289a..a904656f4fd7 100644 --- a/lib/stmp_device.c +++ b/lib/stmp_device.c @@ -15,7 +15,8 @@ #include #include #include -#include +#include +#include #include #define STMP_MODULE_CLKGATE(1 << 30) -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 17/19] lib/strncpy_from_user.c: Replace module.h include
strncpy_from_user.c only needs EXPORT_SYMBOL, so just include compiler.h and export.h instead of the whole module.h machinery. Signed-off-by: Rasmus Villemoes --- lib/strncpy_from_user.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/strncpy_from_user.c b/lib/strncpy_from_user.c index bb2b201d6ad0..e0af6ff73d14 100644 --- a/lib/strncpy_from_user.c +++ b/lib/strncpy_from_user.c @@ -1,4 +1,5 @@ -#include +#include +#include #include #include #include -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/19] lib/kobject_uevent.c: Remove redundant include
The file doesn't seem to use anything from linux/user_namespace.h, and removing it yields byte-identical object code and strictly fewer dependencies in the .cmd file. Signed-off-by: Rasmus Villemoes --- lib/kobject_uevent.c | 1 - 1 file changed, 1 deletion(-) diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c index 9ebf9e20de53..f6c2c1e7779c 100644 --- a/lib/kobject_uevent.c +++ b/lib/kobject_uevent.c @@ -20,7 +20,6 @@ #include #include #include -#include #include #include #include -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 18/19] lib/percpu_ida.c: Remove redundant includes
These three #includes seem to be completely redundant: Removing them
yields identical objdump -d output for each of
{allyes,allno,def}config, and neither included file end up in the
generated dependency file through some recursive include. In total,
about 50 lines are eliminated from .percpu.o.cmd.
Signed-off-by: Rasmus Villemoes
---
lib/percpu_ida.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/lib/percpu_ida.c b/lib/percpu_ida.c
index 93d145e5539c..f75715131f20 100644
--- a/lib/percpu_ida.c
+++ b/lib/percpu_ida.c
@@ -19,13 +19,10 @@
#include
#include
#include
-#include
-#include
#include
#include
#include
#include
-#include
#include
#include
#include
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 19/19] lib/lcm.c: Replace include
We don't need all the stuff kernel.h pulls in; just compiler.h since export.h doesn't do necessary #includes. This removes more than 100 dependencies. Signed-off-by: Rasmus Villemoes --- lib/lcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/lcm.c b/lib/lcm.c index 51cc6b13cd52..e97dbd51e756 100644 --- a/lib/lcm.c +++ b/lib/lcm.c @@ -1,4 +1,4 @@ -#include +#include #include #include #include -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/19] lib/genalloc.c: Remove redundant include
Removing this include produces byte-identical output, and thus removes a false dependency. Signed-off-by: Rasmus Villemoes --- lib/genalloc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/lib/genalloc.c b/lib/genalloc.c index 2e65d206b01c..17d8f58f6716 100644 --- a/lib/genalloc.c +++ b/lib/genalloc.c @@ -34,7 +34,6 @@ #include #include #include -#include #include static inline size_t chunk_size(const struct gen_pool_chunk *chunk) -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/19] lib/sort.c: Move include inside #if 0
The sort function and its helpers don't do memory allocation, so the
slab.h include is redundant. Move it inside the #if 0 protecting the
self-test, similar to how it is done in lib/list_sort.c. This removes
over 450 lines from the generated dependency file.
Signed-off-by: Rasmus Villemoes
---
lib/sort.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/sort.c b/lib/sort.c
index 14fc1dfadb3f..43c9fe73ae2e 100644
--- a/lib/sort.c
+++ b/lib/sort.c
@@ -7,7 +7,6 @@
#include
#include
#include
-#include
static void u32_swap(void *a, void *b, int size)
{
@@ -85,6 +84,7 @@ void sort(void *base, size_t num, size_t size,
EXPORT_SYMBOL(sort);
#if 0
+#include
/* a simple boot-time regression test */
int cmpint(const void *a, const void *b)
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v17 03/12] input: cyapa: add power management interfaces support for the device
Add suspend_scanrate_ms power management interfaces in device's
power group, so users or applications can control the power management
strategy of trackpad device as their requirements.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 127
1 file changed, 127 insertions(+)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 725c84a..46d3830 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -604,6 +604,127 @@ out:
return IRQ_HANDLED;
}
+/*
+ **
+ * sysfs interface
+ **
+*/
+#ifdef CONFIG_PM_SLEEP
+static ssize_t cyapa_show_suspend_scanrate(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ u8 pwr_cmd = cyapa->suspend_power_mode;
+ u16 sleep_time;
+ int len;
+ int error;
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ pwr_cmd = cyapa->suspend_power_mode;
+ sleep_time = cyapa->suspend_sleep_time;
+ mutex_unlock(>state_sync_lock);
+
+ if (pwr_cmd == PWR_MODE_BTN_ONLY) {
+ len = scnprintf(buf, PAGE_SIZE, "%s\n", BTN_ONLY_MODE_NAME);
+ } else if (pwr_cmd == PWR_MODE_OFF) {
+ len = scnprintf(buf, PAGE_SIZE, "%s\n", OFF_MODE_NAME);
+ } else {
+ if (cyapa->gen == CYAPA_GEN3)
+ sleep_time = cyapa_pwr_cmd_to_sleep_time(pwr_cmd);
+ len = scnprintf(buf, PAGE_SIZE, "%u\n", sleep_time);
+ }
+
+ return len;
+}
+
+static ssize_t cyapa_update_suspend_scanrate(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ u16 sleep_time;
+ int error;
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+
+ if (sysfs_streq(buf, BTN_ONLY_MODE_NAME)) {
+ cyapa->suspend_power_mode = PWR_MODE_BTN_ONLY;
+ } else if (sysfs_streq(buf, OFF_MODE_NAME)) {
+ cyapa->suspend_power_mode = PWR_MODE_OFF;
+ } else if (!kstrtou16(buf, 10, _time)) {
+ cyapa->suspend_sleep_time = max_t(u16, sleep_time, 1000);
+ cyapa->suspend_power_mode =
+ cyapa_sleep_time_to_pwr_cmd(cyapa->suspend_sleep_time);
+ } else {
+ count = 0;
+ }
+
+ mutex_unlock(>state_sync_lock);
+
+ return count ? count : -EINVAL;
+}
+
+static DEVICE_ATTR(suspend_scanrate_ms, S_IRUGO|S_IWUSR,
+ cyapa_show_suspend_scanrate,
+ cyapa_update_suspend_scanrate);
+
+static struct attribute *cyapa_power_wakeup_entries[] = {
+ _attr_suspend_scanrate_ms.attr,
+ NULL,
+};
+
+static const struct attribute_group cyapa_power_wakeup_group = {
+ .name = power_group_name,
+ .attrs = cyapa_power_wakeup_entries,
+};
+
+static void cyapa_remove_power_wakeup_group(void *data)
+{
+ struct cyapa *cyapa = data;
+
+ sysfs_unmerge_group(>client->dev.kobj,
+ _power_wakeup_group);
+}
+
+static int cyapa_prepare_wakeup_controls(struct cyapa *cyapa)
+{
+ struct i2c_client *client = cyapa->client;
+ struct device *dev = >dev;
+ int error;
+
+ if (device_can_wakeup(dev)) {
+ error = sysfs_merge_group(>dev.kobj,
+ _power_wakeup_group);
+ if (error) {
+ dev_err(dev, "failed to add power wakeup group: %d\n",
+ error);
+ return error;
+ }
+
+ error = devm_add_action(dev,
+ cyapa_remove_power_wakeup_group, cyapa);
+ if (error) {
+ cyapa_remove_power_wakeup_group(cyapa);
+ dev_err(dev, "failed to add power cleanup action: %d\n",
+ error);
+ return error;
+ }
+ }
+
+ return 0;
+}
+#else
+static inline int cyapa_prepare_wakeup_controls(struct cyapa *cyapa)
+{
+ return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
static int cyapa_probe(struct i2c_client *client,
const struct i2c_device_id *dev_id)
{
@@ -643,6 +764,12 @@ static int cyapa_probe(struct i2c_client *client,
return error;
}
+ error = cyapa_prepare_wakeup_controls(cyapa);
+ if (error) {
+ dev_err(dev, "failed to prepare wakeup controls: %d\n",
[PATCH v17 04/12] input: cyapa: add runtime power management interfaces support for the device
Add runtime_suspend_scanrate_ms power management interfaces in device's
power group, so users or applications can control the runtime power
management strategy of trackpad device as their requirements.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 180 +++-
drivers/input/mouse/cyapa.h | 4 +
2 files changed, 183 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 46d3830..080b93f 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "cyapa.h"
@@ -357,6 +358,10 @@ static int cyapa_open(struct input_dev *input)
}
enable_irq(client->irq);
+ if (!pm_runtime_enabled(>dev)) {
+ pm_runtime_set_active(>dev);
+ pm_runtime_enable(>dev);
+ }
out:
mutex_unlock(>state_sync_lock);
return error;
@@ -370,8 +375,11 @@ static void cyapa_close(struct input_dev *input)
mutex_lock(>state_sync_lock);
disable_irq(client->irq);
+ if (pm_runtime_enabled(>dev))
+ pm_runtime_disable(>dev);
if (cyapa->operational)
cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0);
+ pm_runtime_set_suspended(>dev);
mutex_unlock(>state_sync_lock);
}
@@ -539,6 +547,9 @@ static int cyapa_reinitialize(struct cyapa *cyapa)
struct input_dev *input = cyapa->input;
int error;
+ if (pm_runtime_enabled(dev))
+ pm_runtime_disable(dev);
+
/* Avoid command failures when TP was in OFF state. */
if (cyapa->operational)
cyapa->ops->set_power_mode(cyapa, PWR_MODE_FULL_ACTIVE, 0);
@@ -561,6 +572,13 @@ out:
/* Reset to power OFF state to save power when no user open. */
if (cyapa->operational)
cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0);
+ } else if (!error && cyapa->operational) {
+ /*
+* Make sure only enable runtime PM when device is
+* in operational mode and input->users > 0.
+*/
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
}
return error;
@@ -571,6 +589,7 @@ static irqreturn_t cyapa_irq(int irq, void *dev_id)
struct cyapa *cyapa = dev_id;
struct device *dev = >client->dev;
+ pm_runtime_get_sync(dev);
if (device_may_wakeup(dev))
pm_wakeup_event(dev, 0);
@@ -601,6 +620,8 @@ static irqreturn_t cyapa_irq(int irq, void *dev_id)
}
out:
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_put_sync_autosuspend(dev);
return IRQ_HANDLED;
}
@@ -725,6 +746,118 @@ static inline int cyapa_prepare_wakeup_controls(struct
cyapa *cyapa)
}
#endif /* CONFIG_PM_SLEEP */
+#ifdef CONFIG_PM_RUNTIME
+static ssize_t cyapa_show_rt_suspend_scanrate(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ u8 pwr_cmd;
+ u16 sleep_time;
+ int error;
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ pwr_cmd = cyapa->runtime_suspend_power_mode;
+ sleep_time = cyapa->runtime_suspend_sleep_time;
+ mutex_unlock(>state_sync_lock);
+
+ if (cyapa->gen == CYAPA_GEN3)
+ return scnprintf(buf, PAGE_SIZE, "%u\n",
+ cyapa_pwr_cmd_to_sleep_time(pwr_cmd));
+ return scnprintf(buf, PAGE_SIZE, "%u\n", sleep_time);
+}
+
+static ssize_t cyapa_update_rt_suspend_scanrate(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ u16 time;
+ int error;
+
+ if (buf == NULL || count == 0 || kstrtou16(buf, 10, )) {
+ dev_err(dev, "invalid runtime suspend scanrate ms parameter\n");
+ return -EINVAL;
+ }
+
+ /*
+* When the suspend scanrate is changed, pm_runtime_get to resume
+* a potentially suspended device, update to the new pwr_cmd
+* and then pm_runtime_put to suspend into the new power mode.
+*/
+ pm_runtime_get_sync(dev);
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ cyapa->runtime_suspend_sleep_time = max_t(u16, time, 1000);
+ cyapa->runtime_suspend_power_mode =
+ cyapa_sleep_time_to_pwr_cmd(cyapa->runtime_suspend_sleep_time);
+ mutex_unlock(>state_sync_lock);
+ pm_runtime_put_sync_autosuspend(dev);
+
+ return count;
+}
+
[PATCH v17 01/12] input: cyapa: re-design driver to support multi-trackpad in one driver
In order to support multiple different chipsets and communication protocols trackpad devices in one cyapa driver, the new cyapa driver is re-designed with one cyapa driver core and multiple device specific functions component. The cyapa driver core is contained in this patch, it supplies basic functions that working with kernel and input subsystem, and also supplies the interfaces that the specific devices' component can connect and work together with as one driver. TEST=test on Chromebooks. Signed-off-by: Dudley Du --- drivers/input/mouse/Makefile |3 +- drivers/input/mouse/cyapa.c | 1076 +++--- drivers/input/mouse/cyapa.h | 296 +++ drivers/input/mouse/cyapa_gen3.c | 807 4 files changed, 1516 insertions(+), 666 deletions(-) create mode 100644 drivers/input/mouse/cyapa.h create mode 100644 drivers/input/mouse/cyapa_gen3.c diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile index 560003d..8bd950d 100644 --- a/drivers/input/mouse/Makefile +++ b/drivers/input/mouse/Makefile @@ -8,7 +8,7 @@ obj-$(CONFIG_MOUSE_AMIGA) += amimouse.o obj-$(CONFIG_MOUSE_APPLETOUCH) += appletouch.o obj-$(CONFIG_MOUSE_ATARI) += atarimouse.o obj-$(CONFIG_MOUSE_BCM5974)+= bcm5974.o -obj-$(CONFIG_MOUSE_CYAPA) += cyapa.o +obj-$(CONFIG_MOUSE_CYAPA) += cyapatp.o obj-$(CONFIG_MOUSE_ELAN_I2C) += elan_i2c.o obj-$(CONFIG_MOUSE_GPIO) += gpio_mouse.o obj-$(CONFIG_MOUSE_INPORT) += inport.o @@ -24,6 +24,7 @@ obj-$(CONFIG_MOUSE_SYNAPTICS_I2C) += synaptics_i2c.o obj-$(CONFIG_MOUSE_SYNAPTICS_USB) += synaptics_usb.o obj-$(CONFIG_MOUSE_VSXXXAA)+= vsxxxaa.o +cyapatp-objs := cyapa.o cyapa_gen3.o psmouse-objs := psmouse-base.o synaptics.o focaltech.o psmouse-$(CONFIG_MOUSE_PS2_ALPS) += alps.o diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c index 1bece8c..37b1e37 100644 --- a/drivers/input/mouse/cyapa.c +++ b/drivers/input/mouse/cyapa.c @@ -20,408 +20,127 @@ #include #include #include +#include #include +#include +#include "cyapa.h" -/* APA trackpad firmware generation */ -#define CYAPA_GEN3 0x03 /* support MT-protocol B with tracking ID. */ - -#define CYAPA_NAME "Cypress APA Trackpad (cyapa)" - -/* commands for read/write registers of Cypress trackpad */ -#define CYAPA_CMD_SOFT_RESET 0x00 -#define CYAPA_CMD_POWER_MODE 0x01 -#define CYAPA_CMD_DEV_STATUS 0x02 -#define CYAPA_CMD_GROUP_DATA 0x03 -#define CYAPA_CMD_GROUP_CMD0x04 -#define CYAPA_CMD_GROUP_QUERY 0x05 -#define CYAPA_CMD_BL_STATUS0x06 -#define CYAPA_CMD_BL_HEAD 0x07 -#define CYAPA_CMD_BL_CMD 0x08 -#define CYAPA_CMD_BL_DATA 0x09 -#define CYAPA_CMD_BL_ALL 0x0a -#define CYAPA_CMD_BLK_PRODUCT_ID 0x0b -#define CYAPA_CMD_BLK_HEAD 0x0c - -/* report data start reg offset address. */ -#define DATA_REG_START_OFFSET 0x - -#define BL_HEAD_OFFSET 0x00 -#define BL_DATA_OFFSET 0x10 - -/* - * Operational Device Status Register - * - * bit 7: Valid interrupt source - * bit 6 - 4: Reserved - * bit 3 - 2: Power status - * bit 1 - 0: Device status - */ -#define REG_OP_STATUS 0x00 -#define OP_STATUS_SRC 0x80 -#define OP_STATUS_POWER 0x0c -#define OP_STATUS_DEV 0x03 -#define OP_STATUS_MASK (OP_STATUS_SRC | OP_STATUS_POWER | OP_STATUS_DEV) - -/* - * Operational Finger Count/Button Flags Register - * - * bit 7 - 4: Number of touched finger - * bit 3: Valid data - * bit 2: Middle Physical Button - * bit 1: Right Physical Button - * bit 0: Left physical Button - */ -#define REG_OP_DATA1 0x01 -#define OP_DATA_VALID 0x08 -#define OP_DATA_MIDDLE_BTN 0x04 -#define OP_DATA_RIGHT_BTN 0x02 -#define OP_DATA_LEFT_BTN 0x01 -#define OP_DATA_BTN_MASK (OP_DATA_MIDDLE_BTN | OP_DATA_RIGHT_BTN | \ - OP_DATA_LEFT_BTN) - -/* - * Bootloader Status Register - * - * bit 7: Busy - * bit 6 - 5: Reserved - * bit 4: Bootloader running - * bit 3 - 1: Reserved - * bit 0: Checksum valid - */ -#define REG_BL_STATUS0x01 -#define BL_STATUS_BUSY 0x80 -#define BL_STATUS_RUNNING0x10 -#define BL_STATUS_DATA_VALID 0x08 -#define BL_STATUS_CSUM_VALID 0x01 - -/* - * Bootloader Error Register - * - * bit 7: Invalid - * bit 6: Invalid security key - * bit 5: Bootloading - * bit 4: Command checksum - * bit 3: Flash protection error - * bit 2: Flash checksum error - * bit 1 - 0: Reserved - */ -#define REG_BL_ERROR 0x02 -#define BL_ERROR_INVALID 0x80 -#define BL_ERROR_INVALID_KEY 0x40 -#define BL_ERROR_BOOTLOADING 0x20 -#define BL_ERROR_CMD_CSUM0x10 -#define BL_ERROR_FLASH_PROT 0x08 -#define BL_ERROR_FLASH_CSUM 0x04 - -#define BL_STATUS_SIZE 3 /* length of bootloader status registers */ -#define BLK_HEAD_BYTES 32 - -#define PRODUCT_ID_SIZE 16 -#define QUERY_DATA_SIZE 27
[PATCH v17 02/12] input: cyapa: add gen5 trackpad device basic functions support
Based on the cyapa core, add the gen5 trackpad device's basic functions
supported, so gen5 trackpad device can work with kernel input system.
And also based on the state parse interface, the cyapa driver can
automatically determine the attached is gen3 or gen5 protocol trackpad
device, then set the correct protocol to work with the attached
trackpad device.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/Makefile |2 +-
drivers/input/mouse/cyapa.c | 13 +
drivers/input/mouse/cyapa.h |1 +
drivers/input/mouse/cyapa_gen5.c | 1678 ++
4 files changed, 1693 insertions(+), 1 deletion(-)
create mode 100644 drivers/input/mouse/cyapa_gen5.c
diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
index 8bd950d..8a9c98e 100644
--- a/drivers/input/mouse/Makefile
+++ b/drivers/input/mouse/Makefile
@@ -24,7 +24,7 @@ obj-$(CONFIG_MOUSE_SYNAPTICS_I2C) += synaptics_i2c.o
obj-$(CONFIG_MOUSE_SYNAPTICS_USB) += synaptics_usb.o
obj-$(CONFIG_MOUSE_VSXXXAA)+= vsxxxaa.o
-cyapatp-objs := cyapa.o cyapa_gen3.o
+cyapatp-objs := cyapa.o cyapa_gen3.o cyapa_gen5.o
psmouse-objs := psmouse-base.o synaptics.o focaltech.o
psmouse-$(CONFIG_MOUSE_PS2_ALPS) += alps.o
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 37b1e37..725c84a 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -184,6 +184,14 @@ static int cyapa_get_state(struct cyapa *cyapa)
if (!error)
goto out_detected;
}
+ if ((cyapa->gen == CYAPA_GEN_UNKNOWN ||
+ cyapa->gen == CYAPA_GEN5) &&
+ !smbus && even_addr) {
+ error = cyapa_gen5_ops.state_parse(cyapa,
+ status, BL_STATUS_SIZE);
+ if (!error)
+ goto out_detected;
+ }
/*
* Write 0x00 0x00 to trackpad device to force update its
@@ -272,6 +280,9 @@ static int cyapa_check_is_operational(struct cyapa *cyapa)
return error;
switch (cyapa->gen) {
+ case CYAPA_GEN5:
+ cyapa->ops = _gen5_ops;
+ break;
case CYAPA_GEN3:
cyapa->ops = _gen3_ops;
break;
@@ -506,6 +517,8 @@ static int cyapa_initialize(struct cyapa *cyapa)
/* ops.initialize() is aimed to prepare for module communications. */
error = cyapa_gen3_ops.initialize(cyapa);
+ if (!error)
+ error = cyapa_gen5_ops.initialize(cyapa);
if (error)
return error;
diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
index aab19b7..481a60d 100644
--- a/drivers/input/mouse/cyapa.h
+++ b/drivers/input/mouse/cyapa.h
@@ -292,5 +292,6 @@ u16 cyapa_pwr_cmd_to_sleep_time(u8 pwr_mode);
extern const char product_id[];
extern const struct cyapa_dev_ops cyapa_gen3_ops;
+extern const struct cyapa_dev_ops cyapa_gen5_ops;
#endif
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
new file mode 100644
index 000..a049ae3
--- /dev/null
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -0,0 +1,1678 @@
+/*
+ * Cypress APA trackpad with I2C interface
+ *
+ * Author: Dudley Du
+ *
+ * Copyright (C) 2014 Cypress Semiconductor, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "cyapa.h"
+
+
+/* Macro of Gen5 */
+#define RECORD_EVENT_NONE0
+#define RECORD_EVENT_TOUCHDOWN 1
+#define RECORD_EVENT_DISPLACE2
+#define RECORD_EVENT_LIFTOFF 3
+
+#define CYAPA_TSG_FLASH_MAP_BLOCK_SIZE 0x80
+#define CYAPA_TSG_IMG_FW_HDR_SIZE 13
+#define CYAPA_TSG_FW_ROW_SIZE (CYAPA_TSG_FLASH_MAP_BLOCK_SIZE)
+#define CYAPA_TSG_IMG_START_ROW_NUM 0x002e
+#define CYAPA_TSG_IMG_END_ROW_NUM 0x01fe
+#define CYAPA_TSG_IMG_APP_INTEGRITY_ROW_NUM 0x01ff
+#define CYAPA_TSG_IMG_MAX_RECORDS (CYAPA_TSG_IMG_END_ROW_NUM - \
+ CYAPA_TSG_IMG_START_ROW_NUM + 1 + 1)
+#define CYAPA_TSG_IMG_READ_SIZE (CYAPA_TSG_FLASH_MAP_BLOCK_SIZE /
2)
+#define CYAPA_TSG_START_OF_APPLICATION 0x1700
+#define CYAPA_TSG_APP_INTEGRITY_SIZE60
+#define CYAPA_TSG_FLASH_MAP_METADATA_SIZE 60
+#define CYAPA_TSG_BL_KEY_SIZE 8
+
+#define CYAPA_TSG_MAX_CMD_SIZE 256
+
+#define GEN5_BL_CMD_VERIFY_APP_INTEGRITY0x31
+#define GEN5_BL_CMD_GET_BL_INFO0x38
+#define GEN5_BL_CMD_PROGRAM_VERIFY_ROW 0x39
+#define GEN5_BL_CMD_LAUNCH_APP 0x3b
+#define GEN5_BL_CMD_INITIATE_BL
[PATCH v17 06/12] input: cyapa: add gen3 trackpad device firmware update function support
Add firmware image update function supported for gen3 trackpad device,
it can be used through sysfs update_fw interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen3.c | 291 +++
1 file changed, 291 insertions(+)
diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
index 1b62c7d..715abda 100644
--- a/drivers/input/mouse/cyapa_gen3.c
+++ b/drivers/input/mouse/cyapa_gen3.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "cyapa.h"
@@ -115,6 +116,18 @@ struct cyapa_reg_data {
struct cyapa_touch touches[5];
} __packed;
+struct gen3_write_block_cmd {
+ u8 checksum_seed; /* Always be 0xff */
+ u8 cmd_code; /* command code: 0x39 */
+ u8 key[8]; /* 8-byte security key */
+ __be16 block_num;
+ u8 block_data[CYAPA_FW_BLOCK_SIZE];
+ u8 block_checksum; /* Calculated using bytes 12 - 75 */
+ u8 cmd_checksum;/* Calculated using bytes 0-76 */
+} __packed;
+
+static const u8 security_key[] = {
+ 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07 };
static const u8 bl_activate[] = { 0x00, 0xff, 0x38, 0x00, 0x01, 0x02, 0x03,
0x04, 0x05, 0x06, 0x07 };
static const u8 bl_deactivate[] = { 0x00, 0xff, 0x3b, 0x00, 0x01, 0x02, 0x03,
@@ -423,6 +436,69 @@ static int cyapa_gen3_state_parse(struct cyapa *cyapa, u8
*reg_data, int len)
return -EAGAIN;
}
+/*
+ * Enter bootloader by soft resetting the device.
+ *
+ * If device is already in the bootloader, the function just returns.
+ * Otherwise, reset the device; after reset, device enters bootloader idle
+ * state immediately.
+ *
+ * Returns:
+ * 0on success
+ * -EAGAIN device was reset, but is not now in bootloader idle state
+ * < 0 if the device never responds within the timeout
+ */
+static int cyapa_gen3_bl_enter(struct cyapa *cyapa)
+{
+ int error;
+
+ error = cyapa_poll_state(cyapa, 500);
+ if (error)
+ return error;
+ if (cyapa->state == CYAPA_STATE_BL_IDLE) {
+ /* Already in BL_IDLE. Skipping reset. */
+ return 0;
+ }
+
+ if (cyapa->state != CYAPA_STATE_OP)
+ return -EAGAIN;
+
+ cyapa->state = CYAPA_STATE_NO_DEVICE;
+ error = cyapa_write_byte(cyapa, CYAPA_CMD_SOFT_RESET, 0x01);
+ if (error)
+ return -EIO;
+
+ usleep_range(25000, 5);
+ error = cyapa_poll_state(cyapa, 500);
+ if (error)
+ return error;
+ if ((cyapa->state != CYAPA_STATE_BL_IDLE) ||
+ (cyapa->status[REG_BL_STATUS] & BL_STATUS_WATCHDOG))
+ return -EAGAIN;
+
+ return 0;
+}
+
+static int cyapa_gen3_bl_activate(struct cyapa *cyapa)
+{
+ int error;
+
+ error = cyapa_i2c_reg_write_block(cyapa, 0, sizeof(bl_activate),
+ bl_activate);
+ if (error)
+ return error;
+
+ /* Wait for bootloader to activate; takes between 2 and 12 seconds */
+ msleep(2000);
+ error = cyapa_poll_state(cyapa, 11000);
+ if (error)
+ return error;
+ if (cyapa->state != CYAPA_STATE_BL_ACTIVE)
+ return -EAGAIN;
+
+ return 0;
+}
+
static int cyapa_gen3_bl_deactivate(struct cyapa *cyapa)
{
int error;
@@ -483,6 +559,212 @@ static int cyapa_gen3_bl_exit(struct cyapa *cyapa)
return 0;
}
+static u16 cyapa_gen3_csum(const u8 *buf, size_t count)
+{
+ int i;
+ u16 csum = 0;
+
+ for (i = 0; i < count; i++)
+ csum += buf[i];
+
+ return csum;
+}
+
+/*
+ * Verify the integrity of a CYAPA firmware image file.
+ *
+ * The firmware image file is 30848 bytes, composed of 482 64-byte blocks.
+ *
+ * The first 2 blocks are the firmware header.
+ * The next 480 blocks are the firmware image.
+ *
+ * The first two bytes of the header hold the header checksum, computed by
+ * summing the other 126 bytes of the header.
+ * The last two bytes of the header hold the firmware image checksum, computed
+ * by summing the 30720 bytes of the image modulo 0x.
+ *
+ * Both checksums are stored little-endian.
+ */
+static int cyapa_gen3_check_fw(struct cyapa *cyapa, const struct firmware *fw)
+{
+ struct device *dev = >client->dev;
+ u16 csum;
+ u16 csum_expected;
+
+ /* Firmware must match exact 30848 bytes = 482 64-byte blocks. */
+ if (fw->size != CYAPA_FW_SIZE) {
+ dev_err(dev, "invalid firmware size = %zu, expected %u.\n",
+ fw->size, CYAPA_FW_SIZE);
+ return -EINVAL;
+ }
+
+ /* Verify header block */
+ csum_expected = (fw->data[0] << 8) | fw->data[1];
+ csum = cyapa_gen3_csum(>data[2], CYAPA_FW_HDR_SIZE - 2);
+ if (csum != csum_expected) {
+ dev_err(dev, "%s %04x, expected: %04x\n",
+
[PATCH v17 07/12] input: cyapa: add gen3 trackpad device read baseline function support
Add read baseline function supported for gen3 trackpad device,
it can be used through sysfs baseline interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen3.c | 72
1 file changed, 72 insertions(+)
diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
index 715abda..0cb52fa 100644
--- a/drivers/input/mouse/cyapa_gen3.c
+++ b/drivers/input/mouse/cyapa_gen3.c
@@ -765,6 +765,76 @@ static int cyapa_gen3_do_fw_update(struct cyapa *cyapa,
return 0;
}
+static ssize_t cyapa_gen3_show_baseline(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ int max_baseline, min_baseline;
+ int tries;
+ int ret;
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_DEV_STATUS);
+ if (ret < 0) {
+ dev_err(dev, "Error reading dev status. err = %d\n", ret);
+ goto out;
+ }
+ if ((ret & CYAPA_DEV_NORMAL) != CYAPA_DEV_NORMAL) {
+ dev_warn(dev, "Trackpad device is busy. device state = 0x%x\n",
+ret);
+ ret = -EAGAIN;
+ goto out;
+ }
+
+ ret = cyapa_write_byte(cyapa, CYAPA_CMD_SOFT_RESET,
+ OP_REPORT_BASELINE_MASK);
+ if (ret < 0) {
+ dev_err(dev, "Failed to send report baseline command. %d\n",
+ ret);
+ goto out;
+ }
+
+ tries = 3; /* Try for 30 to 60 ms */
+ do {
+ usleep_range(1, 2);
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_DEV_STATUS);
+ if (ret < 0) {
+ dev_err(dev, "Error reading dev status. err = %d\n",
+ ret);
+ goto out;
+ }
+ if ((ret & CYAPA_DEV_NORMAL) == CYAPA_DEV_NORMAL)
+ break;
+ } while (--tries);
+
+ if (tries == 0) {
+ dev_err(dev, "Device timed out going to Normal state.\n");
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_MAX_BASELINE);
+ if (ret < 0) {
+ dev_err(dev, "Failed to read max baseline. err = %d\n", ret);
+ goto out;
+ }
+ max_baseline = ret;
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_MIN_BASELINE);
+ if (ret < 0) {
+ dev_err(dev, "Failed to read min baseline. err = %d\n", ret);
+ goto out;
+ }
+ min_baseline = ret;
+
+ dev_dbg(dev, "Baseline report successful. Max: %d Min: %d\n",
+ max_baseline, min_baseline);
+ ret = scnprintf(buf, PAGE_SIZE, "%d %d\n", max_baseline, min_baseline);
+
+out:
+ return ret;
+}
+
/*
* cyapa_get_wait_time_for_pwr_cmd
*
@@ -1086,6 +1156,8 @@ const struct cyapa_dev_ops cyapa_gen3_ops = {
.bl_deactivate = cyapa_gen3_bl_deactivate,
.bl_initiate = cyapa_gen3_bl_initiate,
+ .show_baseline = cyapa_gen3_show_baseline,
+
.initialize = cyapa_gen3_initialize,
.state_parse = cyapa_gen3_state_parse,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v17 05/12] input: cyapa: add sysfs interfaces support in the cyapa driver
Add device's basic control and features supported in cyapa driver through
sysfs file system interfaces. These interfaces are commonly used in
pre- and after production, for trackpad device state checking, managing
and firmware image updating.
These interfaces including mode, firmware_version and product_id interfaces
for reading firmware version and trackpad device product id values,
and including update_fw interface to command firmware image update
process. Also including baseline and calibrate interfaces for
reading and checking trackpad device's sensors states.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 302
1 file changed, 302 insertions(+)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 080b93f..e4d1a4d 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -32,6 +32,8 @@
#define CYAPA_ADAPTER_FUNC_SMBUS 2
#define CYAPA_ADAPTER_FUNC_BOTH 3
+#define CYAPA_FW_NAME "cyapa.bin"
+
const char product_id[] = "CYTRA";
static int cyapa_reinitialize(struct cyapa *cyapa);
@@ -475,6 +477,29 @@ static int cyapa_create_input_dev(struct cyapa *cyapa)
return 0;
}
+static void cyapa_enable_irq_for_cmd(struct cyapa *cyapa)
+{
+ struct input_dev *input = cyapa->input;
+
+ if (!input || !input->users) {
+ if (cyapa->operational)
+ cyapa->ops->set_power_mode(cyapa,
+ PWR_MODE_FULL_ACTIVE, 0);
+ enable_irq(cyapa->client->irq);
+ }
+}
+
+static void cyapa_disable_irq_for_cmd(struct cyapa *cyapa)
+{
+ struct input_dev *input = cyapa->input;
+
+ if (!input || !input->users) {
+ disable_irq(cyapa->client->irq);
+ if (cyapa->operational)
+ cyapa->ops->set_power_mode(cyapa, PWR_MODE_OFF, 0);
+ }
+}
+
/*
* cyapa_sleep_time_to_pwr_cmd and cyapa_pwr_cmd_to_sleep_time
*
@@ -858,6 +883,270 @@ static int cyapa_start_runtime(struct cyapa *cyapa)
static inline int cyapa_start_runtime(struct cyapa *cyapa) { return 0; }
#endif /* CONFIG_PM_RUNTIME */
+static ssize_t cyapa_show_fm_ver(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ int error;
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ error = scnprintf(buf, PAGE_SIZE, "%d.%d\n", cyapa->fw_maj_ver,
+cyapa->fw_min_ver);
+ mutex_unlock(>state_sync_lock);
+ return error;
+}
+
+static ssize_t cyapa_show_product_id(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ int size;
+ int error;
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ size = scnprintf(buf, PAGE_SIZE, "%s\n", cyapa->product_id);
+ mutex_unlock(>state_sync_lock);
+ return size;
+}
+
+static int cyapa_firmware(struct cyapa *cyapa, const char *fw_name)
+{
+ struct device *dev = >client->dev;
+ const struct firmware *fw;
+ int error;
+
+ error = request_firmware(, fw_name, dev);
+ if (error) {
+ dev_err(dev, "Could not load firmware from %s: %d\n",
+ fw_name, error);
+ return error;
+ }
+
+ error = cyapa->ops->check_fw(cyapa, fw);
+ if (error) {
+ dev_err(dev, "Invalid CYAPA firmware image: %s\n",
+ fw_name);
+ goto done;
+ }
+
+ /*
+* Resume the potentially suspended device because doing FW
+* update on a device not in the FULL mode has a chance to
+* fail.
+*/
+ pm_runtime_get_sync(dev);
+
+ /* Require IRQ support for firmware update commands. */
+ cyapa_enable_irq_for_cmd(cyapa);
+
+ error = cyapa->ops->bl_enter(cyapa);
+ if (error) {
+ dev_err(dev, "bl_enter failed, %d\n", error);
+ goto err_detect;
+ }
+
+ error = cyapa->ops->bl_activate(cyapa);
+ if (error) {
+ dev_err(dev, "bl_activate failed, %d\n", error);
+ goto err_detect;
+ }
+
+ error = cyapa->ops->bl_initiate(cyapa, fw);
+ if (error) {
+ dev_err(dev, "bl_initiate failed, %d\n", error);
+ goto err_detect;
+ }
+
+ error = cyapa->ops->update_fw(cyapa, fw);
+ if (error) {
+ dev_err(dev, "update_fw failed, %d\n", error);
+ goto err_detect;
+ }
+
+err_detect:
+ cyapa_disable_irq_for_cmd(cyapa);
+ pm_runtime_put_noidle(dev);
+
+done:
+ release_firmware(fw);
+ return error;
+}
+
+static ssize_t
[PATCH v17 00/12] input: cyapa: instruction of cyapa patches
V17 patches have below updates, details of other updates see history list: 1) Fix kernel oops when system booting up with finger on TP. 2) Remove unnecessary error log that may to system. 3) Slipt out pm sleep code into cyapa_prepare_wakeup_controls(), remove #indefs in function body of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME. 4) Supply stubs to cyapa_gen3_ops and cyapa_gen5_ops data structure to avoid checking for presence of various methods in ops. 5) Changing CYAPA_BOOTLOADER() and CYAPA_OPERATIONAL() macros to static inline functions as cyapa_is_bootloader_mode() and cyapa_is_operational_mode(). 6) Remove touching runtime suspend state during system calling cyapa_suspend(). 7) Change to enable runtime PM until make sure device is out of bootloader. 8) Change to return -EAGAIN when bootloader is busy. 9) Correct word spell issue and code styles. This patch series is aimed to re-design the cyapa driver to support old gen3 trackpad devices and new gen5 trackpad devices in one cyapa driver, it's for easily productions support based on customers' requirements. And add sysfs functions and interfaces supported that required by users and customers. Since the earlier gen3 and the latest gen5 trackpad devices using two different chipsets, and have different protocols and interfaces, so if supported these two type trackpad devices in two different drivers, then it will be difficult to manage productions and later firmware updates. e.g.: It will cause customer don't know which one trackpad device firmware image to use and update when it has been used and integrated in same one productions, so here we support these two trackpad devices in same on driver. Dudley Du (12): input: cyapa: re-design driver to support multi-trackpad in one driver input: cyapa: add gen5 trackpad device basic functions support input: cyapa: add power management interfaces support for the device input: cyapa: add runtime power management interfaces support for the device input: cyapa: add sysfs interfaces support in the cyapa driver input: cyapa: add gen3 trackpad device firmware update function support input: cyapa: add gen3 trackpad device read baseline function support input: cyapa: add gen3 trackpad device force re-calibrate function support input: cyapa: add gen5 trackpad device firmware update function support input: cyapa: add gen5 trackpad device read baseline function support input: cyapa: add gen5 trackpad device force re-calibrate function support input: cyapa: add acpi device id support drivers/input/mouse/Kconfig |1 + drivers/input/mouse/Makefile |3 +- drivers/input/mouse/cyapa.c | 1701 ++- drivers/input/mouse/cyapa.h | 303 + drivers/input/mouse/cyapa_gen3.c | 1229 + drivers/input/mouse/cyapa_gen5.c | 2773 ++ 6 files changed, 5348 insertions(+), 662 deletions(-) create mode 100644 drivers/input/mouse/cyapa.h create mode 100644 drivers/input/mouse/cyapa_gen3.c create mode 100644 drivers/input/mouse/cyapa_gen5.c History patch series modifications list: V16 patches have below main updates compared with v15 patches: 1) Fix all miss-spelling and space issue. 2) Rename variables and functions with much more clearer names. 3) Initialize and document tries near where it will be used. 4) Modify cmd buffer to struct for more descriptive way. V15 patches have below main updates compared with v14 patches: 1) Fix all warning errors of sparse tool when running with "make C=1". 2) Change variable name "unique_str" to "product_id" for clearer meanings. 3) Update cyapa_i2c_write function to return error directly when length > 31. V14 patches have below main updates compared with v13 patches: 1) Correct 9 miss spelling issues of "bufferred" to "buffered". 2) Fix the upgrade issue of removing MOUSE_CYAPA config when make oldconfig by replase "depends on I2C && CRC_ITU_T" with "depends on I2C" "select CRC_ITU_T" in patch 9. V13 patches have below main updates compared with v12 patches: 1) Remove all debugfs interface, including read_fw and raw_data interfaces. 2) This patches are made based linux next-20141208. V12 patches have below main updates compared with v11 patches: 1) Add check that when TP is detected but not operational, do not exit driver immediately, but wait and export the update_fw interface for recovering. 2) Re-arrange the function codes, remove unnesseary protype definitions in the header file. V11 patches have below main updates compared with v10 patches: 1) Add add acpi device id supported for old gen3 and new gen5 trackpad devices. 2) Fix the unable to update firmware issue when cyapa_open is not called which means the irq for firwmare update process is not enabled. This fix by checking if the irq is enabled, if not then enable irq before start to do firmware update. V10 patches have below main updates compared with
[PATCH v17 09/12] input: cyapa: add gen5 trackpad device firmware update function support
Add firmware image update function supported for gen5 trackpad device,
it can be used through sysfs update_fw interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/Kconfig | 1 +
drivers/input/mouse/cyapa_gen5.c | 390 +++
2 files changed, 391 insertions(+)
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index d8b46b0..728490e 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -206,6 +206,7 @@ config MOUSE_BCM5974
config MOUSE_CYAPA
tristate "Cypress APA I2C Trackpad support"
depends on I2C
+ select CRC_ITU_T
help
This driver adds support for Cypress All Points Addressable (APA)
I2C Trackpads, including the ones used in 2012 Samsung Chromebooks.
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index a049ae3..6c27b4e 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "cyapa.h"
@@ -264,6 +265,79 @@ struct cyapa_gen5_report_data {
struct cyapa_gen5_touch_record touch_records[10];
} __packed;
+struct cyapa_tsg_bin_image_head {
+ u8 head_size; /* Unit: bytes, including itself. */
+ u8 ttda_driver_major_version; /* Reserved as 0. */
+ u8 ttda_driver_minor_version; /* Reserved as 0. */
+ u8 fw_major_version;
+ u8 fw_minor_version;
+ u8 fw_revision_control_number[8];
+} __packed;
+
+struct cyapa_tsg_bin_image_data_record {
+ u8 flash_array_id;
+ __be16 row_number;
+ /* The number of bytes of flash data contained in this record. */
+ __be16 record_len;
+ /* The flash program data. */
+ u8 record_data[CYAPA_TSG_FW_ROW_SIZE];
+} __packed;
+
+struct cyapa_tsg_bin_image {
+ struct cyapa_tsg_bin_image_head image_head;
+ struct cyapa_tsg_bin_image_data_record records[0];
+} __packed;
+
+struct gen5_bl_packet_start {
+ u8 sop; /* Start of packet, must be 01h */
+ u8 cmd_code;
+ __le16 data_length; /* Size of data parameter start from data[0] */
+} __packed;
+
+struct gen5_bl_packet_end {
+ __le16 crc;
+ u8 eop; /* End of packet, must be 17h */
+} __packed;
+
+struct gen5_bl_cmd_head {
+ __le16 addr; /* Output report register address, must be 0004h */
+ /* Size of packet not including output report register address */
+ __le16 length;
+ u8 report_id; /* Bootloader output report id, must be 40h */
+ u8 rsvd; /* Reserved, must be 0 */
+ struct gen5_bl_packet_start packet_start;
+ u8 data[0]; /* Command data variable based on commands */
+} __packed;
+
+/* Initiate bootload command data structure. */
+struct gen5_bl_initiate_cmd_data {
+ /* Key must be "A5h 01h 02h 03h FFh FEh FDh 5Ah" */
+ u8 key[CYAPA_TSG_BL_KEY_SIZE];
+ u8 metadata_raw_parameter[CYAPA_TSG_FLASH_MAP_METADATA_SIZE];
+ __le16 metadata_crc;
+} __packed;
+
+struct gen5_bl_metadata_row_params {
+ __le16 size;
+ __le16 maximun_size;
+ __le32 app_start;
+ __le16 app_len;
+ __le16 app_crc;
+ __le32 app_entry;
+ __le32 upgrade_start;
+ __le16 upgrade_len;
+ __le16 entry_row_crc;
+ u8 padding[36]; /* Padding data must be 0 */
+ __le16 metadata_crc; /* CRC starts at offset of 60 */
+} __packed;
+
+/* Bootload program and verify row command data structure */
+struct gen5_bl_flash_row_head {
+ u8 flash_array_id;
+ __le16 flash_row_id;
+ u8 flash_data[0];
+} __packed;
+
struct gen5_app_cmd_head {
__le16 addr; /* Output report register address, must be 0004h */
/* Size of packet not including output report register address */
@@ -297,6 +371,10 @@ struct gen5_app_get_parameter_data {
#define GEN5_DEV_UNINIT_SLEEP_TIME(cyapa) \
(((cyapa)->dev_sleep_time) == UNINIT_SLEEP_TIME)
+
+static u8 cyapa_gen5_bl_cmd_key[] = { 0xa5, 0x01, 0x02, 0x03,
+ 0xff, 0xfe, 0xfd, 0x5a };
+
static int cyapa_gen5_initialize(struct cyapa *cyapa)
{
struct cyapa_gen5_cmd_states *gen5_pip = >cmd_states.gen5;
@@ -618,6 +696,22 @@ static bool cyapa_gen5_sort_tsg_pip_app_resp_data(struct
cyapa *cyapa,
return false;
}
+static bool cyapa_gen5_sort_application_launch_data(struct cyapa *cyapa,
+ u8 *buf, int len)
+{
+ if (buf == NULL || len < GEN5_RESP_LENGTH_SIZE)
+ return false;
+
+ /*
+* After reset or power on, trackpad device always sets to 0x00 0x00
+* to indicate a reset or power on event.
+*/
+ if (buf[0] == 0 && buf[1] == 0)
+ return true;
+
+ return false;
+}
+
static bool cyapa_gen5_sort_hid_descriptor_data(struct cyapa *cyapa,
u8 *buf, int len)
{
@@ -923,6 +1017,80 @@ static int cyapa_gen5_state_parse(struct cyapa
[PATCH v17 08/12] input: cyapa: add gen3 trackpad device force re-calibrate function support
Add force re-calibrate function supported for gen3 trackpad device,
it can be used through sysfs calibrate interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen3.c | 59
1 file changed, 59 insertions(+)
diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
index 0cb52fa..c23b644 100644
--- a/drivers/input/mouse/cyapa_gen3.c
+++ b/drivers/input/mouse/cyapa_gen3.c
@@ -765,6 +765,64 @@ static int cyapa_gen3_do_fw_update(struct cyapa *cyapa,
return 0;
}
+static ssize_t cyapa_gen3_do_calibrate(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ int tries;
+ int ret;
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_DEV_STATUS);
+ if (ret < 0) {
+ dev_err(dev, "Error reading dev status: %d\n", ret);
+ goto out;
+ }
+ if ((ret & CYAPA_DEV_NORMAL) != CYAPA_DEV_NORMAL) {
+ dev_warn(dev, "Trackpad device is busy, device state: 0x%02x\n",
+ret);
+ ret = -EAGAIN;
+ goto out;
+ }
+
+ ret = cyapa_write_byte(cyapa, CYAPA_CMD_SOFT_RESET,
+ OP_RECALIBRATION_MASK);
+ if (ret < 0) {
+ dev_err(dev, "Failed to send calibrate command: %d\n",
+ ret);
+ goto out;
+ }
+
+ tries = 20; /* max recalibration timeout 2s. */
+ do {
+ /*
+* For this recalibration, the max time will not exceed 2s.
+* The average time is approximately 500 - 700 ms, and we
+* will check the status every 100 - 200ms.
+*/
+ usleep_range(10, 20);
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_DEV_STATUS);
+ if (ret < 0) {
+ dev_err(dev, "Error reading dev status: %d\n",
+ ret);
+ goto out;
+ }
+ if ((ret & CYAPA_DEV_NORMAL) == CYAPA_DEV_NORMAL)
+ break;
+ } while (--tries);
+
+ if (tries == 0) {
+ dev_err(dev, "Failed to calibrate. Timeout.\n");
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+ dev_dbg(dev, "Calibration successful.\n");
+
+out:
+ return ret < 0 ? ret : count;
+}
+
static ssize_t cyapa_gen3_show_baseline(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -1157,6 +1215,7 @@ const struct cyapa_dev_ops cyapa_gen3_ops = {
.bl_initiate = cyapa_gen3_bl_initiate,
.show_baseline = cyapa_gen3_show_baseline,
+ .calibrate_store = cyapa_gen3_do_calibrate,
.initialize = cyapa_gen3_initialize,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v17 12/12] input: cyapa: add acpi device id support
Add acpi device tree support.
acpi device id "CYAP" is for old gen3 trackpad devices.
acpi device id "CYAP0001" is for new gen5 trackpad devices.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index e4d1a4d..fd63681 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "cyapa.h"
@@ -1344,11 +1345,23 @@ static const struct i2c_device_id cyapa_id_table[] = {
};
MODULE_DEVICE_TABLE(i2c, cyapa_id_table);
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id cyapa_acpi_id[] = {
+ { "CYAP", 0 }, /* Gen3 trackpad with 0x67 I2C address. */
+ { "CYAP0001", 0 }, /* Gen5 trackpad with 0x24 I2C address. */
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, cyapa_acpi_id);
+#endif
+
static struct i2c_driver cyapa_driver = {
.driver = {
.name = "cyapa",
.owner = THIS_MODULE,
.pm = _pm_ops,
+#ifdef CONFIG_ACPI
+ .acpi_match_table = ACPI_PTR(cyapa_acpi_id),
+#endif
},
.probe = cyapa_probe,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v17 11/12] input: cyapa: add gen5 trackpad device force re-calibrate function support
Add force re-calibrate function supported for gen5 trackpad device,
it can be used through sysfs calibrate interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen5.c | 65
1 file changed, 65 insertions(+)
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index 94d7da9..fa660d3 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -1714,6 +1714,70 @@ static int cyapa_gen5_suspend_scanning(struct cyapa
*cyapa)
return 0;
}
+static int cyapa_gen5_calibrate_pwcs(struct cyapa *cyapa,
+ u8 calibrate_sensing_mode_type)
+{
+ struct gen5_app_cmd_head *app_cmd_head;
+ u8 cmd[8];
+ u8 resp_data[6];
+ int resp_len;
+ int error;
+
+ /* Try to dump all buffered data before doing command. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ memset(cmd, 0, sizeof(cmd));
+ app_cmd_head = (struct gen5_app_cmd_head *)cmd;
+ put_unaligned_le16(GEN5_OUTPUT_REPORT_ADDR, _cmd_head->addr);
+ put_unaligned_le16(sizeof(cmd) - 2, _cmd_head->length);
+ app_cmd_head->report_id = GEN5_APP_CMD_REPORT_ID;
+ app_cmd_head->cmd_code = GEN5_CMD_CALIBRATE;
+ app_cmd_head->parameter_data[0] = calibrate_sensing_mode_type;
+ resp_len = sizeof(resp_data);
+ error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
+ cmd, sizeof(cmd),
+ resp_data, _len,
+ 5000, cyapa_gen5_sort_tsg_pip_app_resp_data, true);
+ if (error || !VALID_CMD_RESP_HEADER(resp_data, GEN5_CMD_CALIBRATE) ||
+ !GEN5_CMD_COMPLETE_SUCCESS(resp_data[5]))
+ return error < 0 ? error : -EAGAIN;
+
+ return 0;
+}
+
+static ssize_t cyapa_gen5_do_calibrate(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ int error, calibrate_error;
+
+ /* 1. Suspend Scanning*/
+ error = cyapa_gen5_suspend_scanning(cyapa);
+ if (error)
+ return error;
+
+ /* 2. Do mutual capacitance fine calibrate. */
+ calibrate_error = cyapa_gen5_calibrate_pwcs(cyapa,
+ CYAPA_SENSING_MODE_MUTUAL_CAP_FINE);
+ if (calibrate_error)
+ goto resume_scanning;
+
+ /* 3. Do self capacitance calibrate. */
+ calibrate_error = cyapa_gen5_calibrate_pwcs(cyapa,
+ CYAPA_SENSING_MODE_SELF_CAP);
+ if (calibrate_error)
+ goto resume_scanning;
+
+resume_scanning:
+ /* 4. Resume Scanning*/
+ error = cyapa_gen5_resume_scanning(cyapa);
+ if (error || calibrate_error)
+ return error ? error : calibrate_error;
+
+ return count;
+}
+
static s32 twos_complement_to_s32(s32 value, int num_bits)
{
if (value >> (num_bits - 1))
@@ -2695,6 +2759,7 @@ const struct cyapa_dev_ops cyapa_gen5_ops = {
.bl_deactivate = cyapa_gen5_bl_deactivate,
.show_baseline = cyapa_gen5_show_baseline,
+ .calibrate_store = cyapa_gen5_do_calibrate,
.initialize = cyapa_gen5_initialize,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v17 10/12] input: cyapa: add gen5 trackpad device read baseline function support
Add read baseline function supported for gen5 trackpad device,
it can be used through sysfs baseline interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.h | 2 +
drivers/input/mouse/cyapa_gen5.c | 640 +++
2 files changed, 642 insertions(+)
diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
index f5a2c22..fb3b863 100644
--- a/drivers/input/mouse/cyapa.h
+++ b/drivers/input/mouse/cyapa.h
@@ -265,6 +265,8 @@ struct cyapa {
u8 y_origin; /* Y Axis Origin: 0 = top; 1 = bottom. */
int electrodes_x; /* Number of electrodes on the X Axis*/
int electrodes_y; /* Number of electrodes on the Y Axis*/
+ int electrodes_rx; /* Number of Rx electrodes */
+ int aligned_electrodes_rx; /* 4 aligned */
int max_z;
/*
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index 6c27b4e..94d7da9 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -363,6 +363,12 @@ struct gen5_app_get_parameter_data {
u8 parameter_id;
} __packed;
+struct gen5_retrieve_panel_scan_data {
+ __le16 read_offset;
+ __le16 read_elements;
+ u8 data_id;
+} __packed;
+
/* Variables to record latest gen5 trackpad power states. */
#define GEN5_DEV_SET_PWR_STATE(cyapa, s) ((cyapa)->dev_pwr_mode = (s))
#define GEN5_DEV_GET_PWR_STATE(cyapa) ((cyapa)->dev_pwr_mode)
@@ -1660,6 +1666,638 @@ static int cyapa_gen5_set_power_mode(struct cyapa
*cyapa,
return 0;
}
+static int cyapa_gen5_resume_scanning(struct cyapa *cyapa)
+{
+ u8 cmd[] = { 0x04, 0x00, 0x05, 0x00, 0x2f, 0x00, 0x04 };
+ u8 resp_data[6];
+ int resp_len;
+ int error;
+
+ /* Try to dump all buffered data before doing command. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ resp_len = sizeof(resp_data);
+ error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
+ cmd, sizeof(cmd),
+ resp_data, _len,
+ 500, cyapa_gen5_sort_tsg_pip_app_resp_data, true);
+ if (error || !VALID_CMD_RESP_HEADER(resp_data, 0x04))
+ return -EINVAL;
+
+ /* Try to dump all buffered data when resuming scanning. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ return 0;
+}
+
+static int cyapa_gen5_suspend_scanning(struct cyapa *cyapa)
+{
+ u8 cmd[] = { 0x04, 0x00, 0x05, 0x00, 0x2f, 0x00, 0x03 };
+ u8 resp_data[6];
+ int resp_len;
+ int error;
+
+ /* Try to dump all buffered data before doing command. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ resp_len = sizeof(resp_data);
+ error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
+ cmd, sizeof(cmd),
+ resp_data, _len,
+ 500, cyapa_gen5_sort_tsg_pip_app_resp_data, true);
+ if (error || !VALID_CMD_RESP_HEADER(resp_data, 0x03))
+ return -EINVAL;
+
+ /* Try to dump all buffered data when suspending scanning. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ return 0;
+}
+
+static s32 twos_complement_to_s32(s32 value, int num_bits)
+{
+ if (value >> (num_bits - 1))
+ value |= -1 << num_bits;
+ return value;
+}
+
+static s32 cyapa_parse_structure_data(u8 data_format, u8 *buf, int buf_len)
+{
+ int data_size;
+ bool big_endian;
+ bool unsigned_type;
+ s32 value;
+
+ data_size = (data_format & 0x07);
+ big_endian = ((data_format & 0x10) == 0x00);
+ unsigned_type = ((data_format & 0x20) == 0x00);
+
+ if (buf_len < data_size)
+ return 0;
+
+ switch (data_size) {
+ case 1:
+ value = buf[0];
+ break;
+ case 2:
+ if (big_endian)
+ value = get_unaligned_be16(buf);
+ else
+ value = get_unaligned_le16(buf);
+ break;
+ case 4:
+ if (big_endian)
+ value = get_unaligned_be32(buf);
+ else
+ value = get_unaligned_le32(buf);
+ break;
+ default:
+ /* Should not happen, just as default case here. */
+ value = 0;
+ break;
+ }
+
+ if (!unsigned_type)
+ value = twos_complement_to_s32(value, data_size * 8);
+
+ return value;
+}
+
+static void cyapa_gen5_guess_electrodes(struct cyapa *cyapa,
+ int *electrodes_rx, int *electrodes_tx)
+{
+ if (cyapa->electrodes_rx != 0) {
+ *electrodes_rx = cyapa->electrodes_rx;
+ *electrodes_tx = (cyapa->electrodes_x == *electrodes_rx) ?
+ cyapa->electrodes_y : cyapa->electrodes_x;
+ } else {
+
Re: [PATCH 2/3] mm: cma: introduce /proc/cmainfo
2014-12-29 오후 11:09에 Stefan Strogin 이(가) 쓴 글:
Thanks for review Michał,
On 12/26/2014 07:02 PM, Michal Nazarewicz wrote:
On Fri, Dec 26 2014, "Stefan I. Strogin" wrote:
/proc/cmainfo contains a list of currently allocated CMA buffers for every
CMA area when CONFIG_CMA_DEBUG is enabled.
Format is:
- ( kB), allocated by \
(), latency us
Signed-off-by: Stefan I. Strogin
---
mm/cma.c | 202 +++
1 file changed, 202 insertions(+)
diff --git a/mm/cma.c b/mm/cma.c
index a85ae28..ffaea26 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -347,6 +372,86 @@ err:
return ret;
}
+#ifdef CONFIG_CMA_DEBUG
+/**
+ * cma_buffer_list_add() - add a new entry to a list of allocated buffers
+ * @cma: Contiguous memory region for which the allocation is performed.
+ * @pfn: Base PFN of the allocated buffer.
+ * @count: Number of allocated pages.
+ * @latency: Nanoseconds spent to allocate the buffer.
+ *
+ * This function adds a new entry to the list of allocated contiguous memory
+ * buffers in a CMA area. It uses the CMA area specificated by the device
+ * if available or the default global one otherwise.
+ */
+static int cma_buffer_list_add(struct cma *cma, unsigned long pfn,
+ int count, s64 latency)
+{
+struct cma_buffer *cmabuf;
+struct stack_trace trace;
+
+cmabuf = kmalloc(sizeof(struct cma_buffer), GFP_KERNEL);
cmabuf = kmalloc(sizeof *cmabuf, GFP_KERNEL);
cmabuf = kmalloc(sizeof(*cmabuf), GFP_KERNEL);
+if (!cmabuf)
+return -ENOMEM;
+
+trace.nr_entries = 0;
+trace.max_entries = ARRAY_SIZE(cmabuf->trace_entries);
+trace.entries = >trace_entries[0];
+trace.skip = 2;
+save_stack_trace();
+
+cmabuf->pfn = pfn;
+cmabuf->count = count;
+cmabuf->pid = task_pid_nr(current);
+cmabuf->nr_entries = trace.nr_entries;
+get_task_comm(cmabuf->comm, current);
+cmabuf->latency = (unsigned int) div_s64(latency, NSEC_PER_USEC);
+
+mutex_lock(>list_lock);
+list_add_tail(>list, >buffers_list);
+mutex_unlock(>list_lock);
+
+return 0;
+}
Is it ok if the information is too big?
I'm not sure but I remember that seq_printf has 4K limitation.
So I made seq_operations with seq_list_start/next functions.
EX)
static void *debug_seq_start(struct seq_file *s, loff_t *pos)
{
» mutex_lock(_lock);
» return seq_list_start(_list, *pos);
}
static void debug_seq_stop(struct seq_file *s, void *data)
{
» struct debug_header *header = data;
» if (header == NULL || >head_list == _list) {
» » seq_printf(s, "end of info");
» }
» mutex_unlock(_lock);
}
static void *debug_seq_next(struct seq_file *s, void *data, loff_t *pos)
{
» return seq_list_next(data, _list, pos);
}
static int debug_seq_show(struct seq_file *sfile, void *data)
{
» struct debug_header *header;
» char *p;
» header= list_entry(data,
» » » struct debug_header,
» » » head_list);
» seq_printf(sfile, "print info");
» return 0;
}
static const struct seq_operations debug_seq_ops = {
» .start = debug_seq_start,
» .next = debug_seq_next,
» .stop = debug_seq_stop,
» .show = debug_seq_show,
};
You do not have guarantee that CMA deallocations will match allocations
exactly. User may allocate CMA region and then free it chunks. I'm not
saying that the debug code must handle than case but at least I would
like to see a comment describing this shortcoming.
Thanks, I'll fix it. If a number of released pages is less than there
were allocated then the list entry shouldn't be deleted, but it's fields
should be updated.
@@ -361,11 +466,15 @@ struct page *cma_alloc(struct cma *cma, int count,
unsigned int align)
unsigned long mask, offset, pfn, start = 0;
unsigned long bitmap_maxno, bitmap_no, bitmap_count;
struct page *page = NULL;
+struct timespec ts1, ts2;
+s64 latency;
int ret;
if (!cma || !cma->count)
return NULL;
+getnstimeofday();
+
If CMA_DEBUG is disabled, you waste time on measuring latency. Either
use #ifdef or IS_ENABLED, e.g.:
if (IS_ENABLED(CMA_DEBUG))
getnstimeofday();
Obviously! :)
@@ -413,6 +522,19 @@ struct page *cma_alloc(struct cma *cma, int count,
unsigned int align)
start = bitmap_no + mask + 1;
}
+getnstimeofday();
+latency = timespec_to_ns() - timespec_to_ns();
+
+if (page) {
if (IS_ENABLED(CMA_DEBUG) && page) {
getnstimeofday();
latency = timespec_to_ns() - timespec_to_ns();
+ret = cma_buffer_list_add(cma, pfn, count, latency);
You could also change cma_buffer_list_add to take ts1 as an argument
instead of latency and then latency calculating would be hidden inside
of that function. Initialising ts1 should still be guarded with
IS_ENABLED of course.
Re: [PATCH 0/3] mm: cma: /proc/cmainfo
2014-12-30 오후 1:47에 Minchan Kim 이(가) 쓴 글: On Mon, Dec 29, 2014 at 11:52:58AM -0800, Laura Abbott wrote: On 12/28/2014 6:36 PM, Minchan Kim wrote: Hello, On Fri, Dec 26, 2014 at 05:39:01PM +0300, Stefan I. Strogin wrote: Hello all, Here is a patch set that adds /proc/cmainfo. When compiled with CONFIG_CMA_DEBUG /proc/cmainfo will contain information about about total, used, maximum free contiguous chunk and all currently allocated contiguous buffers in CMA regions. The information about allocated CMA buffers includes pid, comm, allocation latency and stacktrace at the moment of allocation. It just says what you are doing but you didn't say why we need it. I can guess but clear description(ie, the problem what you want to solve with this patchset) would help others to review, for instance, why we need latency, why we need callstack, why we need new wheel rather than ftrace and so on. Thanks. I've been meaning to write something like this for a while so I'm happy to see an attempt made to fix this. I can't speak for the author's reasons for wanting this information but there are several reasons why I was thinking of something similar. The most common bug reports seen internally on CMA are 1) CMA is too slow and 2) CMA failed to allocate memory. For #1, not all allocations may be slow so it's useful to be able to keep track of which allocations are taking too long. For #2, migration Then, I don't think we could keep all of allocations. What we need is only slow allocations. I hope we can do that with ftrace. ex) # cd /sys/kernel/debug/tracing # echo 1 > options/stacktrace # echo cam_alloc > set_ftrace_filter # echo your_threshold > tracing_thresh I know it doesn't work now but I think it's more flexible and general way to handle such issues(ie, latency of some functions). So, I hope we could enhance ftrace rather than new wheel. Ccing ftrace people. For CMA performance test or code flow check, ftrace is better. ex) echo cma_alloc > /sys/kernel/debug/tracing/set_graph_function echo function_graph > /sys/kernel/debug/tracing/current_tracer echo funcgraph-proc > /sys/kernel/debug/tracing/trace_options echo nosleep-time > /sys/kernel/debug/tracing/trace_options echo funcgraph-tail > /sys/kernel/debug/tracing/trace_options echo 1 > /sys/kernel/debug/tracing/tracing_on This can trace every cam_alloc and allocation time. I think ftrace is better to debug latency. If a buffer had allocated and had peak latency and freed, we can check it. But ftrace doesn't provide current status how many buffers we have and what address it is. So I think debugging information is useful. Futhermore, if we really need to have such information, we need more data (ex, how many of pages were migrated out, how many pages were dropped without migrated, how many pages were written back, how many pages were retried with the page lock and so on). In this case, event trace would be better. failure is fairly common but it's still important to rule out a memory leak from a dma client. Seeing all the allocations is also very useful for memory tuning (e.g. how big does the CMA region need to be, which clients are actually allocating memory). Memory leak is really general problem and could we handle it with page_owner? ftrace is certainly usable for tracing CMA allocation callers and latency. ftrace is still only a fixed size buffer though so it's possible for information to be lost if other logging is enabled. Sorry, I don't get with only above reasons why we need this. :( For most of the CMA use cases, there is a very high cost if the proper debugging information is not available so the more that can be guaranteed the better. It's also worth noting that the SLUB allocator has a sysfs interface for showing allocation callers when CONFIG_SLUB_DEBUG is enabled. Thanks, Laura -- Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
lk3.19.0-rc2: no cfg80211 wireless extensions compatibility
Was there a good reason for this change in net/wireless/Kconfig between lk 3.18 and 3.19-rc2 ?? --- /tmp/Kconfig2014-12-25 13:46:28.802185089 -0500 +++ ./Kconfig 2014-12-30 18:08:15.539337145 -0500 @@ -175,7 +175,7 @@ Most distributions have a CRDA package. So if unsure, say N. config CFG80211_WEXT - bool "cfg80211 wireless extensions compatibility" + bool depends on CFG80211 select WEXT_CORE help That change makes it pretty hard for folks who need those extensions. Doug Gilbert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ARM: dts: sun9i: Allwinner A80 dtsi - missing clock-frequency property
When booting Linux 3.19-rc2 on a Merrii Optimusboard using arch/arm/boot/dts/sun9i-a80-optimus.dts adn arch/arm/boot/dts/sun9i-a80.dtsi I get errors [0.061192] /cpus/cpu@0 missing clock-frequency property [0.061209] /cpus/cpu@1 missing clock-frequency property [0.061223] /cpus/cpu@2 missing clock-frequency property [0.061237] /cpus/cpu@3 missing clock-frequency property [0.061251] /cpus/cpu@100 missing clock-frequency property [0.061266] /cpus/cpu@101 missing clock-frequency property [0.061283] /cpus/cpu@102 missing clock-frequency property [0.061300] /cpus/cpu@103 missing clock-frequency property The dtsi was provided by patch https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4ab328f06e305bf3ea254f4e3c94bb4d820998c1 According to file pack/chips/sun9iw1p1/optimus/sys_config.fex supplied in the OptimusBoard SDK the big cluster can run at up to 1800 MHz, and the LITTLE cluster can run at up to 1200 MHz,depending on the CPU voltage: big 1.08V (1608Mhz, 1800Mhz] 1.00V (1536Mhz, 1608Mhz] 0.96V (1440Mhz, 1536Mhz] 0.90V (1296Mhz, 1440Mhz] 0.84V ( 0Mhz, 1296Mhz] LITTLE 1.02V (1128Mhz, 1200Mhz] 0.96V (1008Mhz, 1128Mhz] 0.90V ( 864Mhz, 1008Mhz] 0.84V ( 0Mhz, 864Mhz] I guess the proper way to specify the data is the one described in Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt Other boards might run at other frequencies. Hence we might want to put this information into the board file arch/arm/boot/dts/sun9i-a80-optimus.dts. Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt, arch/arm/boot/dts/exynos5260.dtsi, and arch/arm/boot/dts/exynos5420.dtsi, all assume that cpu@0-cpu@3 are A15 (big) and cpu@101-cpu@103 are A7 (LITTLE). Shouldn't arch/arm/boot/dts/sun9i-a80.dtsi stick to this convention? The scripts to create the uImage and to reproduce the problem are in https://github.com/xypron/kernel-optimusboard/tree/35d06c020f6584b5023e0e4bef67cc5a625f65bb Best regards Heinrich Schuchardt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] mm: cma: /proc/cmainfo
On Tue, Dec 30, 2014 at 02:00:27PM -0800, Laura Abbott wrote: > On 12/29/2014 8:47 PM, Minchan Kim wrote: > >> > >> > >>I've been meaning to write something like this for a while so I'm > >>happy to see an attempt made to fix this. I can't speak for the > >>author's reasons for wanting this information but there are > >>several reasons why I was thinking of something similar. > >> > >>The most common bug reports seen internally on CMA are 1) CMA is > >>too slow and 2) CMA failed to allocate memory. For #1, not all > >>allocations may be slow so it's useful to be able to keep track > >>of which allocations are taking too long. For #2, migration > > > >Then, I don't think we could keep all of allocations. What we need > >is only slow allocations. I hope we can do that with ftrace. > > > >ex) > > > ># cd /sys/kernel/debug/tracing > ># echo 1 > options/stacktrace > ># echo cam_alloc > set_ftrace_filter > ># echo your_threshold > tracing_thresh > > > >I know it doesn't work now but I think it's more flexible > >and general way to handle such issues(ie, latency of some functions). > >So, I hope we could enhance ftrace rather than new wheel. > >Ccing ftrace people. > > > >Futhermore, if we really need to have such information, we need more data > >(ex, how many of pages were migrated out, how many pages were dropped > >without migrated, how many pages were written back, how many pages were > >retried with the page lock and so on). > >In this case, event trace would be better. > > > > > > I agree ftrace is significantly more flexible in many respects but > for the type of information we're actually trying to collect here > ftrace may not be the right tool. Often times it won't be obvious there > will be a problem when starting a test so all debugging information > needs to be enabled. If the debugging information needs to be on > almost all the time anyway it seems silly to allow it be configurable > via ftrace. There is a trade off. Instead, ftrace will collect the information with small overhead in runtime, even alomost zero-overhead when we turns off so we could investigate the problem in live machine without rebooting/rebuiling. If the problem you are trying to solve is latency, I think ftrace with more data(ie, # of migrated page, # of stall by dirty or locking and so on) would be better. As current interface, something did cma_alloc which was really slow but it just cma_release right before we looked at the /proc/cmainfo. In that case, we will miss the information. It means someone should poll cmainfo continuously to avoid the missing so we should make reading part of cmainfo fast or make notification mechanism or keep only top 10 entries. Let's think as different view. If we know via cmainfo some function was slow, it's always true? Slowness of cma_alloc depends migration latency as well as cma region fragmentation so the function which was really slow would be fast in future if we are luck while fast function in old could be slower in future if there are lots of dirty pages or small small contiguous space in CMA region. I mean some funcion itself is slow or fast is not a important parameter to pinpoint cma's problem if we should take care of CMA's slowness or failing. Anyway, I'm not saying I don't want to add any debug facility to CMA. My point is this patchset doesn't say why author need it so it's hard to review the code. Depending on the problem author is looking, we should review what kinds of data, what kinds of interface, what kinds of implementation need. So please say more specific rather than just having better. > > >>failure is fairly common but it's still important to rule out > >>a memory leak from a dma client. Seeing all the allocations is > >>also very useful for memory tuning (e.g. how big does the CMA > >>region need to be, which clients are actually allocating memory). > > > >Memory leak is really general problem and could we handle it with > >page_owner? > > > > True, but it gets difficult to narrow down which are CMA pages allocated > via the contiguous code path. page owner also can't differentiate between I don't get it. The page_owner provides backtrace so why is it hard to parse contiguous code path? > different CMA regions, this needs to be done separately. This may Page owner just report PFN and we know which pfn range is any CMA regions so can't we do postprocessing? > be a sign page owner needs some extensions independent of any CMA > work. > >> > >>ftrace is certainly usable for tracing CMA allocation callers and > >>latency. ftrace is still only a fixed size buffer though so it's > >>possible for information to be lost if other logging is enabled. > > > >Sorry, I don't get with only above reasons why we need this. :( > > > > I guess from my perspective the problem that is being solved here > is a fairly fixed static problem. We know the information we always > want to collect and have available so the ability to turn it off > and on via ftrace doesn't seem
Re: fanotify bug on gdb -- hard crash
On Mon, 2014-12-29 at 13:06 +0800, ivo welch wrote:
> thank you, eric. will do. I read up on it above and now understand it
> better.
Great let us know if it keeps giving you trouble!
> the example in the man page seems somewhat misfortunate. I would use
> an example that does not, by default, lock up the user system.
> (perhaps add a second example with the _PERM feature that shows how it
> responds.)
The link you gave does respond and allow permissions:
if (metadata->fd >= 0) {
/* Handle open permission event */
if (metadata->mask & FAN_OPEN_PERM) {
printf("FAN_OPEN_PERM: ");
/* Allow file to be opened */
response.fd = metadata->fd;
response.response = FAN_ALLOW;
write(fd, ,
sizeof(struct fanotify_response));
}
That's the key bit of the example... If you use gdb and never get to
there, you are in a bit of trouble, I agree!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] media: au0828 analog_register error path fixes to do proper cleanup
au0828_analog_register() doesn't release video and vbi queues created by vb2_queue_init(). In addition, it doesn't unregister vdev when vbi register fails. Add vb2_queue_release() calls to release video and vbi queues to the failure path to be called when vdev register fails. Add video_unregister_device() for vdev when vbi register fails. Signed-off-by: Shuah Khan --- Please note that this patch is dependent on the au0828 vb2 conversion patch. drivers/media/usb/au0828/au0828-video.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/media/usb/au0828/au0828-video.c b/drivers/media/usb/au0828/au0828-video.c index 94b65b8..17450eb 100644 --- a/drivers/media/usb/au0828/au0828-video.c +++ b/drivers/media/usb/au0828/au0828-video.c @@ -1785,7 +1785,7 @@ int au0828_analog_register(struct au0828_dev *dev, dprintk(1, "unable to register video device (error = %d).\n", retval); ret = -ENODEV; - goto err_vbi_dev; + goto err_reg_vdev; } /* Register the vbi device */ @@ -1795,14 +1795,18 @@ int au0828_analog_register(struct au0828_dev *dev, dprintk(1, "unable to register vbi device (error = %d).\n", retval); ret = -ENODEV; - goto err_vbi_dev; + goto err_reg_vbi_dev; } - dprintk(1, "%s completed!\n", __func__); return 0; +err_reg_vbi_dev: + video_unregister_device(dev->vdev); +err_reg_vdev: + vb2_queue_release(>vb_vidq); + vb2_queue_release(>vb_vbiq); err_vbi_dev: video_device_release(dev->vbi_dev); err_vdev: -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next V2] virtio-net: don't do header check for dodgy gso packets
From: Jason Wang Date: Wed, 24 Dec 2014 11:03:52 +0800 > There's no need to do header check for virtio-net since: > > - Host sets dodgy for all gso packets from guest and check the header. > - Host should be prepared for all kinds of evil packets from guest, since > malicious guest can send any kinds of packet. > > So this patch sets NETIF_F_GSO_ROBUST for virtio-net to skip the check. > > Cc: Rusty Russell > Cc: Michael S. Tsirkin > Acked-by: Michael S. Tsirkin > Signed-off-by: Jason Wang > --- > Changes from V1: > - typo fixes Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
blk-mq: should elv_iosched_store return ENXIO/EINVAL?
Hello,
setting an invalid elevator without blk-mq results in an error:
# cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
# echo foo > /sys/block/sda/queue/scheduler
-bash: echo: write error: Invalid argument
# dmesg
[ 328.767088] elevator: type foo not found
[ 328.767097] elevator: switch to foo
failed
With blk-mq no error is returned:
# cat /sys/block/sda/queue/scheduler
none
# echo foo > /sys/block/sda/queue/scheduler
# echo $?
0
block/elevator.c got
988 ssize_t elv_iosched_store(struct request_queue *q, const char *name,
989 size_t count)
990 {
991 int ret;
992
993 if (!q->elevator)
994 return count;
995
996 ret = __elevator_change(q, name);
and
952 static int __elevator_change(struct request_queue *q, const char *name)
953 {
954 char elevator_name[ELV_NAME_MAX];
955 struct elevator_type *e;
956
957 if (!q->elevator)
958 return -ENXIO;
959
960 strlcpy(elevator_name, name, sizeof(elevator_name));
961 e = elevator_get(strstrip(elevator_name), true);
962 if (!e) {
963 printk(KERN_ERR "elevator: type %s not found\n",
elevator_name);
964 return -EINVAL;
965 }
So !q->elevator is checked in elv_iosched_store and __elevator_change.
Should elv_iosched_store return ENXIO or EINVAL or should __elevator_change
handle this?
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/27] atl1e: Use setup_timer
From: Julia Lawall Date: Fri, 26 Dec 2014 15:35:35 +0100 > Convert a call to init_timer and accompanying intializations of > the timer's data and function fields to a call to setup_timer. > > A simplified version of the semantic match that fixes this problem is as > follows: (http://coccinelle.lip6.fr/) > > // > @@ > expression t,f,d; > @@ > > -init_timer(); > +setup_timer(,f,d); > -t.function = f; > -t.data = d; > // > > Signed-off-by: Julia Lawall Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/27] atheros: atlx: Use setup_timer
From: Julia Lawall Date: Fri, 26 Dec 2014 15:35:34 +0100 > Convert a call to init_timer and accompanying intializations of > the timer's data and function fields to a call to setup_timer. > > A simplified version of the semantic match that fixes this problem is as > follows: (http://coccinelle.lip6.fr/) > > // > @@ > expression t,f,d; > @@ > > -init_timer(); > +setup_timer(,f,d); > -t.function = f; > -t.data = d; > // > > Signed-off-by: Julia Lawall Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/27] ksz884x: Use setup_timer
From: Julia Lawall Date: Fri, 26 Dec 2014 15:35:42 +0100 > Convert a call to init_timer and accompanying intializations of > the timer's data and function fields to a call to setup_timer. > > A simplified version of the semantic match that fixes this problem is as > follows: (http://coccinelle.lip6.fr/) > > // > @@ > expression t,f,d; > @@ > > -init_timer(); > +setup_timer(,f,d); > -t.function = f; > -t.data = d; > // > > Signed-off-by: Julia Lawall Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/27] net: sxgbe: Use setup_timer
From: Julia Lawall Date: Fri, 26 Dec 2014 15:35:46 +0100 > Convert a call to init_timer and accompanying intializations of > the timer's data and function fields to a call to setup_timer. > > A simplified version of the semantic match that fixes this problem is as > follows: (http://coccinelle.lip6.fr/) > > // > @@ > expression t,f,d; > @@ > > -init_timer(); > +setup_timer(,f,d); > -t.function = f; > -t.data = d; > // > > Signed-off-by: Julia Lawall Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 00/11] Time Counter fixes and improvements
From: Richard Cochran Date: Sun, 21 Dec 2014 19:46:55 +0100 > Several PTP Hardware Clock (PHC) drivers implement the clock in > software using the timecounter/cyclecounter code. This series adds one > simple improvement and one more subtle fix to the shared timecounter > facility. Credit for this series goes to Janusz Użycki, who pointed > the issues out to me off list. Series applied, thanks Richard. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 答复：[PATCH] perf core: Use KSTK_ESP() instead of pt_regs->sp while output user regs
On Dec 30, 2014 11:03 AM, "Peter Zijlstra" wrote: > > On Thu, Dec 25, 2014 at 07:48:28AM -0800, Andy Lutomirski wrote: > > On a quick look, there are plenty of other bugs in there besides just > > the stack pointer issue. The ABI check that uses TIF_IA32 in the perf > > core is completely wrong. TIF_IA32 may be equal to the actual > > userspace bitness by luck, but, if so, that's more or less just luck. > > And there's a user_mode test that should be user_mode_vm. > > > > Also, it's not just sp that's wrong. There are various places that > > you can interrupt in which many of the registers have confusing > > locations. You could try using the cfi unwind data, but that's > > unlikely to work for regs like cs and ss, and, during context switch, > > this has very little chance of working. > > > > What's the point of this feature? Honestly, my suggestion would be to > > delete it instead of trying to fix it. It's also not clear to me that > > there aren't serious security problems here -- it's entirely possible > > for sensitive *kernel* values to and up in task_pt_regs at certain > > times, and if you run during context switch and there's no code to > > suppress this dump during context switch, then you could be showing > > regs that belong to the wrong task. > > Of course the people who actually wrote the code are not on CC :/ > > There's two users of this iirc; > > 1) the dwarf stack unwinder thingy, which basically dumps the userspace > regs and the top of userspace stack on 'event'. > Given how the x86_64* entry code works, using task_pt_regs from anywhere except explicitly supported contexts (including exceptions that originated in userspace and a small handful of system calls) is asking for trouble. NMI context is especially bad. How important is this feature, and which registers matter? It might be possible to use a dwarf unwinder on the kernel call stack to get most of the regs from most contexts, and it might also be possible to make small changes to the entry code to make it possible to get some of the registers reliably, but it's not currently possible to safely use task_pt_regs *at all* from NMI context unless you've at least blacklisted a handful of origin RIP values that give dangerously bogus results. (Using do_nmi's regs parameter if user_mode_vm(regs) is a different story.) * I'm not nearly as familiar with the 32-bit entry code, so I don't know whether we have the same issues there. > 2) the recent sample_regs_intr, which dumps the register set at > 'event', be it kernel or userspace. > What's wrong with the PMI's pt_regs for that? If we interrupted the kernel, they'll be kernel regs (with all their attendant security issues) and, if we interrupted userspace, then they'll be the full, correct userspace registers. --Andy > > The first is somewhat usable when lacking framepointers while still > desiring some unwind information, the second is useful to things like > call argument profiling and the like. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] net: stmmac: add BQL support
On Mon, Dec 29, 2014 at 09:42:01AM -0800, Dave Taht wrote: > On Sun, Dec 28, 2014 at 1:48 PM, Beniamino Galvani > wrote: > > On Sun, Dec 28, 2014 at 08:25:40AM -0800, Dave Taht wrote: > >> On Sun, Dec 28, 2014 at 6:57 AM, Beniamino Galvani > >> wrote: > >> > Add support for Byte Queue Limits to the STMicro MAC driver. > >> > >> Thank you! > >> > >> > Tested on a Amlogic S805 Cortex-A5 board, where the use of BQL > >> > slightly decreases the ping latency from ~10ms to ~3ms when the > >> > 100Mbps link is saturated by TCP streams. No difference is > >> > observed at 1Gbps. > >> > >> I see the plural. With TSQ in place it is hard (without something like > >> the rrul test driving multiple streams) to drive a driver to > >> saturation with small numbers of flows. This was with pfifo_fast, not > >> sch_fq, at 100mbit? > > > > Hi Dave, > > > > yes, this was with pfifo_fast and I used 4 iperf TCP streams. The total > > throughput didn't seem to increase adding more streams. > > >> > >> Can this board actually drive a full gigabit in the first place? Until > >> now most of the low end arm boards I have seen only came with > >> a 100mbit mac, and the gig ones lacking offloads seemed to peak > >> out at about 600mbit. > > > > I measured a throughput of 650mbit in rx and 600mbit in tx. > > You might want to try the rrul test which tests both directions and > latency at the same time. I will try it, thanks. > > In my case I have been trying to find a low-cost chip that could do soft > rate limiting (htb) + fq_codel at up to 300mbit/sec, as that is about > the peak speed > we will be getting from cable modems, and these are horribly overbuffered, > at these speeds too, with 1.2sec of bidirectional latency observed at > 120mbit/12mbit. > > I'm open to crazy ideas like trying to find a use for the gpu, etc, to > get there. > > > > >> > >> Under my christmas tree landed a quad core A5 (odroid-c1), also an > >> xgene and zedboard - both of the latter are a-needing BQL, > >> and I haven't booted the udroid yet. Hopefully it is the > >> same driver you just improved. > > > > I'm using the odroid-c1 too, with this tree based on the recent > > Amlogic mainline work: > > > > https://github.com/bengal/linux/tree/meson8b > > Oh, cool, thx! > > > Unfortunately at the moment the support for the board is very basic > > (for example, SMP is not working yet) but it's enough to do some NIC > > tests. > > Good to know. Have you looked at xmit_more yet? > > http://lwn.net/Articles/615238/ I don't know if I have implemented it correctly, but I found that the improvement with xmit_more is so small to be barely observable, maybe because the cost for starting the hardware transmission is very low (it's a single mmio write). Beniamino -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "perf top -g" leaking ~300MB per second.
Em Tue, Dec 30, 2014 at 09:35:24AM +0100, Markus Trippelsdorf escreveu: > On 2014.12.30 at 14:38 +0900, Namhyung Kim wrote: > > Hi David and Markus, > > > > On Sat, Dec 13, 2014 at 11:16:43AM -0700, David Ahern wrote: > > > On 12/13/14 8:26 AM, Arnaldo Carvalho de Melo wrote: > > > >The callchain code was done initially for 'report' and when I made 'top' > > > >reuse the hist_entry code allowing 'top' to collect callchains was too > > > >easy, but then we need to go thru the callchain/hists/hist_entry code to > > > >make sure that they don't leak, will try to do it... > > > > > > > > > > As I recall it is build up of the dead_threads list. > > > > Maybe. But I guess it's because of leak of callchains.. > > > > Markus, could you please test below patch how much it affects? > > Thanks Namhyung. It leaks an order of magnitude less memory now: > ~30MB/sec on my machine. > > Valgrind shows (last entries of the list): > ... > ==20512== 7,225,920 bytes in 17,370 blocks are possibly lost in loss record > 295 of 301 > ==20512==at 0x402B000: calloc (vg_replace_malloc.c:623) > ==20512==by 0x4A6996: zalloc (util.h:189) > ==20512==by 0x4A6996: hist_entry__new (hist.c:309) > ==20512==by 0x4A8249: add_hist_entry (hist.c:431) > ==20512==by 0x4A8249: __hists__add_entry (hist.c:477) > ==20512==by 0x4A8902: iter_add_single_cumulative_entry (hist.c:730) > ==20512==by 0x4A8A64: hist_entry_iter__add (hist.c:876) > ==20512==by 0x43787A: perf_event__process_sample (builtin-top.c:787) > ==20512==by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) > ==20512==by 0x4395EE: perf_top__mmap_read (builtin-top.c:871) > ==20512==by 0x4395EE: __cmd_top (builtin-top.c:974) > ==20512==by 0x4395EE: cmd_top (builtin-top.c:1266) > ==20512==by 0x41B702: run_builtin (perf.c:341) > ==20512==by 0x41AE51: handle_internal_command (perf.c:400) > ==20512==by 0x41AE51: run_argv (perf.c:444) > ==20512==by 0x41AE51: main (perf.c:559) #1) Ok, those are the hist_entries that were not decayed, if top continued they would eventually be decayed, freed, etc, i.e. the exit of top is equivalent to the last decay. > ==20512== > ==20512== 8,922,480 bytes in 159,330 blocks are possibly lost in loss record > 296 of 301 > ==20512==at 0x402B000: calloc (vg_replace_malloc.c:623) > ==20512==by 0x4821FE: zalloc (util.h:189) > ==20512==by 0x4821FE: fill_node (callchain.c:450) > ==20512==by 0x4821FE: add_child (callchain.c:473) > ==20512==by 0x4821FE: append_chain_children (callchain.c:596) > ==20512==by 0x48514E: callchain_append (callchain.c:672) > ==20512==by 0x4A8947: iter_add_single_cumulative_entry (hist.c:739) > ==20512==by 0x4A8A64: hist_entry_iter__add (hist.c:876) > ==20512==by 0x43787A: perf_event__process_sample (builtin-top.c:787) > ==20512==by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) > ==20512==by 0x43967E: perf_top__mmap_read (builtin-top.c:871) > ==20512==by 0x43967E: __cmd_top (builtin-top.c:996) > ==20512==by 0x43967E: cmd_top (builtin-top.c:1266) > ==20512==by 0x41B702: run_builtin (perf.c:341) > ==20512==by 0x41AE51: handle_internal_command (perf.c:400) > ==20512==by 0x41AE51: run_argv (perf.c:444) > ==20512==by 0x41AE51: main (perf.c:559) > ==20512== > ==20512== 11,050,136 bytes in 1,663 blocks are definitely lost in loss record > 297 of 301 > ==20512==at 0x402B000: calloc (vg_replace_malloc.c:623) > ==20512==by 0x44F7BF: zalloc (util.h:189) > ==20512==by 0x44F7BF: symbol__alloc_hist (annotate.c:455) > ==20512==by 0x44F7BF: symbol__inc_addr_samples (annotate.c:507) > ==20512==by 0x44F7BF: hist_entry__inc_addr_samples (annotate.c:521) > ==20512==by 0x437A65: perf_top__record_precise_ip (builtin-top.c:195) > ==20512==by 0x437A65: hist_iter__top_callback (builtin-top.c:688) > ==20512==by 0x4A8AC8: hist_entry_iter__add (hist.c:892) > ==20512==by 0x43787A: perf_event__process_sample (builtin-top.c:787) > ==20512==by 0x43787A: perf_top__mmap_read_idx (builtin-top.c:854) > ==20512==by 0x43967E: perf_top__mmap_read (builtin-top.c:871) > ==20512==by 0x43967E: __cmd_top (builtin-top.c:996) > ==20512==by 0x43967E: cmd_top (builtin-top.c:1266) > ==20512==by 0x41B702: run_builtin (perf.c:341) > ==20512==by 0x41AE51: handle_internal_command (perf.c:400) > ==20512==by 0x41AE51: run_argv (perf.c:444) > ==20512==by 0x41AE51: main (perf.c:559) These (symbol__alloc_hist) we need to free up the decaying of per RIP annotation gets to zero... Will check where to do this... > ==20512== > ==20512== 24,920,064 bytes in 59,904 blocks are possibly lost in loss record > 298 of 301 > ==20512==at 0x402B000: calloc (vg_replace_malloc.c:623) > ==20512==by 0x4A6996: zalloc (util.h:189) > ==20512==by 0x4A6996: hist_entry__new (hist.c:309) > ==20512==by 0x4A8249: add_hist_entry (hist.c:431) > ==20512==by 0x4A8249: __hists__add_entry
Re: [PATCH 3/3] comedi: checkpatch warning: missing blank line
On 28/12/14 18:56, Andreas Siegling wrote:
This patch will fix all occurrences of the checkpatch warning:
WARNING: Missing a blank line after declarations
in drivers/staging/comedi/.
Signed-off-by: Andreas Siegling
Signed-off-by: Zhutao Lu
---
drivers/staging/comedi/drivers/comedi_bond.c | 1 +
drivers/staging/comedi/drivers/ni_stc.h | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/staging/comedi/drivers/comedi_bond.c
b/drivers/staging/comedi/drivers/comedi_bond.c
index 85b2f4a..221d381 100644
--- a/drivers/staging/comedi/drivers/comedi_bond.c
+++ b/drivers/staging/comedi/drivers/comedi_bond.c
@@ -261,6 +261,7 @@ static int do_dev_config(struct comedi_device *dev, struct
comedi_devconfig *it)
{
/* Append dev:subdev to devpriv->name */
char buf[20];
+
snprintf(buf, sizeof(buf), "%u:%u ",
bdev->minor, bdev->subdev);
strlcat(devpriv->name, buf,
diff --git a/drivers/staging/comedi/drivers/ni_stc.h
b/drivers/staging/comedi/drivers/ni_stc.h
index bb76fe1..3b8b3c5 100644
--- a/drivers/staging/comedi/drivers/ni_stc.h
+++ b/drivers/staging/comedi/drivers/ni_stc.h
@@ -326,6 +326,7 @@ static inline unsigned RTSI_Output_Bit(unsigned channel,
int is_mseries)
{
unsigned max_channel;
unsigned base_bit_shift;
+
if (is_mseries) {
base_bit_shift = 8;
max_channel = 7;
@@ -1142,6 +1143,7 @@ static inline unsigned MSeries_AI_Config_Bank_Bits(enum
ni_reg_type reg_type,
unsigned channel)
{
unsigned bits = channel & 0x30;
+
if (reg_type == ni_reg_622x) {
if (channel & 0x40)
bits |= 0x400;
@@ -1191,6 +1193,7 @@ enum MSeries_PLL_Control_Bits {
static inline unsigned MSeries_PLL_Divisor_Bits(unsigned divisor)
{
static const unsigned max_divisor = 0x10;
+
if (divisor < 1 || divisor > max_divisor) {
pr_err("%s: bug, invalid divisor=%i\n", __func__, divisor);
return 0;
@@ -1201,6 +1204,7 @@ static inline unsigned MSeries_PLL_Divisor_Bits(unsigned
divisor)
static inline unsigned MSeries_PLL_Multiplier_Bits(unsigned multiplier)
{
static const unsigned max_multiplier = 0x100;
+
if (multiplier < 1 || multiplier > max_multiplier) {
pr_err("%s: bug, invalid multiplier=%i\n", __func__,
multiplier);
Reviewed-by: Ian Abbott
--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Web: http://www.mev.co.uk/ )=-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
This reverts commit 24a0aa212ee2dbe44360288684478d76a8e20a0a. It's causing severe userspace breakage. Namely, all the utilities from wireless-utils which are relying on CONFIG_WEXT (which means tools like 'iwconfig', 'iwlist', etc) are not working anymore. There is a 'iw' utility in newer wireless-tools, which is supposed to be a replacement for all the "deprecated" binaries, but it's far away from being massively adopted. Please see [1] for example of the userspace breakage this is causing. In addition to that, Larry Finger reports [2] that this patch is also causing ipw2200 driver being impossible to build. To me this clearly shows that CONFIG_WEXT is far, far away from being "deprecated enough" to be removed. [1] http://thread.gmane.org/gmane.linux.kernel/1857010 [2] http://thread.gmane.org/gmane.linux.network/343688 Signed-off-by: Jiri Kosina --- net/wireless/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig index 22ba971..29c8675 100644 --- a/net/wireless/Kconfig +++ b/net/wireless/Kconfig @@ -175,7 +175,7 @@ config CFG80211_INTERNAL_REGDB Most distributions have a CRDA package. So if unsure, say N. config CFG80211_WEXT - bool + bool "cfg80211 wireless extensions compatibility" depends on CFG80211 select WEXT_CORE help -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
