[RESEND PATCH v2] mm/vmscan.c: wrap five parameters into writeback_stats for reducing the stack consumption
shrink_page_list() has too many arguments that have already reached ten.
Some of those arguments and temporary variables introduces extra 80 bytes
on the stack. This patch wraps five parameters into writeback_stats and removes
some temporary variables, thus making the relative functions to consume fewer
stack space.
Before mm/vmscan.c is changed:
textdata bss dec hex filename
6876698 957224 966656 8800578 864942 vmlinux-3.15
After mm/vmscan.c is changed:
textdata bss dec hex filename
6876506 957224 966656 8800386 864882 vmlinux-3.15
scripts/checkstack.pl can be used for checking the change of the target
function stack.
Before mm/vmscan.c is changed:
0x810af103 shrink_inactive_list []: 152
0x810af43d shrink_inactive_list []: 152
-
0x810aede8 reclaim_clean_pages_from_list []:184
0x810aeef8 reclaim_clean_pages_from_list []:184
-
0x810ae582 shrink_page_list []: 232
0x810aedb5 shrink_page_list []: 232
After mm/vmscan.c is changed::
0x810af078 shrink_inactive_list []: 120
0x810af36d shrink_inactive_list []: 120
-
With: struct writeback_stats dummy = {};
0x810aed6c reclaim_clean_pages_from_list []:152
0x810aee68 reclaim_clean_pages_from_list []:152
-
With: static struct writeback_stats dummy ={};
0x810aed69 reclaim_clean_pages_from_list []:120
0x810aee4d reclaim_clean_pages_from_list []:120
--
0x810ae586 shrink_page_list []: 184 --- sub
$0xb8,%rsp
0x810aed36 shrink_page_list []: 184 --- add
$0xb8,%rsp
Via the above figures, we can find that the difference value of the stack is 32
for
shrink_inactive_list and reclaim_clean_pages_from_list, and this value is
48(232-184)
for shrink_page_list. From the hierarchy of functions called, the total
difference
value is 80(32+48) for this change.
Changes since v1: https://lkml.org/lkml/2014/6/12/159
* Rename arg_container to writeback_stats
* Change the the way of initializing writeback_stats object.
Signed-off-by: Chen Yucong sla...@gmail.com
---
mm/vmscan.c | 62 ++-
1 file changed, 27 insertions(+), 35 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index a8ffe4e..3f28e39 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -791,28 +791,31 @@ static void page_check_dirty_writeback(struct page *page,
}
/*
+ * Callers pass a prezeroed writeback_stats into the shrink functions to gather
+ * statistics about how many pages of particular states were processed
+ */
+struct writeback_stats {
+ unsigned long nr_dirty;
+ unsigned long nr_unqueued_dirty;
+ unsigned long nr_congested;
+ unsigned long nr_writeback;
+ unsigned long nr_immediate;
+};
+
+/*
* shrink_page_list() returns the number of reclaimed pages
*/
static unsigned long shrink_page_list(struct list_head *page_list,
struct zone *zone,
struct scan_control *sc,
enum ttu_flags ttu_flags,
- unsigned long *ret_nr_dirty,
- unsigned long *ret_nr_unqueued_dirty,
- unsigned long *ret_nr_congested,
- unsigned long *ret_nr_writeback,
- unsigned long *ret_nr_immediate,
+ struct writeback_stats *ws,
bool force_reclaim)
{
LIST_HEAD(ret_pages);
LIST_HEAD(free_pages);
int pgactivate = 0;
- unsigned long nr_unqueued_dirty = 0;
- unsigned long nr_dirty = 0;
- unsigned long nr_congested = 0;
unsigned long nr_reclaimed = 0;
- unsigned long nr_writeback = 0;
- unsigned long nr_immediate = 0;
cond_resched();
@@ -858,10 +861,10 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
*/
page_check_dirty_writeback(page, dirty, writeback);
if (dirty || writeback)
- nr_dirty++;
+ ws-nr_dirty++;
if (dirty !writeback)
- nr_unqueued_dirty++;
+ ws-nr_unqueued_dirty++;
/*
* Treat this page as congested if the underlying BDI is or if
@@ -872,7 +875,7 @@ static unsigned long
Re: [PATCH] sched: Fast idling of CPU when system is partially loaded
On Thu, 2014-06-12 at 14:25 -0700, Tim Chen wrote:
Signed-off-by: Tim Chen tim.c.c...@linux.intel.com
---
kernel/sched/core.c | 12
kernel/sched/fair.c | 23 +--
kernel/sched/sched.h | 10 --
3 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c6b9879..4f57221 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2630,7 +2630,7 @@ static inline struct task_struct *
pick_next_task(struct rq *rq, struct task_struct *prev)
{
const struct sched_class *class = fair_sched_class;
- struct task_struct *p;
+ struct task_struct *p = NULL;
/*
* Optimization: we know that if all tasks are in
@@ -2638,9 +2638,13 @@ pick_next_task(struct rq *rq, struct task_struct *prev)
*/
if (likely(prev-sched_class == class
rq-nr_running == rq-cfs.h_nr_running)) {
- p = fair_sched_class.pick_next_task(rq, prev);
- if (unlikely(p == RETRY_TASK))
- goto again;
+
+ /* If no cpu has more than 1 task, skip */
+ if (rq-nr_running 0 || rq-rd-overload) {
Hi Tim,
If it is skipping if no cpu has more than 1 task, should the
above have the additional check for (rq-nr_running 1) instead
of (rq-nr_running 0)?
+ p = fair_sched_class.pick_next_task(rq, prev);
+ if (unlikely(p == RETRY_TASK))
+ goto again;
+ }
/* assumes fair_sched_class-next == idle_sched_class */
if (unlikely(!p))
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9855e87..00ab38c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5863,7 +5863,8 @@ static inline int sg_capacity(struct lb_env *env,
struct sched_group *group)
*/
static inline void update_sg_lb_stats(struct lb_env *env,
struct sched_group *group, int load_idx,
- int local_group, struct sg_lb_stats *sgs)
+ int local_group, struct sg_lb_stats *sgs,
+ bool *overload)
{
unsigned long load;
int i;
@@ -5881,6 +5882,8 @@ static inline void update_sg_lb_stats(struct lb_env
*env,
sgs-group_load += load;
sgs-sum_nr_running += rq-nr_running;
+ if (overload rq-nr_running 1)
+ *overload = true;
#ifdef CONFIG_NUMA_BALANCING
sgs-nr_numa_running += rq-nr_numa_running;
sgs-nr_preferred_running += rq-nr_preferred_running;
@@ -5991,6 +5994,7 @@ static inline void update_sd_lb_stats(struct lb_env
*env, struct sd_lb_stats *sd
struct sched_group *sg = env-sd-groups;
struct sg_lb_stats tmp_sgs;
int load_idx, prefer_sibling = 0;
+ bool overload = false;
if (child child-flags SD_PREFER_SIBLING)
prefer_sibling = 1;
@@ -6011,7 +6015,13 @@ static inline void update_sd_lb_stats(struct lb_env
*env, struct sd_lb_stats *sd
update_group_power(env-sd, env-dst_cpu);
}
- update_sg_lb_stats(env, sg, load_idx, local_group, sgs);
+ if (env-sd-parent)
+ update_sg_lb_stats(env, sg, load_idx, local_group, sgs,
+ NULL);
+ else
+ /* gather overload info if we are at root domain */
+ update_sg_lb_stats(env, sg, load_idx, local_group, sgs,
+ overload);
Would it make the code cleaner if we always call:
+ update_sg_lb_stats(env, sg, load_idx, local_group, sgs,
overload);
and in update_sg_lb_stats():
+ bool is_root_domain = (env-sd-parent == NULL)
+ /* gather overload info if we are at root domain */
+ if (is_root_domain rq-nr_running 1)
+ *overload = true;
if (local_group)
goto next_group;
@@ -6045,6 +6055,15 @@ next_group:
if (env-sd-flags SD_NUMA)
env-fbq_type = fbq_classify_group(sds-busiest_stat);
+
+ if (!env-sd-parent) {
+ /* update overload indicator if we are at root domain */
+ int i = cpumask_first(sched_domain_span(env-sd));
+ struct rq *rq = cpu_rq(i);
Perhaps we could just use:
struct rq *rq = env-dst_rq;
+ if (rq-rd-overload != overload)
+ rq-rd-overload = overload;
+ }
+
}
/**
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index e47679b..a0cd5c1 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -477,6 +477,9 @@ struct root_domain {
cpumask_var_t span;
cpumask_var_t online;
+ /* Indicate more than one runnable task for
Re: [PATCH v3] lib: add size unit t/p/e to memparse
On 12/06/14 23:15, Andrew Morton wrote: On Wed, 2 Apr 2014 16:54:37 +0800 Gui Hecheng guihc.f...@cn.fujitsu.com wrote: For modern filesystems such as btrfs, t/p/e size level operations are common. add size unit t/p/e parsing to memparse Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com --- changelog v1-v2: replace kilobyte with kibibyte, and others v2-v3: add missing unit bytes in comment --- lib/cmdline.c | 25 - 1 file changed, 20 insertions(+), 5 deletions(-) diff --git a/lib/cmdline.c b/lib/cmdline.c index eb67911..511b9be 100644 --- a/lib/cmdline.c +++ b/lib/cmdline.c @@ -119,11 +119,17 @@ char *get_options(const char *str, int nints, int *ints) *@retptr: (output) Optional pointer to next char after parse completes * *Parses a string into a number. The number stored at @ptr is - * potentially suffixed with %K (for kilobytes, or 1024 bytes), - * %M (for megabytes, or 1048576 bytes), or %G (for gigabytes, or - * 1073741824). If the number is suffixed with K, M, or G, then - * the return value is the number multiplied by one kilobyte, one - * megabyte, or one gigabyte, respectively. + * potentially suffixed with + * %K (for kibibytes, or 1024 bytes), + * %M (for mebibytes, or 1048576 bytes), + * %G (for gibibytes, or 1073741824 bytes), + * %T (for tebibytes, or 1099511627776 bytes), + * %P (for pebibytes, or 1125899906842624 bytes), + * %E (for exbibytes, or 1152921504606846976 bytes). I'm afraid I find these names quite idiotic - we all know what the traditional terms mean so why go and muck with it. Also, kibibytes sounds like cat food. Hi, Andrew While I agree it sounds like cat food, it seemed like a good opportunity to fix a minor issue that is otherwise unlikely to be fixed for a very long time. Should we feel uncomfortable with the patch, as is, because of language/correctness friction? Pedantry included, the patch is correct. ;) Thanks -- __ Brendan Hide http://swiftspirit.co.za/ http://www.webafrica.co.za/?AFF1E97 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lib: add size unit t/p/e to memparse
On 13/06/14 03:42, Gui Hecheng wrote:
For modern filesystems such as btrfs, t/p/e size level operations
are common.
add size unit t/p/e parsing to memparse
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
changelog
v1-v2: replace kilobyte with kibibyte, and others
v2-v3: add missing unit bytes in comment
v3-v4: remove idiotic name for K,M,G,P,T,E
---
lib/cmdline.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/lib/cmdline.c b/lib/cmdline.c
index d4932f7..76a712e 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -121,11 +121,7 @@ EXPORT_SYMBOL(get_options);
*@retptr: (output) Optional pointer to next char after parse completes
*
*Parses a string into a number. The number stored at @ptr is
- * potentially suffixed with %K (for kilobytes, or 1024 bytes),
- * %M (for megabytes, or 1048576 bytes), or %G (for gigabytes, or
- * 1073741824). If the number is suffixed with K, M, or G, then
- * the return value is the number multiplied by one kilobyte, one
- * megabyte, or one gigabyte, respectively.
+ * potentially suffixed with K, M, G, T, P, E.
*/
unsigned long long memparse(const char *ptr, char **retptr)
@@ -135,6 +131,15 @@ unsigned long long memparse(const char *ptr, char **retptr)
unsigned long long ret = simple_strtoull(ptr, endptr, 0);
switch (*endptr) {
+ case 'E':
+ case 'e':
+ ret = 10;
+ case 'P':
+ case 'p':
+ ret = 10;
+ case 'T':
+ case 't':
+ ret = 10;
case 'G':
case 'g':
ret = 10;
Ah, I see - you've removed all reference to their names. That's good too. :)
--
__
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] lib: add size unit t/p/e to memparse
On Fri, 2014-06-13 at 07:55 +0200, Brendan Hide wrote:
On 13/06/14 03:42, Gui Hecheng wrote:
For modern filesystems such as btrfs, t/p/e size level operations
are common.
add size unit t/p/e parsing to memparse
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
changelog
v1-v2: replace kilobyte with kibibyte, and others
v2-v3: add missing unit bytes in comment
v3-v4: remove idiotic name for K,M,G,P,T,E
---
lib/cmdline.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/lib/cmdline.c b/lib/cmdline.c
index d4932f7..76a712e 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -121,11 +121,7 @@ EXPORT_SYMBOL(get_options);
*@retptr: (output) Optional pointer to next char after parse
completes
*
*Parses a string into a number. The number stored at @ptr is
- * potentially suffixed with %K (for kilobytes, or 1024 bytes),
- * %M (for megabytes, or 1048576 bytes), or %G (for gigabytes, or
- * 1073741824). If the number is suffixed with K, M, or G, then
- * the return value is the number multiplied by one kilobyte, one
- * megabyte, or one gigabyte, respectively.
+ * potentially suffixed with K, M, G, T, P, E.
*/
unsigned long long memparse(const char *ptr, char **retptr)
@@ -135,6 +131,15 @@ unsigned long long memparse(const char *ptr, char
**retptr)
unsigned long long ret = simple_strtoull(ptr, endptr, 0);
switch (*endptr) {
+ case 'E':
+ case 'e':
+ ret = 10;
+ case 'P':
+ case 'p':
+ ret = 10;
+ case 'T':
+ case 't':
+ ret = 10;
case 'G':
case 'g':
ret = 10;
Ah, I see - you've removed all reference to their names. That's good too. :)
Thank you for your review!
I think maybe more people would like cleaner things in the kernel.
-Gui
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 05/19] irqchip: crossbar: Change allocation logic by reversing search for free irqs
Hi Jason, On Thursday 12 June 2014 06:26 PM, Jason Cooper wrote: On Thu, Jun 12, 2014 at 05:23:13PM +0530, Sricharan R wrote: From: Nishanth Menon n...@ti.com Reverse the search algorithm to ensure that address mapping and IRQ allocation logics are proper. This can open up new bugs which are easily fixable rather than wait till allocation logic approaches the limit to find new bugs. Could you expand on this logic some more? What class of bugs are you hoping to discover more easily? class 1. address space errors - example: reg = a size_b ti,max-irqs = is a wrong parameter class 2: irq-reserved list - which decides which entries in the address space is not actually wired in class 3: wrong list of routable-irqs. in general allocating from max to min tends to have benefits in ensuring the different issues that may be present in dts is easily caught at definition time, rather than at a later point in time. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] staging: alarm-dev: Support to Compile as Module
From: Pramod Gurav pramod.gurav@gmail.com Currently this alarm-dev can be compiles only as built in driver. This adds support to compile it as module as well which is in planned activity (See drivers/staging/android/TODO) CC: Greg Kroah-Hartman g...@kroah.com CC: Brian Swetland swetl...@google.com Signed-off-by: Pramod Gurav pramod.gurav@gmail.com --- drivers/staging/android/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig index 99e484f..c359317 100644 --- a/drivers/staging/android/Kconfig +++ b/drivers/staging/android/Kconfig @@ -76,7 +76,7 @@ config ANDROID_LOW_MEMORY_KILLER Registers processes to be killed when memory is low config ANDROID_INTF_ALARM_DEV - bool Android alarm driver + tristate Android alarm driver depends on RTC_CLASS default n ---help--- -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] alarmtimer: Export symbols of alarmtimer_get_rtcdev
From: Pramod Gurav pramod.gurav@gmail.com Export symbol of alarmtimer_get_rtcdev so that it is used by any driver when built as module like, drivers/staging/android/alarm-dev.c. CC: John Stultz john.stu...@linaro.org CC: Marcus Gelderie redm...@gmail.com CC: Greg Kroah-Hartman g...@kroah.com Signed-off-by: Pramod Gurav pramod.gurav@gmail.com --- This Export was missing in Marcus's below patch: https://lkml.org/lkml/2013/6/1/144 Changes since v1: -Removed trivial list from CC kernel/time/alarmtimer.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c index 88c9c65..a53ba0b 100644 --- a/kernel/time/alarmtimer.c +++ b/kernel/time/alarmtimer.c @@ -71,7 +71,7 @@ struct rtc_device *alarmtimer_get_rtcdev(void) return ret; } - +EXPORT_SYMBOL_GPL(alarmtimer_get_rtcdev); static int alarmtimer_rtc_add_device(struct device *dev, struct class_interface *class_intf) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 00/14] perf/core improvements and fixes
* Jiri Olsa jo...@kernel.org wrote: hi Ingo, please consider pulling thanks, jirka The following changes since commit 7184062b94b4bfac08715fb786fd2df399c5d6ee: Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core (2014-06-12 13:54:42 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git tags/perf-core-for-mingo for you to fetch changes up to 45dc1bb5c1d47f9519e2101f6b073bb4bb1d1f99: perf tests: Add test for closing dso objects on EMFILE error (2014-06-12 16:53:23 +0200) perf/core improvements and fixes: . Honor user freq/interval properly in record command (Namhyung Kim) . Speedup DWARF unwind (Jiri Olsa) Signed-off-by: Jiri Olsa jo...@kernel.org Jiri Olsa (13): perf tools: Cache register accesses for unwind processing perf tools: Separate dso data related variables perf tools: Add data_fd into dso object perf tools: Add global list of opened dso objects perf tools: Add global count of opened dso objects perf tools: Cache dso data file descriptor perf tools: Add file size check and factor dso__data_read_offset perf tools: Allow to close dso fd in case of open failure perf tools: Add dso__data_* interface descriptons perf tests: Spawn child for each test perf tests: Allow reuse of test_file function perf tests: Add test for caching dso file descriptors perf tests: Add test for closing dso objects on EMFILE error Namhyung Kim (1): perf record: Fix to honor user freq/interval properly tools/perf/tests/builtin-test.c| 42 +- tools/perf/tests/dso-data.c| 214 +++- tools/perf/tests/tests.h | 2 + tools/perf/util/dso.c | 279 + tools/perf/util/dso.h | 50 ++- tools/perf/util/event.h| 5 + tools/perf/util/evsel.c| 4 +- tools/perf/util/perf_regs.c| 10 +- tools/perf/util/perf_regs.h| 4 +- tools/perf/util/unwind-libunwind.c | 2 - 10 files changed, 574 insertions(+), 38 deletions(-) Pulled, thanks a lot Jiri! Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] USB:gadget: Fix a warning while loading g_mass_storage
On 06/09/2014 02:19 PM, wei.y...@windriver.com wrote: From: Yang Wei wei.y...@windriver.com While loading g_mass_storage module, the following warning is triggered. WARNING: at drivers/usb/gadget/composite.c: usb_composite_setup_continue: Unexpected call Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage [800179cc] (unwind_backtrace+0x0/0x104) from [80619608] (dump_stack+0x20/0x24) [80619608] (dump_stack+0x20/0x24) from [80025100] (warn_slowpath_common+0x64/0x74) [80025100] (warn_slowpath_common+0x64/0x74) from [800251cc] (warn_slowpath_fmt+0x40/0x48) [800251cc] (warn_slowpath_fmt+0x40/0x48) from [7f047774] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) [7f047774] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) from [7f047ad4] (handle_exception+0x358/0x3e4 [g_mass_storage]) [7f047ad4] (handle_exception+0x358/0x3e4 [g_mass_storage]) from [7f048080] (fsg_main_thread+0x520/0x157c [g_mass_storage]) [7f048080] (fsg_main_thread+0x520/0x157c [g_mass_storage]) from [8004bc90] (kthread+0x98/0x9c) [8004bc90] (kthread+0x98/0x9c) from [8000faec] (kernel_thread_exit+0x0/0x8) The root cause is that the existing code fails to take into account the possibility that common-new_fsg can change while do_set_interface() is running, because the spinlock isn't held at this point. Signed-off-by: Yang Wei wei.y...@windriver.com Signed-off-by: Alan Stern st...@rowland.harvard.edu --- drivers/usb/gadget/f_mass_storage.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) Hi Alan, Thanks for your review, there are a few changes in v3: 1) Fix a coding style issue. 2) Refine the commit log Regards Wei Ping, Alan, What do you think of it? Wei diff --git a/drivers/usb/gadget/f_mass_storage.c b/drivers/usb/gadget/f_mass_storage.c index b963939..0cd8f21 100644 --- a/drivers/usb/gadget/f_mass_storage.c +++ b/drivers/usb/gadget/f_mass_storage.c @@ -2342,6 +2342,7 @@ static void handle_exception(struct fsg_common *common) struct fsg_buffhd *bh; enum fsg_state old_state; struct fsg_lun *curlun; + struct fsg_dev *new_fsg; unsigned intexception_req_tag; /* @@ -2421,6 +2422,7 @@ static void handle_exception(struct fsg_common *common) } common-state = FSG_STATE_IDLE; } + new_fsg = common-new_fsg; spin_unlock_irq(common-lock); /* Carry out any extra actions required for the exception */ @@ -2460,8 +2462,8 @@ static void handle_exception(struct fsg_common *common) break; case FSG_STATE_CONFIG_CHANGE: - do_set_interface(common, common-new_fsg); - if (common-new_fsg) + do_set_interface(common, new_fsg); + if (new_fsg) usb_composite_setup_continue(common-cdev); break; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tools: Cache register accesses for unwind processing
Commit-ID: 0c4e774fad0202b91dea8d99c04e9bdf2c2c6647
Gitweb: http://git.kernel.org/tip/0c4e774fad0202b91dea8d99c04e9bdf2c2c6647
Author: Jiri Olsa jo...@kernel.org
AuthorDate: Thu, 17 Apr 2014 19:39:10 +0200
Committer: Jiri Olsa jo...@kernel.org
CommitDate: Thu, 12 Jun 2014 16:53:19 +0200
perf tools: Cache register accesses for unwind processing
Caching registers value into an array. Got about 4% speed up
of perf_reg_value function for report command processing
dwarf unwind stacks.
Output from report over 1.5 GB data with DWARF unwind stacks:
(TODO fix perf diff)
current code:
5.84% perf perf [.] perf_reg_value
change:
1.94% perf perf [.] perf_reg_value
And little bit of overall speed up:
(perf stat -r 5 -e '{cycles,instructions}:u' ...)
current code:
310,298,611,754 cycles ( +- 0.33% )
439,669,689,341 instructions ( +- 0.03% )
188.656753166 seconds time elapsed( +- 0.82% )
change:
291,315,329,878 cycles ( +- 0.22% )
391,763,485,304 instructions ( +- 0.03% )
180.742249687 seconds time elapsed( +- 0.64% )
Acked-by: Namhyung Kim namhy...@kernel.org
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link:
http://lkml.kernel.org/r/1401892622-30848-2-git-send-email-jo...@kernel.org
Signed-off-by: Jiri Olsa jo...@kernel.org
---
tools/perf/util/event.h | 5 +
tools/perf/util/perf_regs.c | 10 +-
tools/perf/util/perf_regs.h | 4 +++-
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 9ba2eb3..e5dd40a 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -7,6 +7,7 @@
#include ../perf.h
#include map.h
#include build-id.h
+#include perf_regs.h
struct mmap_event {
struct perf_event_header header;
@@ -89,6 +90,10 @@ struct regs_dump {
u64 abi;
u64 mask;
u64 *regs;
+
+ /* Cached values/mask filled by first register access. */
+ u64 cache_regs[PERF_REGS_MAX];
+ u64 cache_mask;
};
struct stack_dump {
diff --git a/tools/perf/util/perf_regs.c b/tools/perf/util/perf_regs.c
index a3539ef..43168fb 100644
--- a/tools/perf/util/perf_regs.c
+++ b/tools/perf/util/perf_regs.c
@@ -1,11 +1,15 @@
#include errno.h
#include perf_regs.h
+#include event.h
int perf_reg_value(u64 *valp, struct regs_dump *regs, int id)
{
int i, idx = 0;
u64 mask = regs-mask;
+ if (regs-cache_mask (1 id))
+ goto out;
+
if (!(mask (1 id)))
return -EINVAL;
@@ -14,6 +18,10 @@ int perf_reg_value(u64 *valp, struct regs_dump *regs, int id)
idx++;
}
- *valp = regs-regs[idx];
+ regs-cache_mask |= (1 id);
+ regs-cache_regs[id] = regs-regs[idx];
+
+out:
+ *valp = regs-cache_regs[id];
return 0;
}
diff --git a/tools/perf/util/perf_regs.h b/tools/perf/util/perf_regs.h
index 79c78f7..980dbf7 100644
--- a/tools/perf/util/perf_regs.h
+++ b/tools/perf/util/perf_regs.h
@@ -2,7 +2,8 @@
#define __PERF_REGS_H
#include linux/types.h
-#include event.h
+
+struct regs_dump;
#ifdef HAVE_PERF_REGS_SUPPORT
#include perf_regs.h
@@ -11,6 +12,7 @@ int perf_reg_value(u64 *valp, struct regs_dump *regs, int id);
#else
#define PERF_REGS_MASK 0
+#define PERF_REGS_MAX 0
static inline const char *perf_reg_name(int id __maybe_unused)
{
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tools: Add data_fd into dso object
Commit-ID: 53fa8eaa093ad87eb59379de059e76d735a5de45
Gitweb: http://git.kernel.org/tip/53fa8eaa093ad87eb59379de059e76d735a5de45
Author: Jiri Olsa jo...@kernel.org
AuthorDate: Mon, 28 Apr 2014 16:43:43 +0200
Committer: Jiri Olsa jo...@kernel.org
CommitDate: Thu, 12 Jun 2014 16:53:19 +0200
perf tools: Add data_fd into dso object
Adding data_fd into dso object so we could handle caching
of opened dso file data descriptors coming int next patches.
Adding dso__data_close interface to keep the data_fd updated
when the descriptor is closed.
Acked-by: Namhyung Kim namhy...@kernel.org
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link:
http://lkml.kernel.org/r/1401892622-30848-4-git-send-email-jo...@kernel.org
Signed-off-by: Jiri Olsa jo...@kernel.org
---
tools/perf/util/dso.c | 23 +++
tools/perf/util/dso.h | 3 +++
tools/perf/util/unwind-libunwind.c | 4 ++--
3 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 1c3cdaf..5acb4b8 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -159,6 +159,14 @@ static int open_dso(struct dso *dso, struct machine
*machine)
return fd;
}
+void dso__data_close(struct dso *dso)
+{
+ if (dso-data.fd = 0) {
+ close(dso-data.fd);
+ dso-data.fd = -1;
+ }
+}
+
int dso__data_fd(struct dso *dso, struct machine *machine)
{
enum dso_binary_type binary_type_data[] = {
@@ -168,8 +176,13 @@ int dso__data_fd(struct dso *dso, struct machine *machine)
};
int i = 0;
- if (dso-binary_type != DSO_BINARY_TYPE__NOT_FOUND)
- return open_dso(dso, machine);
+ if (dso-data.fd = 0)
+ return dso-data.fd;
+
+ if (dso-binary_type != DSO_BINARY_TYPE__NOT_FOUND) {
+ dso-data.fd = open_dso(dso, machine);
+ return dso-data.fd;
+ }
do {
int fd;
@@ -178,7 +191,7 @@ int dso__data_fd(struct dso *dso, struct machine *machine)
fd = open_dso(dso, machine);
if (fd = 0)
- return fd;
+ return dso-data.fd = fd;
} while (dso-binary_type != DSO_BINARY_TYPE__NOT_FOUND);
@@ -301,7 +314,7 @@ dso_cache__read(struct dso *dso, struct machine *machine,
if (ret = 0)
free(cache);
- close(fd);
+ dso__data_close(dso);
return ret;
}
@@ -474,6 +487,7 @@ struct dso *dso__new(const char *name)
for (i = 0; i MAP__NR_TYPES; ++i)
dso-symbols[i] = dso-symbol_names[i] = RB_ROOT;
dso-data.cache = RB_ROOT;
+ dso-data.fd = -1;
dso-symtab_type = DSO_BINARY_TYPE__NOT_FOUND;
dso-binary_type = DSO_BINARY_TYPE__NOT_FOUND;
dso-loaded = 0;
@@ -506,6 +520,7 @@ void dso__delete(struct dso *dso)
dso-long_name_allocated = false;
}
+ dso__data_close(dso);
dso_cache__free(dso-data.cache);
dso__free_a2l(dso);
zfree(dso-symsrc_filename);
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index 7637fdd..e48dcf5 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -102,6 +102,7 @@ struct dso {
/* dso data file */
struct {
struct rb_root cache;
+ int fd;
} data;
char name[0];
@@ -147,6 +148,8 @@ int dso__read_binary_type_filename(const struct dso *dso,
enum dso_binary_type t
char *root_dir, char *filename, size_t size);
int dso__data_fd(struct dso *dso, struct machine *machine);
+void dso__data_close(struct dso *dso);
+
ssize_t dso__data_read_offset(struct dso *dso, struct machine *machine,
u64 offset, u8 *data, ssize_t size);
ssize_t dso__data_read_addr(struct dso *dso, struct map *map,
diff --git a/tools/perf/util/unwind-libunwind.c
b/tools/perf/util/unwind-libunwind.c
index bd5768d..4f8dd9e 100644
--- a/tools/perf/util/unwind-libunwind.c
+++ b/tools/perf/util/unwind-libunwind.c
@@ -250,7 +250,7 @@ static int read_unwind_spec_eh_frame(struct dso *dso,
struct machine *machine,
/* Check the .eh_frame section for unwinding info */
offset = elf_section_offset(fd, .eh_frame_hdr);
- close(fd);
+ dso__data_close(dso);
if (offset)
ret = unwind_spec_ehframe(dso, machine, offset,
@@ -271,7 +271,7 @@ static int read_unwind_spec_debug_frame(struct dso *dso,
/* Check the .debug_frame section for
[tip:perf/core] perf tools: Add global count of opened dso objects
Commit-ID: bda6ee4a94d1e1be0c1428d37bc0d3da2e5793ad
Gitweb: http://git.kernel.org/tip/bda6ee4a94d1e1be0c1428d37bc0d3da2e5793ad
Author: Jiri Olsa jo...@kernel.org
AuthorDate: Wed, 30 Apr 2014 15:25:10 +0200
Committer: Jiri Olsa jo...@kernel.org
CommitDate: Thu, 12 Jun 2014 16:53:20 +0200
perf tools: Add global count of opened dso objects
Adding global count of opened dso objects so we could
properly limit the number of opened dso data file
descriptors.
Acked-by: Namhyung Kim namhy...@kernel.org
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link:
http://lkml.kernel.org/r/1401892622-30848-6-git-send-email-jo...@kernel.org
Signed-off-by: Jiri Olsa jo...@kernel.org
---
tools/perf/util/dso.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 5d7c7bc..76e5c13 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -1,3 +1,4 @@
+#include asm/bug.h
#include symbol.h
#include dso.h
#include machine.h
@@ -137,18 +138,23 @@ int dso__read_binary_type_filename(const struct dso *dso,
}
/*
- * Global list of open DSOs.
+ * Global list of open DSOs and the counter.
*/
static LIST_HEAD(dso__data_open);
+static long dso__data_open_cnt;
static void dso__list_add(struct dso *dso)
{
list_add_tail(dso-data.open_entry, dso__data_open);
+ dso__data_open_cnt++;
}
static void dso__list_del(struct dso *dso)
{
list_del(dso-data.open_entry);
+ WARN_ONCE(dso__data_open_cnt = 0,
+ DSO data fd counter out of bounds.);
+ dso__data_open_cnt--;
}
static int __open_dso(struct dso *dso, struct machine *machine)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf record: Fix to honor user freq/ interval properly
Commit-ID: 17314e2385c6627fcab4b8f97bd6668bb63495c0
Gitweb: http://git.kernel.org/tip/17314e2385c6627fcab4b8f97bd6668bb63495c0
Author: Namhyung Kim namhy...@kernel.org
AuthorDate: Mon, 9 Jun 2014 14:43:37 +0900
Committer: Jiri Olsa jo...@kernel.org
CommitDate: Thu, 12 Jun 2014 16:53:18 +0200
perf record: Fix to honor user freq/interval properly
When configuring event perf checked a wrong condition that user
specified both of freq (-F) and period (-c) or the event has no
default value. This worked because most of events don't have default
value and only tracepoint events have default of 1 (and it's not
desirable to change it for those events).
However, Andi's downloadable event patch changes the situation so it
cannot change the value for those events. Fix it by allowing override
the default value if user gives one of the options.
$ perf record -a -e uops_retired.all -F 4000 sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.325 MB perf.data (~14185 samples) ]
$ perf evlist -F
cpu/uops_retired.all/: sample_freq=4000
Signed-off-by: Namhyung Kim namhy...@kernel.org
Cc: Andi Kleen a...@firstfloor.org
Cc: Frederic Weisbecker fweis...@gmail.com
Link:
http://lkml.kernel.org/r/1402292617-26278-1-git-send-email-namhy...@kernel.org
Signed-off-by: Jiri Olsa jo...@kernel.org
---
tools/perf/util/evsel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 21154da..8606175 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -589,10 +589,10 @@ void perf_evsel__config(struct perf_evsel *evsel, struct
record_opts *opts)
}
/*
-* We default some events to a 1 default interval. But keep
+* We default some events to have a default interval. But keep
* it a weak assumption overridable by the user.
*/
- if (!attr-sample_period || (opts-user_freq != UINT_MAX
+ if (!attr-sample_period || (opts-user_freq != UINT_MAX ||
opts-user_interval != ULLONG_MAX)) {
if (opts-freq) {
perf_evsel__set_sample_bit(evsel, PERIOD);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tools: Add global list of opened dso objects
Commit-ID: eba5102d2f0b4117edd089f2d882d9386025c829
Gitweb: http://git.kernel.org/tip/eba5102d2f0b4117edd089f2d882d9386025c829
Author: Jiri Olsa jo...@kernel.org
AuthorDate: Wed, 30 Apr 2014 15:00:59 +0200
Committer: Jiri Olsa jo...@kernel.org
CommitDate: Thu, 12 Jun 2014 16:53:20 +0200
perf tools: Add global list of opened dso objects
Adding global list of opened dso objects, so we can
track them and use the list for caching dso data file
descriptors.
Acked-by: Namhyung Kim namhy...@kernel.org
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link:
http://lkml.kernel.org/r/1401892622-30848-5-git-send-email-jo...@kernel.org
Signed-off-by: Jiri Olsa jo...@kernel.org
---
tools/perf/util/dso.c | 41 +++--
tools/perf/util/dso.h | 1 +
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 5acb4b8..5d7c7bc 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -136,7 +136,22 @@ int dso__read_binary_type_filename(const struct dso *dso,
return ret;
}
-static int open_dso(struct dso *dso, struct machine *machine)
+/*
+ * Global list of open DSOs.
+ */
+static LIST_HEAD(dso__data_open);
+
+static void dso__list_add(struct dso *dso)
+{
+ list_add_tail(dso-data.open_entry, dso__data_open);
+}
+
+static void dso__list_del(struct dso *dso)
+{
+ list_del(dso-data.open_entry);
+}
+
+static int __open_dso(struct dso *dso, struct machine *machine)
{
int fd;
char *root_dir = (char *);
@@ -159,14 +174,35 @@ static int open_dso(struct dso *dso, struct machine
*machine)
return fd;
}
-void dso__data_close(struct dso *dso)
+static int open_dso(struct dso *dso, struct machine *machine)
+{
+ int fd = __open_dso(dso, machine);
+
+ if (fd 0)
+ dso__list_add(dso);
+
+ return fd;
+}
+
+static void close_data_fd(struct dso *dso)
{
if (dso-data.fd = 0) {
close(dso-data.fd);
dso-data.fd = -1;
+ dso__list_del(dso);
}
}
+static void close_dso(struct dso *dso)
+{
+ close_data_fd(dso);
+}
+
+void dso__data_close(struct dso *dso)
+{
+ close_dso(dso);
+}
+
int dso__data_fd(struct dso *dso, struct machine *machine)
{
enum dso_binary_type binary_type_data[] = {
@@ -499,6 +535,7 @@ struct dso *dso__new(const char *name)
dso-kernel = DSO_TYPE_USER;
dso-needs_swap = DSO_SWAP__UNSET;
INIT_LIST_HEAD(dso-node);
+ INIT_LIST_HEAD(dso-data.open_entry);
}
return dso;
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index e48dcf5..90988bf 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -103,6 +103,7 @@ struct dso {
struct {
struct rb_root cache;
int fd;
+ struct list_head open_entry;
} data;
char name[0];
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tools: Add file size check and factor dso__data_read_offset
Commit-ID: c3fbd2a606c5f88de0079b027727a1fb0ae27b65
Gitweb: http://git.kernel.org/tip/c3fbd2a606c5f88de0079b027727a1fb0ae27b65
Author: Jiri Olsa jo...@kernel.org
AuthorDate: Wed, 7 May 2014 18:51:41 +0200
Committer: Jiri Olsa jo...@kernel.org
CommitDate: Thu, 12 Jun 2014 16:53:21 +0200
perf tools: Add file size check and factor dso__data_read_offset
Adding file size check, because the lseek will succeed for
any offset behind file size and thus succeed when it was
expected to fail.
Factoring the code to check the offset against file size
earlier in the flow.
Acked-by: Namhyung Kim namhy...@kernel.org
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link:
http://lkml.kernel.org/r/1401892622-30848-8-git-send-email-jo...@kernel.org
Signed-off-by: Jiri Olsa jo...@kernel.org
---
tools/perf/util/dso.c | 64 +++
tools/perf/util/dso.h | 1 +
2 files changed, 50 insertions(+), 15 deletions(-)
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index fbf6cc9..db63438 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -205,6 +205,7 @@ static void close_data_fd(struct dso *dso)
if (dso-data.fd = 0) {
close(dso-data.fd);
dso-data.fd = -1;
+ dso-data.file_size = 0;
dso__list_del(dso);
}
}
@@ -373,16 +374,10 @@ dso_cache__memcpy(struct dso_cache *cache, u64 offset,
}
static ssize_t
-dso_cache__read(struct dso *dso, struct machine *machine,
-u64 offset, u8 *data, ssize_t size)
+dso_cache__read(struct dso *dso, u64 offset, u8 *data, ssize_t size)
{
struct dso_cache *cache;
ssize_t ret;
- int fd;
-
- fd = dso__data_fd(dso, machine);
- if (fd 0)
- return -1;
do {
u64 cache_offset;
@@ -396,10 +391,10 @@ dso_cache__read(struct dso *dso, struct machine *machine,
cache_offset = offset DSO__DATA_CACHE_MASK;
ret = -EINVAL;
- if (-1 == lseek(fd, cache_offset, SEEK_SET))
+ if (-1 == lseek(dso-data.fd, cache_offset, SEEK_SET))
break;
- ret = read(fd, cache-data, DSO__DATA_CACHE_SIZE);
+ ret = read(dso-data.fd, cache-data, DSO__DATA_CACHE_SIZE);
if (ret = 0)
break;
@@ -417,8 +412,8 @@ dso_cache__read(struct dso *dso, struct machine *machine,
return ret;
}
-static ssize_t dso_cache_read(struct dso *dso, struct machine *machine,
- u64 offset, u8 *data, ssize_t size)
+static ssize_t dso_cache_read(struct dso *dso, u64 offset,
+ u8 *data, ssize_t size)
{
struct dso_cache *cache;
@@ -426,11 +421,10 @@ static ssize_t dso_cache_read(struct dso *dso, struct
machine *machine,
if (cache)
return dso_cache__memcpy(cache, offset, data, size);
else
- return dso_cache__read(dso, machine, offset, data, size);
+ return dso_cache__read(dso, offset, data, size);
}
-ssize_t dso__data_read_offset(struct dso *dso, struct machine *machine,
- u64 offset, u8 *data, ssize_t size)
+static ssize_t cached_read(struct dso *dso, u64 offset, u8 *data, ssize_t size)
{
ssize_t r = 0;
u8 *p = data;
@@ -438,7 +432,7 @@ ssize_t dso__data_read_offset(struct dso *dso, struct
machine *machine,
do {
ssize_t ret;
- ret = dso_cache_read(dso, machine, offset, p, size);
+ ret = dso_cache_read(dso, offset, p, size);
if (ret 0)
return ret;
@@ -458,6 +452,46 @@ ssize_t dso__data_read_offset(struct dso *dso, struct
machine *machine,
return r;
}
+static int data_file_size(struct dso *dso)
+{
+ struct stat st;
+
+ if (!dso-data.file_size) {
+ if (fstat(dso-data.fd, st)) {
+ pr_err(dso mmap failed, fstat: %s\n, strerror(errno));
+ return -1;
+ }
+ dso-data.file_size = st.st_size;
+ }
+
+ return 0;
+}
+
+static ssize_t data_read_offset(struct dso *dso, u64 offset,
+ u8 *data, ssize_t size)
+{
+ if (data_file_size(dso))
+ return -1;
+
+ /* Check the offset sanity. */
+ if (offset dso-data.file_size)
+ return -1;
+
+ if (offset + size offset)
+ return -1;
+
+ return cached_read(dso, offset, data, size);
+}
+
+ssize_t dso__data_read_offset(struct dso *dso, struct machine
[tip:perf/core] perf tools: Cache dso data file descriptor
Commit-ID: c658045197814b7d762662f9aa9f652379121a03
Gitweb: http://git.kernel.org/tip/c658045197814b7d762662f9aa9f652379121a03
Author: Jiri Olsa jo...@kernel.org
AuthorDate: Wed, 30 Apr 2014 15:47:27 +0200
Committer: Jiri Olsa jo...@kernel.org
CommitDate: Thu, 12 Jun 2014 16:53:20 +0200
perf tools: Cache dso data file descriptor
Caching dso data file descriptors to avoid expensive re-opens
especially during DWARF unwind.
We keep dsos data file descriptors open until their count reaches
the half of the current fd open limit (RLIMIT_NOFILE). In this case
we close file descriptor of the first opened dso object.
We've got overall speedup (~27% for my workload) of report:
'perf report --stdio -i perf-test.data' (3 runs)
(perf-test.data size was around 12GB)
current code:
545,640,944,228 cycles ( +- 0.53% )
785,255,798,320 instructions ( +- 0.03% )
366.340910010 seconds time elapsed( +- 3.65% )
after change:
435,895,036,114 cycles ( +- 0.26% )
636,790,271,176 instructions ( +- 0.04% )
266.481463387 seconds time elapsed( +- 0.13% )
Acked-by: Namhyung Kim namhy...@kernel.org
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link:
http://lkml.kernel.org/r/1401892622-30848-7-git-send-email-jo...@kernel.org
Signed-off-by: Jiri Olsa jo...@kernel.org
---
tools/perf/util/dso.c | 61 --
tools/perf/util/unwind-libunwind.c | 2 --
2 files changed, 59 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 76e5c13..fbf6cc9 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -1,4 +1,6 @@
#include asm/bug.h
+#include sys/time.h
+#include sys/resource.h
#include symbol.h
#include dso.h
#include machine.h
@@ -180,12 +182,20 @@ static int __open_dso(struct dso *dso, struct machine
*machine)
return fd;
}
+static void check_data_close(void);
+
static int open_dso(struct dso *dso, struct machine *machine)
{
int fd = __open_dso(dso, machine);
- if (fd 0)
+ if (fd 0) {
dso__list_add(dso);
+ /*
+* Check if we crossed the allowed number
+* of opened DSOs and close one if needed.
+*/
+ check_data_close();
+ }
return fd;
}
@@ -204,6 +214,54 @@ static void close_dso(struct dso *dso)
close_data_fd(dso);
}
+static void close_first_dso(void)
+{
+ struct dso *dso;
+
+ dso = list_first_entry(dso__data_open, struct dso, data.open_entry);
+ close_dso(dso);
+}
+
+static rlim_t get_fd_limit(void)
+{
+ struct rlimit l;
+ rlim_t limit = 0;
+
+ /* Allow half of the current open fd limit. */
+ if (getrlimit(RLIMIT_NOFILE, l) == 0) {
+ if (l.rlim_cur == RLIM_INFINITY)
+ limit = l.rlim_cur;
+ else
+ limit = l.rlim_cur / 2;
+ } else {
+ pr_err(failed to get fd limit\n);
+ limit = 1;
+ }
+
+ return limit;
+}
+
+static bool may_cache_fd(void)
+{
+ static rlim_t limit;
+
+ if (!limit)
+ limit = get_fd_limit();
+
+ if (limit == RLIM_INFINITY)
+ return true;
+
+ return limit (rlim_t) dso__data_open_cnt;
+}
+
+static void check_data_close(void)
+{
+ bool cache_fd = may_cache_fd();
+
+ if (!cache_fd)
+ close_first_dso();
+}
+
void dso__data_close(struct dso *dso)
{
close_dso(dso);
@@ -356,7 +414,6 @@ dso_cache__read(struct dso *dso, struct machine *machine,
if (ret = 0)
free(cache);
- dso__data_close(dso);
return ret;
}
diff --git a/tools/perf/util/unwind-libunwind.c
b/tools/perf/util/unwind-libunwind.c
index 4f8dd9e..25578b9 100644
--- a/tools/perf/util/unwind-libunwind.c
+++ b/tools/perf/util/unwind-libunwind.c
@@ -250,7 +250,6 @@ static int read_unwind_spec_eh_frame(struct dso *dso,
struct machine *machine,
/* Check the .eh_frame section for unwinding info */
offset = elf_section_offset(fd, .eh_frame_hdr);
- dso__data_close(dso);
if (offset)
ret = unwind_spec_ehframe(dso, machine, offset,
@@ -271,7 +270,6 @@ static int read_unwind_spec_debug_frame(struct dso *dso,
/* Check the .debug_frame section for unwinding info */
*offset = elf_section_offset(fd, .debug_frame);
- dso__data_close(dso);
if (*offset)
return 0;
--
To unsubscribe from this list:
[tip:perf/core] perf tools: Add dso__data_* interface descriptons
Commit-ID: c1f9aa0a61bde512a68060883d1c3c1955a546ea
Gitweb: http://git.kernel.org/tip/c1f9aa0a61bde512a68060883d1c3c1955a546ea
Author: Jiri Olsa jo...@kernel.org
AuthorDate: Wed, 7 May 2014 21:09:59 +0200
Committer: Jiri Olsa jo...@kernel.org
CommitDate: Thu, 12 Jun 2014 16:53:22 +0200
perf tools: Add dso__data_* interface descriptons
Adding descriptions/explanations for dso__data_* interface
functions.
Acked-by: Namhyung Kim namhy...@kernel.org
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link:
http://lkml.kernel.org/r/1401892622-30848-10-git-send-email-jo...@kernel.org
Signed-off-by: Jiri Olsa jo...@kernel.org
---
tools/perf/util/dso.c | 59 +++
tools/perf/util/dso.h | 38 +
2 files changed, 97 insertions(+)
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index c30752c..819f104 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -205,6 +205,13 @@ static int __open_dso(struct dso *dso, struct machine
*machine)
static void check_data_close(void);
+/**
+ * dso_close - Open DSO data file
+ * @dso: dso object
+ *
+ * Open @dso's data file descriptor and updates
+ * list/count of open DSO objects.
+ */
static int open_dso(struct dso *dso, struct machine *machine)
{
int fd = __open_dso(dso, machine);
@@ -231,6 +238,13 @@ static void close_data_fd(struct dso *dso)
}
}
+/**
+ * dso_close - Close DSO data file
+ * @dso: dso object
+ *
+ * Close @dso's data file descriptor and updates
+ * list/count of open DSO objects.
+ */
static void close_dso(struct dso *dso)
{
close_data_fd(dso);
@@ -276,6 +290,11 @@ static bool may_cache_fd(void)
return limit (rlim_t) dso__data_open_cnt;
}
+/*
+ * Check and close LRU dso if we crossed allowed limit
+ * for opened dso file descriptors. The limit is half
+ * of the RLIMIT_NOFILE files opened.
+*/
static void check_data_close(void)
{
bool cache_fd = may_cache_fd();
@@ -284,11 +303,25 @@ static void check_data_close(void)
close_first_dso();
}
+/**
+ * dso__data_close - Close DSO data file
+ * @dso: dso object
+ *
+ * External interface to close @dso's data file descriptor.
+ */
void dso__data_close(struct dso *dso)
{
close_dso(dso);
}
+/**
+ * dso__data_fd - Get dso's data file descriptor
+ * @dso: dso object
+ * @machine: machine object
+ *
+ * External interface to find dso's file, open it and
+ * returns file descriptor.
+ */
int dso__data_fd(struct dso *dso, struct machine *machine)
{
enum dso_binary_type binary_type_data[] = {
@@ -445,6 +478,11 @@ static ssize_t dso_cache_read(struct dso *dso, u64 offset,
return dso_cache__read(dso, offset, data, size);
}
+/*
+ * Reads and caches dso data DSO__DATA_CACHE_SIZE size chunks
+ * in the rb_tree. Any read to already cached data is served
+ * by cached data.
+ */
static ssize_t cached_read(struct dso *dso, u64 offset, u8 *data, ssize_t size)
{
ssize_t r = 0;
@@ -504,6 +542,17 @@ static ssize_t data_read_offset(struct dso *dso, u64
offset,
return cached_read(dso, offset, data, size);
}
+/**
+ * dso__data_read_offset - Read data from dso file offset
+ * @dso: dso object
+ * @machine: machine object
+ * @offset: file offset
+ * @data: buffer to store data
+ * @size: size of the @data buffer
+ *
+ * External interface to read data from dso file offset. Open
+ * dso data file and use cached_read to get the data.
+ */
ssize_t dso__data_read_offset(struct dso *dso, struct machine *machine,
u64 offset, u8 *data, ssize_t size)
{
@@ -513,6 +562,16 @@ ssize_t dso__data_read_offset(struct dso *dso, struct
machine *machine,
return data_read_offset(dso, offset, data, size);
}
+/**
+ * dso__data_read_addr - Read data from dso address
+ * @dso: dso object
+ * @machine: machine object
+ * @add: virtual memory address
+ * @data: buffer to store data
+ * @size: size of the @data buffer
+ *
+ * External interface to read data from dso address.
+ */
ssize_t dso__data_read_addr(struct dso *dso, struct map *map,
struct machine *machine, u64 addr,
u8 *data, ssize_t size)
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index da47b13..ad553ba 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -149,6 +149,44 @@ char dso__symtab_origin(const struct dso *dso);
int dso__read_binary_type_filename(const struct dso *dso, enum dso_binary_type
type,
char *root_dir, char *filename, size_t size);
+/*
+ * The dso__data_* external interface
[tip:perf/core] perf tools: Allow to close dso fd in case of open failure
Commit-ID: a08cae03f430b971afa508a32662dc476d42d8cb
Gitweb: http://git.kernel.org/tip/a08cae03f430b971afa508a32662dc476d42d8cb
Author: Jiri Olsa jo...@kernel.org
AuthorDate: Wed, 7 May 2014 21:35:02 +0200
Committer: Jiri Olsa jo...@kernel.org
CommitDate: Thu, 12 Jun 2014 16:53:21 +0200
perf tools: Allow to close dso fd in case of open failure
Adding do_open function that tries to close opened
dso objects in case we fail to open the dso due to
to crossing the allowed RLIMIT_NOFILE limit.
Acked-by: Namhyung Kim namhy...@kernel.org
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link:
http://lkml.kernel.org/r/1401892622-30848-9-git-send-email-jo...@kernel.org
Signed-off-by: Jiri Olsa jo...@kernel.org
---
tools/perf/util/dso.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index db63438..c30752c 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -159,6 +159,27 @@ static void dso__list_del(struct dso *dso)
dso__data_open_cnt--;
}
+static void close_first_dso(void);
+
+static int do_open(char *name)
+{
+ int fd;
+
+ do {
+ fd = open(name, O_RDONLY);
+ if (fd = 0)
+ return fd;
+
+ pr_debug(dso open failed, mmap: %s\n, strerror(errno));
+ if (!dso__data_open_cnt || errno != EMFILE)
+ break;
+
+ close_first_dso();
+ } while (1);
+
+ return -1;
+}
+
static int __open_dso(struct dso *dso, struct machine *machine)
{
int fd;
@@ -177,7 +198,7 @@ static int __open_dso(struct dso *dso, struct machine
*machine)
return -EINVAL;
}
- fd = open(name, O_RDONLY);
+ fd = do_open(name);
free(name);
return fd;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tests: Add test for closing dso objects on EMFILE error
Commit-ID: 45dc1bb5c1d47f9519e2101f6b073bb4bb1d1f99
Gitweb: http://git.kernel.org/tip/45dc1bb5c1d47f9519e2101f6b073bb4bb1d1f99
Author: Jiri Olsa jo...@kernel.org
AuthorDate: Mon, 12 May 2014 14:50:03 +0200
Committer: Jiri Olsa jo...@kernel.org
CommitDate: Thu, 12 Jun 2014 16:53:23 +0200
perf tests: Add test for closing dso objects on EMFILE error
Testing that perf properly closes opened dso objects
and tries to reopen in case we run out of allowed file
descriptors for dso data.
Acked-by: Namhyung Kim namhy...@kernel.org
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Reviewed by: David Ahern dsah...@gmail.com
Link:
http://lkml.kernel.org/r/1401892622-30848-14-git-send-email-jo...@kernel.org
Signed-off-by: Jiri Olsa jo...@kernel.org
---
tools/perf/tests/builtin-test.c | 4 +++
tools/perf/tests/dso-data.c | 73 +
tools/perf/tests/tests.h| 1 +
3 files changed, 78 insertions(+)
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index b8a6358..6f8b01b 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -60,6 +60,10 @@ static struct test {
.func = test__dso_data_cache,
},
{
+ .desc = Test dso data reopen,
+ .func = test__dso_data_reopen,
+ },
+ {
.desc = roundtrip evsel-name check,
.func = test__perf_evsel__roundtrip_name_test,
},
diff --git a/tools/perf/tests/dso-data.c b/tools/perf/tests/dso-data.c
index 2d30014..630808c 100644
--- a/tools/perf/tests/dso-data.c
+++ b/tools/perf/tests/dso-data.c
@@ -283,3 +283,76 @@ int test__dso_data_cache(void)
TEST_ASSERT_VAL(failed leadking files, nr == nr_end);
return 0;
}
+
+int test__dso_data_reopen(void)
+{
+ struct machine machine;
+ long nr_end, nr = open_files_cnt();
+ int fd, fd_extra;
+
+#define dso_0 (dsos[0])
+#define dso_1 (dsos[1])
+#define dso_2 (dsos[2])
+
+ memset(machine, 0, sizeof(machine));
+
+ /*
+* Test scenario:
+* - create 3 dso objects
+* - set process file descriptor limit to current
+* files count + 3
+* - test that the first dso gets closed when we
+* reach the files count limit
+*/
+
+ /* Make sure we are able to open 3 fds anyway */
+ TEST_ASSERT_VAL(failed to set file limit,
+ !set_fd_limit((nr + 3)));
+
+ TEST_ASSERT_VAL(failed to create dsos\n, !dsos__create(3,
TEST_FILE_SIZE));
+
+ /* open dso_0 */
+ fd = dso__data_fd(dso_0, machine);
+ TEST_ASSERT_VAL(failed to get fd, fd 0);
+
+ /* open dso_1 */
+ fd = dso__data_fd(dso_1, machine);
+ TEST_ASSERT_VAL(failed to get fd, fd 0);
+
+ /*
+* open extra file descriptor and we just
+* reached the files count limit
+*/
+ fd_extra = open(/dev/null, O_RDONLY);
+ TEST_ASSERT_VAL(failed to open extra fd, fd_extra 0);
+
+ /* open dso_2 */
+ fd = dso__data_fd(dso_2, machine);
+ TEST_ASSERT_VAL(failed to get fd, fd 0);
+
+ /*
+* dso_0 should get closed, because we reached
+* the file descriptor limit
+*/
+ TEST_ASSERT_VAL(failed to close dso_0, dso_0-data.fd == -1);
+
+ /* open dso_0 */
+ fd = dso__data_fd(dso_0, machine);
+ TEST_ASSERT_VAL(failed to get fd, fd 0);
+
+ /*
+* dso_1 should get closed, because we reached
+* the file descriptor limit
+*/
+ TEST_ASSERT_VAL(failed to close dso_1, dso_1-data.fd == -1);
+
+ /* cleanup everything */
+ close(fd_extra);
+ dsos__delete(3);
+
+ /* Make sure we did not leak any file descriptor. */
+ nr_end = open_files_cnt();
+ pr_debug(nr start %ld, nr stop %ld\n, nr, nr_end);
+ TEST_ASSERT_VAL(failed leadking files, nr == nr_end);
+ return 0;
+}
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index ccc4deb..ed64790 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -29,6 +29,7 @@ int test__pmu(void);
int test__attr(void);
int test__dso_data(void);
int test__dso_data_cache(void);
+int test__dso_data_reopen(void);
int test__parse_events(void);
int test__hists_link(void);
int test__python_use(void);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tests: Add test for caching dso file descriptors
Commit-ID: 4ebbcb84b19b8472fb5b9c8be89b3d0ea17c902e
Gitweb: http://git.kernel.org/tip/4ebbcb84b19b8472fb5b9c8be89b3d0ea17c902e
Author: Jiri Olsa jo...@kernel.org
AuthorDate: Mon, 12 May 2014 14:43:53 +0200
Committer: Jiri Olsa jo...@kernel.org
CommitDate: Thu, 12 Jun 2014 16:53:22 +0200
perf tests: Add test for caching dso file descriptors
Adding test that setup test_dso_data__fd_limit and test
dso data file descriptors are cached appropriately.
Acked-by: Namhyung Kim namhy...@kernel.org
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link:
http://lkml.kernel.org/r/1401892622-30848-13-git-send-email-jo...@kernel.org
Signed-off-by: Jiri Olsa jo...@kernel.org
---
tools/perf/tests/builtin-test.c | 6 +-
tools/perf/tests/dso-data.c | 135 +++-
tools/perf/tests/tests.h| 1 +
3 files changed, 138 insertions(+), 4 deletions(-)
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 9677a5c..b8a6358 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -52,10 +52,14 @@ static struct test {
.func = test__pmu,
},
{
- .desc = Test dso data interface,
+ .desc = Test dso data read,
.func = test__dso_data,
},
{
+ .desc = Test dso data cache,
+ .func = test__dso_data_cache,
+ },
+ {
.desc = roundtrip evsel-name check,
.func = test__perf_evsel__roundtrip_name_test,
},
diff --git a/tools/perf/tests/dso-data.c b/tools/perf/tests/dso-data.c
index 7384381..2d30014 100644
--- a/tools/perf/tests/dso-data.c
+++ b/tools/perf/tests/dso-data.c
@@ -1,11 +1,12 @@
-#include util.h
-
#include stdlib.h
#include linux/types.h
#include sys/stat.h
#include fcntl.h
#include string.h
-
+#include sys/time.h
+#include sys/resource.h
+#include api/fs/fs.h
+#include util.h
#include machine.h
#include symbol.h
#include tests.h
@@ -154,3 +155,131 @@ int test__dso_data(void)
unlink(file);
return 0;
}
+
+static long open_files_cnt(void)
+{
+ char path[PATH_MAX];
+ struct dirent *dent;
+ DIR *dir;
+ long nr = 0;
+
+ scnprintf(path, PATH_MAX, %s/self/fd, procfs__mountpoint());
+ pr_debug(fd path: %s\n, path);
+
+ dir = opendir(path);
+ TEST_ASSERT_VAL(failed to open fd directory, dir);
+
+ while ((dent = readdir(dir)) != NULL) {
+ if (!strcmp(dent-d_name, .) ||
+ !strcmp(dent-d_name, ..))
+ continue;
+
+ nr++;
+ }
+
+ closedir(dir);
+ return nr - 1;
+}
+
+static struct dso **dsos;
+
+static int dsos__create(int cnt, int size)
+{
+ int i;
+
+ dsos = malloc(sizeof(dsos) * cnt);
+ TEST_ASSERT_VAL(failed to alloc dsos array, dsos);
+
+ for (i = 0; i cnt; i++) {
+ char *file;
+
+ file = test_file(size);
+ TEST_ASSERT_VAL(failed to get dso file, file);
+
+ dsos[i] = dso__new(file);
+ TEST_ASSERT_VAL(failed to get dso, dsos[i]);
+ }
+
+ return 0;
+}
+
+static void dsos__delete(int cnt)
+{
+ int i;
+
+ for (i = 0; i cnt; i++) {
+ struct dso *dso = dsos[i];
+
+ unlink(dso-name);
+ dso__delete(dso);
+ }
+
+ free(dsos);
+}
+
+static int set_fd_limit(int n)
+{
+ struct rlimit rlim;
+
+ if (getrlimit(RLIMIT_NOFILE, rlim))
+ return -1;
+
+ pr_debug(file limit %ld, new %d\n, (long) rlim.rlim_cur, n);
+
+ rlim.rlim_cur = n;
+ return setrlimit(RLIMIT_NOFILE, rlim);
+}
+
+int test__dso_data_cache(void)
+{
+ struct machine machine;
+ long nr_end, nr = open_files_cnt();
+ int dso_cnt, limit, i, fd;
+
+ memset(machine, 0, sizeof(machine));
+
+ /* set as system limit */
+ limit = nr * 4;
+ TEST_ASSERT_VAL(failed to set file limit, !set_fd_limit(limit));
+
+ /* and this is now our dso open FDs limit + 1 extra */
+ dso_cnt = limit / 2 + 1;
+ TEST_ASSERT_VAL(failed to create dsos\n,
+ !dsos__create(dso_cnt, TEST_FILE_SIZE));
+
+ for (i = 0; i (dso_cnt - 1); i++) {
+ struct dso *dso = dsos[i];
+
+ /*
+* Open dsos via dso__data_fd or dso__data_read_offset.
+* Both opens the data file and keep it open.
+*/
+ if (i % 2) {
+ fd = dso__data_fd(dso, machine);
+ TEST_ASSERT_VAL(failed to get fd, fd
[tip:perf/core] perf tests: Allow reuse of test_file function
Commit-ID: 822c45db6398a69879b0539f0819de02b813493c
Gitweb: http://git.kernel.org/tip/822c45db6398a69879b0539f0819de02b813493c
Author: Jiri Olsa jo...@kernel.org
AuthorDate: Sun, 4 May 2014 13:51:46 +0200
Committer: Jiri Olsa jo...@kernel.org
CommitDate: Thu, 12 Jun 2014 16:53:22 +0200
perf tests: Allow reuse of test_file function
Making the test_file function to be reusable for
new tests coming in following patches.
Also changing the template name of temp files to
/tmp/perf-test-XX to easily identify blame.
Acked-by: Namhyung Kim namhy...@kernel.org
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link:
http://lkml.kernel.org/r/1401892622-30848-12-git-send-email-jo...@kernel.org
Signed-off-by: Jiri Olsa jo...@kernel.org
---
tools/perf/tests/dso-data.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/perf/tests/dso-data.c b/tools/perf/tests/dso-data.c
index 3e6cb17..7384381 100644
--- a/tools/perf/tests/dso-data.c
+++ b/tools/perf/tests/dso-data.c
@@ -12,11 +12,15 @@
static char *test_file(int size)
{
- static char buf_templ[] = /tmp/test-XX;
+#define TEMPL /tmp/perf-test-XX
+ static char buf_templ[sizeof(TEMPL)];
char *templ = buf_templ;
int fd, i;
unsigned char *buf;
+ strcpy(buf_templ, TEMPL);
+#undef TEMPL
+
fd = mkstemp(templ);
if (fd 0) {
perror(mkstemp failed);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tests: Spawn child for each test
Commit-ID: 0d8a5faaf5a1087c7212a6f0d81920a93396414a
Gitweb: http://git.kernel.org/tip/0d8a5faaf5a1087c7212a6f0d81920a93396414a
Author: Jiri Olsa jo...@kernel.org
AuthorDate: Sat, 10 May 2014 17:22:30 +0200
Committer: Jiri Olsa jo...@kernel.org
CommitDate: Thu, 12 Jun 2014 16:53:22 +0200
perf tests: Spawn child for each test
In upcoming tests we will setup process limits, which
might affect other tests. Spawning child for each test
to prevent this.
Acked-by: Namhyung Kim namhy...@kernel.org
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Reviewed-by: David Ahern dsah...@gmail.com
Link:
http://lkml.kernel.org/r/1401892622-30848-11-git-send-email-jo...@kernel.org
Signed-off-by: Jiri Olsa jo...@kernel.org
---
tools/perf/tests/builtin-test.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 802e3cd..9677a5c 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -3,6 +3,8 @@
*
* Builtin regression testing command: ever growing number of sanity tests
*/
+#include unistd.h
+#include string.h
#include builtin.h
#include intlist.h
#include tests.h
@@ -172,6 +174,34 @@ static bool perf_test__matches(int curr, int argc, const
char *argv[])
return false;
}
+static int run_test(struct test *test)
+{
+ int status, err = -1, child = fork();
+
+ if (child 0) {
+ pr_err(failed to fork test: %s\n, strerror(errno));
+ return -1;
+ }
+
+ if (!child) {
+ pr_debug(test child forked, pid %d\n, getpid());
+ err = test-func();
+ exit(err);
+ }
+
+ wait(status);
+
+ if (WIFEXITED(status)) {
+ err = WEXITSTATUS(status);
+ pr_debug(test child finished with %d\n, err);
+ } else if (WIFSIGNALED(status)) {
+ err = -1;
+ pr_debug(test child interrupted\n);
+ }
+
+ return err;
+}
+
static int __cmd_test(int argc, const char *argv[], struct intlist *skiplist)
{
int i = 0;
@@ -200,7 +230,7 @@ static int __cmd_test(int argc, const char *argv[], struct
intlist *skiplist)
}
pr_debug(\n--- start ---\n);
- err = tests[curr].func();
+ err = run_test(tests[curr]);
pr_debug( end \n%s:, tests[curr].desc);
switch (err) {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: XFS WARN_ON in xfs_vm_writepage
[cc linux-mm] On Fri, Jun 13, 2014 at 01:16:31AM -0400, Dave Jones wrote: Just hit this on Linus' tree from earlier this afternoon.. WARNING: CPU: 3 PID: 19721 at fs/xfs/xfs_aops.c:971 xfs_vm_writepage+0x5ce/0x630 [xfs]() CPU: 3 PID: 19721 Comm: trinity-c61 Not tainted 3.15.0+ #3 0009 4f70ab82 8801d5ebf578 8373215c 8801d5ebf5b0 8306f7cd 88023dd543e0 ea000254a3c0 8801d5ebf820 ea000254a3e0 8801d5ebf728 Call Trace: [8373215c] dump_stack+0x4e/0x7a [8306f7cd] warn_slowpath_common+0x7d/0xa0 [8306f8fa] warn_slowpath_null+0x1a/0x20 [c023068e] xfs_vm_writepage+0x5ce/0x630 [xfs] [8373f1ab] ? preempt_count_sub+0xab/0x100 [83347315] ? __percpu_counter_add+0x85/0xc0 [8316f759] shrink_page_list+0x8f9/0xb90 [83170123] shrink_inactive_list+0x253/0x510 [83170c93] shrink_lruvec+0x563/0x6c0 [83170e2b] shrink_zone+0x3b/0x100 [831710e1] shrink_zones+0x1f1/0x3c0 [83171414] try_to_free_pages+0x164/0x380 [83163e52] __alloc_pages_nodemask+0x822/0xc90 [83169eb2] ? pagevec_lru_move_fn+0x122/0x140 [831abeff] alloc_pages_vma+0xaf/0x1c0 [8318a931] handle_mm_fault+0xa31/0xc50 [831845c0] ? follow_page_mask+0x1f0/0x320 [8318491b] __get_user_pages+0x22b/0x660 [831b5093] ? kmem_cache_alloc+0x183/0x210 [8318ce7e] __mlock_vma_pages_range+0x9e/0xd0 [8318d6ba] __mm_populate+0xca/0x180 [83179033] vm_mmap_pgoff+0xd3/0xe0 [8318fbd6] SyS_mmap_pgoff+0x116/0x2c0 [83011ced] ? syscall_trace_enter+0x14d/0x2a0 [830084c2] SyS_mmap+0x22/0x30 [837436ef] tracesys+0xdd/0xe2 970 if (WARN_ON_ONCE((current-flags (PF_MEMALLOC|PF_KSWAPD)) == 971 PF_MEMALLOC)) What were you running at the time? The XFS warning is there to indicate that memory reclaim is doing something it shouldn't (i.e. dirty page writeback from direct reclaim), so this is one for the mm folk to work out... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] Sound: tlv320aic31xx: Fixed Coding Style Issues
From: Shahina Shaik sharab.sh...@gmail.com
Fixed coding style issues of Missing Blank line after declaration
Signed-off-by: Shahina Shaik sharab.sh...@gmail.com
---
sound/soc/codecs/tlv320aic31xx.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c
index 2341910..a9c4a8b 100644
--- a/sound/soc/codecs/tlv320aic31xx.c
+++ b/sound/soc/codecs/tlv320aic31xx.c
@@ -329,6 +329,7 @@ static int aic31xx_wait_bits(struct aic31xx_priv *aic31xx,
unsigned int reg,
unsigned int bits;
int counter = count;
int ret = regmap_read(aic31xx-regmap, reg, bits);
+
while ((bits mask) != wbits counter !ret) {
usleep_range(sleep, sleep * 2);
ret = regmap_read(aic31xx-regmap, reg, bits);
@@ -435,6 +436,7 @@ static int mic_bias_event(struct snd_soc_dapm_widget *w,
{
struct snd_soc_codec *codec = w-codec;
struct aic31xx_priv *aic31xx = snd_soc_codec_get_drvdata(codec);
+
switch (event) {
case SND_SOC_DAPM_POST_PMU:
/* change mic bias voltage to user defined */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tools: Separate dso data related variables
Commit-ID: ca40e2af1f75eddf7eb2b93fde6391ea185d8fc8
Gitweb: http://git.kernel.org/tip/ca40e2af1f75eddf7eb2b93fde6391ea185d8fc8
Author: Jiri Olsa jo...@kernel.org
AuthorDate: Wed, 7 May 2014 18:30:45 +0200
Committer: Jiri Olsa jo...@kernel.org
CommitDate: Thu, 12 Jun 2014 16:53:19 +0200
perf tools: Separate dso data related variables
Add separated structure/namespace for data related
variables. We are going to add mode of them, so this
way they will be clearly separated.
Acked-by: Namhyung Kim namhy...@kernel.org
Cc: Arnaldo Carvalho de Melo a...@kernel.org
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link:
http://lkml.kernel.org/r/1401892622-30848-3-git-send-email-jo...@kernel.org
Signed-off-by: Jiri Olsa jo...@kernel.org
---
tools/perf/util/dso.c | 8
tools/perf/util/dso.h | 7 ++-
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 64453d6..1c3cdaf 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -292,7 +292,7 @@ dso_cache__read(struct dso *dso, struct machine *machine,
cache-offset = cache_offset;
cache-size = ret;
- dso_cache__insert(dso-cache, cache);
+ dso_cache__insert(dso-data.cache, cache);
ret = dso_cache__memcpy(cache, offset, data, size);
@@ -310,7 +310,7 @@ static ssize_t dso_cache_read(struct dso *dso, struct
machine *machine,
{
struct dso_cache *cache;
- cache = dso_cache__find(dso-cache, offset);
+ cache = dso_cache__find(dso-data.cache, offset);
if (cache)
return dso_cache__memcpy(cache, offset, data, size);
else
@@ -473,7 +473,7 @@ struct dso *dso__new(const char *name)
dso__set_short_name(dso, dso-name, false);
for (i = 0; i MAP__NR_TYPES; ++i)
dso-symbols[i] = dso-symbol_names[i] = RB_ROOT;
- dso-cache = RB_ROOT;
+ dso-data.cache = RB_ROOT;
dso-symtab_type = DSO_BINARY_TYPE__NOT_FOUND;
dso-binary_type = DSO_BINARY_TYPE__NOT_FOUND;
dso-loaded = 0;
@@ -506,7 +506,7 @@ void dso__delete(struct dso *dso)
dso-long_name_allocated = false;
}
- dso_cache__free(dso-cache);
+ dso_cache__free(dso-data.cache);
dso__free_a2l(dso);
zfree(dso-symsrc_filename);
free(dso);
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index 38efe95..7637fdd 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -76,7 +76,6 @@ struct dso {
struct list_head node;
struct rb_root symbols[MAP__NR_TYPES];
struct rb_root symbol_names[MAP__NR_TYPES];
- struct rb_root cache;
void *a2l;
char *symsrc_filename;
unsigned int a2l_fails;
@@ -99,6 +98,12 @@ struct dso {
const char *long_name;
u16 long_name_len;
u16 short_name_len;
+
+ /* dso data file */
+ struct {
+ struct rb_root cache;
+ } data;
+
char name[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 V2 08/19] irqchip: crossbar: fix checkpatch warning
Hi Jason, On Thursday 12 June 2014 09:35 PM, Joe Perches wrote: On Thu, 2014-06-12 at 11:32 -0400, Jason Cooper wrote: Hi Jason. But bugfix backports haven't been much of an issue in other subsystems with fairly active whitespace/style changes. Most of the mvebu fixes we've had that failed to apply were generally due to a large whitespace change (dts node shuffling, admittedly not checkpatch-related). So not due to this. I've also frequently been stymied by code cleanups when using git blame to find the commit introducing a regression. git blame -w can frequently help there. So, my general rule is: If you're submitting a patch to make checkpatch be quiet, re-assess the need. If you're making changes and you can fix some checkpatch items while you're there, then do so. Decent rule. There are certainly legitimate checkpatch-only patches, I just don't think this is one qualifies. Of course it's the maintainer's choice (and last I saw, that's you) to ignore whatever doesn't fit the appropriate vision for the code. $ ./scripts/get_maintainer.pl -f drivers/irqchip/irq-crossbar.c Thomas Gleixner t...@linutronix.de (maintainer:IRQCHIP DRIVERS) Jason Cooper ja...@lakedaemon.net (maintainer:IRQCHIP DRIVERS) Ok, if this is not qualifying as a separate patch then i will merge this with other patches in the series which touch them. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On Thursday 12 June 2014 07:27 PM, Tony Lindgren wrote: * Jason Cooper ja...@lakedaemon.net [140612 05:52]: On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote: From: Nishanth Menon n...@ti.com When, in the system due to varied reasons, interrupts might be unusable due to hardware behavior, but register maps do exist, then those interrupts should be skipped while mapping irq to crossbars. Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com Tony, have you applied these somewhere already? I think some of these I had applied into a branch ready for merging but then it was discovered that further changes were needed and the branch was dropped. Sricharan, please remove my Signed-off-by from this series. If I end up applying it for merging my scripts will add it automatically. Ok, will remove it. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: kmemleak: Unable to handle kernel paging request
On 6/12/14, Naoya Horiguchi n-horigu...@ah.jp.nec.com wrote:
Hi Denis,
On Thu, Jun 12, 2014 at 04:00:57PM +0400, Denis Kirjanov wrote:
On 6/12/14, Denis Kirjanov k...@linux-powerpc.org wrote:
On 6/12/14, Catalin Marinas catalin.mari...@arm.com wrote:
On 11 Jun 2014, at 21:04, Denis Kirjanov k...@linux-powerpc.org
wrote:
On 6/11/14, Catalin Marinas catalin.mari...@arm.com wrote:
On Wed, Jun 11, 2014 at 04:13:07PM +0400, Denis Kirjanov wrote:
I got a trace while running 3.15.0-08556-gdfb9454:
[ 104.534026] Unable to handle kernel paging request for data at
address 0xc0007f00
Were there any kmemleak messages prior to this, like kmemleak
disabled? There could be a race when kmemleak is disabled because
of
some fatal (for kmemleak) error while the scanning is taking place
(which needs some more thinking to fix properly).
No. I checked for the similar problem and didn't find anything
relevant.
I'll try to bisect it.
Does this happen soon after boot? I guess it’s the first scan
(scheduled at around 1min after boot). Something seems to be telling
kmemleak that there is a valid memory block at 0xc0007f00.
Yeah, it happens after a while with a booted system so that's the
first kmemleak scan.
Catalin
I've bisected to this commit: d4c54919ed86302094c0ca7d48a8cbd4ee753e92
mm: add !pte_present() check on existing hugetlb_entry callbacks.
Reverting the commit fixes the issue
Thanks for the effort of bisecting.
I guess that this bug happens because pte_none() check was gone in this
commit, so could you try to find if the following patch fixes the problem?
I don't know much about kmemleak's details, so I'm not sure how this bug
affected kmemleak. So I'm appreciated if you would add some comment in
patch description.
Thanks,
Naoya Horiguchi
---
Date: Thu, 12 Jun 2014 08:56:27 -0400
Subject: [PATCH] mm: revoke pte_none() check for hugetlb_entry() callbacks
commit: d4c54919ed86302094c0ca7d48a8cbd4ee753e92 (mm: add !pte_present()
check on existing hugetlb_entry callbacks) removed pte_none() check in
a -hugetlb_entry() handler, which unexpectedly broke other features like
kmemleak.
pte_none() check should be done in common page walk code, because we do
so for normal pages and page walk might want to handle holes with
-pte_hole() callback.
Reported-by: Denis Kirjanov k...@linux-powerpc.org
Signed-off-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
---
mm/pagewalk.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/mm/pagewalk.c b/mm/pagewalk.c
index 2beeabf502c5..0618657285c4 100644
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -118,6 +118,13 @@ static int walk_hugetlb_range(struct vm_area_struct
*vma,
do {
next = hugetlb_entry_end(h, addr, end);
pte = huge_pte_offset(walk-mm, addr hmask);
+ if (huge_pte_none(*pte)) {
+ if (walk-pte_hole)
+ err = walk-pte_hole(addr, next, walk);
+ if (err)
+ break;
+ continue;
+ }
if (pte walk-hugetlb_entry)
err = walk-hugetlb_entry(pte, hmask, addr, next, walk);
if (err)
--
1.9.3
Nope, Unfortunately I still see the issue :/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
Hi Jason,
On Thursday 12 June 2014 07:37 PM, Jason Cooper wrote:
On Thu, Jun 12, 2014 at 06:49:17PM +0530, Sricharan R wrote:
Hi Jason,
On Thursday 12 June 2014 06:21 PM, Jason Cooper wrote:
On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote:
From: Nishanth Menon n...@ti.com
When, in the system due to varied reasons, interrupts might be unusable
due to hardware behavior, but register maps do exist, then those interrupts
should be skipped while mapping irq to crossbars.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
Tony, have you applied these somewhere already?
---
drivers/irqchip/irq-crossbar.c | 47
1 file changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c
b/drivers/irqchip/irq-crossbar.c
index 51d4b87..847f6e3 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -13,11 +13,13 @@
#include linux/io.h
#include linux/of_address.h
#include linux/of_irq.h
+#include linux/of_device.h
#include linux/slab.h
#include linux/irqchip/arm-gic.h
#define IRQ_FREE -1
#define IRQ_RESERVED -2
+#define IRQ_SKIP -3
#define GIC_IRQ_START 32
/*
@@ -34,6 +36,16 @@ struct crossbar_device {
void (*write) (int, int);
};
+/**
+ * struct crossbar_data: Platform specific data
+ * @irqs_unused: array of irqs that cannot be used because of hw erratas
+ * @size: size of the irqs_unused array
+ */
+struct crossbar_data {
+ const uint *irqs_unused;
+ const uint size;
+};
+
static struct crossbar_device *cb;
static inline void crossbar_writel(int irq_no, int cb_no)
@@ -119,10 +131,12 @@ const struct irq_domain_ops routable_irq_domain_ops
= {
.xlate = crossbar_domain_xlate
};
-static int __init crossbar_of_init(struct device_node *node)
+static int __init crossbar_of_init(struct device_node *node,
+ const struct crossbar_data *data)
{
int i, size, max, reserved = 0, entry;
const __be32 *irqsr;
+ const int *irqsk = NULL;
cb = kzalloc(sizeof(*cb), GFP_KERNEL);
@@ -194,6 +208,22 @@ static int __init crossbar_of_init(struct device_node
*node)
reserved += size;
}
+ /* Skip the ones marked as unused */
+ if (data) {
+ irqsk = data-irqs_unused;
+ size = data-size;
+
+ for (i = 0; i size; i++) {
+ entry = irqsk[i];
+
+ if (entry max) {
+ pr_err(Invalid skip entry\n);
+ goto err3;
+ }
+ cb-irq_map[entry] = IRQ_SKIP;
+ }
+ }
+
register_routable_domain_ops(routable_irq_domain_ops);
return 0;
@@ -208,18 +238,27 @@ err1:
return -ENOMEM;
}
+/* irq number 10 cannot be used because of hw bug */
+int dra_irqs_unused[] = { 10 };
+struct crossbar_data cb_dra_data = { dra_irqs_unused,
+ ARRAY_SIZE(dra_irqs_unused) };
+
static const struct of_device_id crossbar_match[] __initconst = {
- { .compatible = ti,irq-crossbar },
+ { .compatible = ti,irq-crossbar, .data = cb_dra_data },
{}
};
This is a bug in all implementations of this IP? Or, a specific
SoC's implementation? Would this be better expressed in the dts via a
property? Can we expect future implementations to be fixed?
thx,
Jason.
Infact this and PATCH#10 should be merged. I will change that.
So in Socs's (2 so far) that do have a crossbar, some irqs are mapped
through a crossbar and some are directly wired to the irqchip.
These 'unused irqs' are those which are directly wired but they still
have a crossbar register. Their routing cannot be changed. So this
is not really expected usage of the crossbar hw ip. We initially thought
having a dts property separately for this, but took this path to avoid
loading the dts with additional bindings which may not be generic.
How do you plan to handle future SoCs with this IP and possibly
different hard-wired irqs?
Yes, that would require adding a new compatible in the above list and dts.
So if adding a new binding in the dts would be cleaner, then i will change
it that way.
Regards,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: scsi-mq
On 06/12/14 15:48, Christoph Hellwig wrote: The usage of blk-mq dramatically decreases CPU usage under all workloads going down from 100% CPU usage that the old setup can hit easily to usually less than 20% for maxing out storage subsystems with 512 byte reads and writes, and it allows to easily achieve millions of IOPS. Bart and Robert have helped with some very detailed measurements that they might be able to send in reply to this, although these usually involve significantly reworked low level drivers to avoid other bottle necks. Thanks Christoph for writing up this excellent summary. In case anyone is wondering which LLD changes Christoph is referring to: the tests I ran myself were with an SRP initiator driver modified to use multiple RDMA channels between initiator and target instead of a single channel. I will post these changes for review on the linux-rdma mailing list as soon as I have the time. Bart. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Networking
On Thu, Jun 12, 2014 at 12:14 PM, David Miller da...@davemloft.net wrote: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master Hmm. I get *lots* of the appended messages from iwlwifi now. Things still seem to work, but ... This is a Haswell laptop with bog-standard intel wireless: 01:00.0 Network controller: Intel Corporation Wireless 7260 (rev 6b) Any ideas? Linus --- [ 273.783438] unknown: hw csum failure [ 273.783449] CPU: 2 PID: 2199 Comm: Chrome_IOThread Not tainted 3.15.0-11906-g6d87c225f5d8 #8 [ 273.783451] Hardware name: Sony Corporation SVP11213CXB/VAIO, BIOS R0270V7 05/17/2013 [ 273.783461] Call Trace: [ 273.783477] [8159d199] ? dump_stack+0x41/0x51 [ 273.783488] [814a4f1d] ? skb_copy_and_csum_datagram_iovec+0xfd/0x110 [ 273.783494] [8150e2ea] ? udp_recvmsg+0x1ca/0x390 [ 273.783500] [81518e95] ? inet_recvmsg+0x65/0x80 [ 273.783506] [814971f5] ? sock_recvmsg+0x95/0xd0 [ 273.783511] [81197862] ? ep_send_events_proc+0xa2/0x1b0 [ 273.783513] [811977c0] ? ep_read_events_proc+0xb0/0xb0 [ 273.783516] [81497325] ? SYSC_recvfrom+0xb5/0x110 [ 273.783521] [8108bdc0] ? wake_up_state+0x10/0x10 [ 273.783527] [815a3d92] ? system_call_fastpath+0x16/0x1b -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 0/8] 3.4.94-stable review
On 06/12/2014 04:22 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.94 release. There are 8 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Jun 14 23:22:28 UTC 2014. Anything received after that time might be too late. Build results: total: 136 pass: 111 skipped: 20 fail: 5 Failed builds: alpha:allmodconfig arm:spear6xx_defconfig sparc64:allmodconfig unicore32:defconfig xtensa:allmodconfig Qemu tests all passed. Results are as expected. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] cpufreq: intel_pstate: Fix rounding of core_pct
On 2014.06.12 13:03 Rafael J. Wysocki wrote: On Thursday, June 12, 2014 05:35:59 PM Stratos Karafotis wrote: On 12/06/2014 12:15 πμ, Doug Smythies wrote: On 2014.06.11 13:20 Stratos Karafotis wrote: On 11/06/2014 06:02 μμ, Doug Smythies wrote: On 2104.06.11 07:08 Stratos Karafotis wrote: On 11/06/2014 04:41 μμ, Doug Smythies wrote: No. The intent was only ever to round properly the pseudo floating point result of the divide. It was much more important (ugh, well 4 times more) when FRACBITS was still 6, which also got changed to 8 in a recent patch. Are you sure? Yes. This rounding was very recently added. As far as I can understand, I don't see the meaning of this rounding, as is. Even if FRAC_BITS was 6, I think it would have almost no improvement in calculations. Note: I had not seen this e-mail when I wrote a few minutes ago: You may be correct. If Dirk agrees, I will re-analyse the entire driver for rounding effects soon. When FRACBITS was 6 there were subtle cases where the driver would get stuck, and not make a final pstate change, with the default PID gains. Other things have changed, and the analysis needs to be re-done. Could you please elaborate a little bit more what we need these 2 lines below? if ((rem 1) = int_tofp(sample-mperf)) core_pct += 1; Because nothing is mentioned for them in commit's changelog. Do we need to round core_pct or not? Because if we try to round it, I think this patch should work. As mentioned originally, they are there just to round the pseudo floating number, not the integer portion only. Let us bring back the very numbers you originally gave and work through it. aperf = 5024 mperf = 10619 core_pct = 47.31142292% or 47 and 79.724267 256ths or to the closest kept fractional part 47 and 80 256ths or 12112 as a pseudo float. The maximum error with this rounding will be 1 part in 512 and symmetric instead of the 1 part in 256 always in one direction without. Now if FRACBITS was still 6: core_pct = 47.31142292% or 47 and 19.931 64ths or to the closest kept fractional part 47 and 20 64ths or 3028 as a pseudo float. The maximum error with this rounding will be 1 part in 128 and symmetric instead of the 1 part in 64 (1.6% !!!) always in one direction without. Hope this helps. Yes, it helps. Thanks a lot! But please note that the maximum error without this rounding will be 1.6% _only_ in fractional part. In the real number it will be much smaller: Fair comment. Thanks. 47.19 instead of 47.20 And using FRAC_BITS 8: 47.79 instead of 47.80 I really wouldn't write it that way, as I find it misleading. It is really 47 and 19 256ths... Anyway, I think we all understand. This is a 0.0002% difference. I can't see how this is can affect the calculations even with FRAC_BITS 6. O.K. The solution is overkill and div_u64 could have been used instead of div_u64_rem. On my list, it is the lowest of priorities. Another thing is that this algorithm generally is used to round to the nearest integer. I'm not sure if it's valid to apply it for the rounding of the fractional part of fixed point number. I'm not sure how to reply, a pseudo floating point number is just an integer. Depending on the original reason, it may or may not be. The original reason for that overall code patch was to address the possible overflow of the math, which (as far I know and have tested) it does. I think we have gone down a bit of rat hole here in terms of the detail. ... Doug -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] ACPI/EC: Fix an issue that advance_transaction() processes stale hardware status.
The advance_transaction() will be invoked from the IRQ context GPE handler
and the task context ec_poll(). The handling of this function is locked so
that the EC state machine are ensured to be advanced sequentially.
But there is a problem. Before invoking advance_transaction(), EC_SC(R) is
read. Then for advance_transaction(), there could be race condition around
the lock from both contexts. The first one reading the register could fail
this race and when it passes the stale register value to the state machine
advancement code, the hardware condition is totally different from when
the register is read. And the hardware accesses determined from the wrong
hardware status can break the EC state machine. For example:
1. When 2 EC_DATA(W) write compete the IBF=0, the 2nd EC_DATA(W) write may
be invalid due to IBF=1 after the 1st EC_DATA(W).
2. When 1 EC_DATA(W) and 1 EC_SC(W) writes compete the IBF=0, the EC_SC(W)
write may be invalid due to IBF=1 after the EC_DATA(W). This is the root
cause of the reported issue.
This patch fixes this issue by moving the EC_SC(R) access into the lock so
that we can ensure that the state machine is advanced under the right
condition.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Signed-off-by: Lv Zheng lv.zh...@intel.com
Reported-and-tested-by: Gareth Williams gar...@garethwilliams.me.uk
Tested-by: Steffen Weber steffen.we...@gmail.com
[zetalog: first affected by:]
Cc: sta...@vger.kernel.org # 2.6.11: 7c6db4e0: ACPI: EC: do transaction from
interrupt context
[zetalog: cleanly applying to:]
Cc: sta...@vger.kernel.org # 3.14.x: 42b946bb: ACPI / EC: disable GPE before
removing GPE handler
---
drivers/acpi/ec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index ad11ba4..762b4cc 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -168,12 +168,15 @@ static void start_transaction(struct acpi_ec *ec)
acpi_ec_write_cmd(ec, ec-curr-command);
}
-static void advance_transaction(struct acpi_ec *ec, u8 status)
+static void advance_transaction(struct acpi_ec *ec)
{
unsigned long flags;
struct transaction *t;
+ u8 status;
spin_lock_irqsave(ec-lock, flags);
+ pr_debug(= %s =\n, in_interrupt() ? IRQ : TASK);
+ status = acpi_ec_read_status(ec);
t = ec-curr;
if (!t)
goto unlock;
@@ -236,7 +239,7 @@ static int ec_poll(struct acpi_ec *ec)
msecs_to_jiffies(1)))
return 0;
}
- advance_transaction(ec, acpi_ec_read_status(ec));
+ advance_transaction(ec);
} while (time_before(jiffies, delay));
pr_debug(controller reset, restart transaction\n);
spin_lock_irqsave(ec-lock, flags);
@@ -635,11 +638,8 @@ static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
u32 gpe_number, void *data)
{
struct acpi_ec *ec = data;
- u8 status = acpi_ec_read_status(ec);
-
- pr_debug(~~~ interrupt, status:0x%02x\n, status);
- advance_transaction(ec, status);
+ advance_transaction(ec);
if (ec_transaction_done(ec)
(acpi_ec_read_status(ec) ACPI_EC_FLAG_IBF) == 0) {
wake_up(ec-wait);
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/7] ACPI/EC: Add asynchronous command byte write support.
This patch adds asynchronous command byte write into advance_transaction()
so that all state machine affecting EC register accesses can happen in this
state machine advancement function.
This is achieved by moving the first command write code into
advance_transaction(). This function then can be a complete implementation
of an asyncrhonous transaction for a single command so that:
1. The first command byte can be written in the interrupt context;
2. The command completion waiter can also be used to wait the first command
byte's timeout;
3. In BURST mode, the follow-up command bytes can be written in the
interrupt context directly, so that it doesn't need to return to the
task context. Returning to the task context reduces the throughput of
the BURST mode and in the worst cases where the system workload is very
high, this leads to the hardware driven automatic BURST mode exit.
In order not to increase memory consumptions, this patch converts 'done'
into 'flags' to contain multiple indications:
1. ACPI_EC_COMMAND_COMPLETE: converting from original 'done' condition,
indicating the completion of the command transaction.
2. ACPI_EC_COMMAND_POLL: indicating the availability of writing the first
command byte. A new command can utilize this flag to compete for the
right of accessing the underlying hardware.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Signed-off-by: Lv Zheng lv.zh...@intel.com
Reported-and-tested-by: Gareth Williams gar...@garethwilliams.me.uk
Tested-by: Steffen Weber steffen.we...@gmail.com
[zetalog: first affected by:]
Cc: sta...@vger.kernel.org # 2.6.11: 7c6db4e0: ACPI: EC: do transaction from
interrupt context
[zetalog: cleanly applying to:]
Cc: sta...@vger.kernel.org # 3.14.x: 42b946bb: ACPI / EC: disable GPE before
removing GPE handler
---
drivers/acpi/ec.c | 83 +++--
1 file changed, 48 insertions(+), 35 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 762b4cc..f09386e 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -78,6 +78,9 @@ enum {
EC_FLAGS_BLOCKED, /* Transactions are blocked */
};
+#define ACPI_EC_COMMAND_POLL 0x01 /* Available for command byte */
+#define ACPI_EC_COMMAND_COMPLETE 0x02 /* Completed last byte */
+
/* ec.c is compiled in acpi namespace so this shows up as acpi.ec_delay param
*/
static unsigned int ec_delay __read_mostly = ACPI_EC_DELAY;
module_param(ec_delay, uint, 0644);
@@ -109,7 +112,7 @@ struct transaction {
u8 ri;
u8 wlen;
u8 rlen;
- bool done;
+ u8 flags;
};
struct acpi_ec *boot_ec, *first_ec;
@@ -150,63 +153,68 @@ static inline void acpi_ec_write_data(struct acpi_ec *ec,
u8 data)
outb(data, ec-data_addr);
}
-static int ec_transaction_done(struct acpi_ec *ec)
+static int ec_transaction_completed(struct acpi_ec *ec)
{
unsigned long flags;
int ret = 0;
spin_lock_irqsave(ec-lock, flags);
- if (!ec-curr || ec-curr-done)
+ if (!ec-curr || (ec-curr-flags ACPI_EC_COMMAND_COMPLETE))
ret = 1;
spin_unlock_irqrestore(ec-lock, flags);
return ret;
}
-static void start_transaction(struct acpi_ec *ec)
-{
- ec-curr-irq_count = ec-curr-wi = ec-curr-ri = 0;
- ec-curr-done = false;
- acpi_ec_write_cmd(ec, ec-curr-command);
-}
-
static void advance_transaction(struct acpi_ec *ec)
{
- unsigned long flags;
struct transaction *t;
u8 status;
- spin_lock_irqsave(ec-lock, flags);
pr_debug(= %s =\n, in_interrupt() ? IRQ : TASK);
status = acpi_ec_read_status(ec);
t = ec-curr;
if (!t)
- goto unlock;
- if (t-wlen t-wi) {
- if ((status ACPI_EC_FLAG_IBF) == 0)
- acpi_ec_write_data(ec,
- t-wdata[t-wi++]);
- else
- goto err;
- } else if (t-rlen t-ri) {
- if ((status ACPI_EC_FLAG_OBF) == 1) {
- t-rdata[t-ri++] = acpi_ec_read_data(ec);
- if (t-rlen == t-ri)
- t-done = true;
+ goto err;
+ if (t-flags ACPI_EC_COMMAND_POLL) {
+ if (t-wlen t-wi) {
+ if ((status ACPI_EC_FLAG_IBF) == 0)
+ acpi_ec_write_data(ec, t-wdata[t-wi++]);
+ else
+ goto err;
+ } else if (t-rlen t-ri) {
+ if ((status ACPI_EC_FLAG_OBF) == 1) {
+ t-rdata[t-ri++] = acpi_ec_read_data(ec);
+ if (t-rlen == t-ri)
+ t-flags |= ACPI_EC_COMMAND_COMPLETE;
+ } else
+ goto err;
+ } else if (t-wlen == t-wi
+
[PATCH 3/7] ACPI/EC: Remove duplicated ec_wait_ibf0() waiter.
After we've added first command byte write into advance_transaction(), the
IBF=0 waiter is duplicated with the command completion waiter implemented
in the ec_poll() because:
If IBF=1 blocked the first command byte write invoked in the task
context ec_poll(), it would be kicked off upon IBF=0 interrupt or timed
out and retried again in the task context.
This patch removes this seperate and duplicate IBF=0 waiter, by doing so,
we can reduce the overall number of times to access the EC_SC(R) status
register.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Signed-off-by: Lv Zheng lv.zh...@intel.com
Reported-and-tested-by: Gareth Williams gar...@garethwilliams.me.uk
Tested-by: Steffen Weber steffen.we...@gmail.com
[zetalog: first affected by:]
Cc: sta...@vger.kernel.org # 2.6.11: 7c6db4e0: ACPI: EC: do transaction from
interrupt context
[zetalog: cleanly applying to:]
Cc: sta...@vger.kernel.org # 3.14.x: 42b946bb: ACPI / EC: disable GPE before
removing GPE handler
---
drivers/acpi/ec.c | 27 +--
1 file changed, 1 insertion(+), 26 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index f09386e..d016ea3 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -281,23 +281,6 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec *ec,
return ret;
}
-static int ec_check_ibf0(struct acpi_ec *ec)
-{
- u8 status = acpi_ec_read_status(ec);
- return (status ACPI_EC_FLAG_IBF) == 0;
-}
-
-static int ec_wait_ibf0(struct acpi_ec *ec)
-{
- unsigned long delay = jiffies + msecs_to_jiffies(ec_delay);
- /* interrupt wait manually if GPE mode is not active */
- while (time_before(jiffies, delay))
- if (wait_event_timeout(ec-wait, ec_check_ibf0(ec),
- msecs_to_jiffies(1)))
- return 0;
- return -ETIME;
-}
-
static int acpi_ec_transaction(struct acpi_ec *ec, struct transaction *t)
{
int status;
@@ -318,12 +301,6 @@ static int acpi_ec_transaction(struct acpi_ec *ec, struct
transaction *t)
goto unlock;
}
}
- if (ec_wait_ibf0(ec)) {
- pr_err(input buffer is not empty,
- aborting transaction\n);
- status = -ETIME;
- goto end;
- }
pr_debug(transaction start (cmd=0x%02x, addr=0x%02x)\n,
t-command, t-wdata ? t-wdata[0] : 0);
/* disable GPE during transaction if storm is detected */
@@ -347,7 +324,6 @@ static int acpi_ec_transaction(struct acpi_ec *ec, struct
transaction *t)
set_bit(EC_FLAGS_GPE_STORM, ec-flags);
}
pr_debug(transaction end\n);
-end:
if (ec-global_lock)
acpi_release_global_lock(glk);
unlock:
@@ -653,8 +629,7 @@ static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
spin_lock_irqsave(ec-lock, flags);
advance_transaction(ec);
spin_unlock_irqrestore(ec-lock, flags);
- if (ec_transaction_completed(ec)
- (acpi_ec_read_status(ec) ACPI_EC_FLAG_IBF) == 0) {
+ if (ec_transaction_completed(ec)) {
wake_up(ec-wait);
ec_check_sci(ec, acpi_ec_read_status(ec));
}
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 4/7] ACPI/EC: Fix a race condition in ec_transaction_completed().
There is a race condition in ec_transaction_completed().
When ec_transaction_completed() is called in the GPE handler, it could
return true because of (ec-curr == NULL). Then the wake_up() invocation
could complete the next command unexpectedly since there is no lock between
the 2 invocations. With the previous cleanup, we now needn't to handle
IBF=0 waiter race. It's now safe for us to return a flag from
advance_condition() to indicate the requirement of wakeup, the flag is
returned from a locked context.
The ec_transaction_completed() now is only invoked by the ec_poll() where
the ec-curr is ensured to be !NULL.
After cleaning up, the EVT_SCI=1 check should be moved out of the wakeup
condition so that an EVT_SCI raised with (ec-curr == NULL) can trigger a
QR_SC command.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Signed-off-by: Lv Zheng lv.zh...@intel.com
Reported-and-tested-by: Gareth Williams gar...@garethwilliams.me.uk
Tested-by: Steffen Weber steffen.we...@gmail.com
[zetalog: first affected by:]
Cc: sta...@vger.kernel.org # 2.6.11: 7c6db4e0: ACPI: EC: do transaction from
interrupt context
[zetalog: cleanly applying to:]
Cc: sta...@vger.kernel.org # 3.14.x: 42b946bb: ACPI / EC: disable GPE before
removing GPE handler
---
drivers/acpi/ec.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index d016ea3..f1fa899 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -158,16 +158,17 @@ static int ec_transaction_completed(struct acpi_ec *ec)
unsigned long flags;
int ret = 0;
spin_lock_irqsave(ec-lock, flags);
- if (!ec-curr || (ec-curr-flags ACPI_EC_COMMAND_COMPLETE))
+ if (ec-curr (ec-curr-flags ACPI_EC_COMMAND_COMPLETE))
ret = 1;
spin_unlock_irqrestore(ec-lock, flags);
return ret;
}
-static void advance_transaction(struct acpi_ec *ec)
+static bool advance_transaction(struct acpi_ec *ec)
{
struct transaction *t;
u8 status;
+ bool wakeup = false;
pr_debug(= %s =\n, in_interrupt() ? IRQ : TASK);
status = acpi_ec_read_status(ec);
@@ -183,21 +184,25 @@ static void advance_transaction(struct acpi_ec *ec)
} else if (t-rlen t-ri) {
if ((status ACPI_EC_FLAG_OBF) == 1) {
t-rdata[t-ri++] = acpi_ec_read_data(ec);
- if (t-rlen == t-ri)
+ if (t-rlen == t-ri) {
t-flags |= ACPI_EC_COMMAND_COMPLETE;
+ wakeup = true;
+ }
} else
goto err;
} else if (t-wlen == t-wi
- (status ACPI_EC_FLAG_IBF) == 0)
+ (status ACPI_EC_FLAG_IBF) == 0) {
t-flags |= ACPI_EC_COMMAND_COMPLETE;
- return;
+ wakeup = true;
+ }
+ return wakeup;
} else {
if ((status ACPI_EC_FLAG_IBF) == 0) {
acpi_ec_write_cmd(ec, t-command);
t-flags |= ACPI_EC_COMMAND_POLL;
} else
goto err;
- return;
+ return wakeup;
}
err:
/*
@@ -208,13 +213,14 @@ err:
if (in_interrupt() t)
++t-irq_count;
}
+ return wakeup;
}
static void start_transaction(struct acpi_ec *ec)
{
ec-curr-irq_count = ec-curr-wi = ec-curr-ri = 0;
ec-curr-flags = 0;
- advance_transaction(ec);
+ (void)advance_transaction(ec);
}
static int acpi_ec_sync_query(struct acpi_ec *ec, u8 *data);
@@ -248,7 +254,7 @@ static int ec_poll(struct acpi_ec *ec)
return 0;
}
spin_lock_irqsave(ec-lock, flags);
- advance_transaction(ec);
+ (void)advance_transaction(ec);
spin_unlock_irqrestore(ec-lock, flags);
} while (time_before(jiffies, delay));
pr_debug(controller reset, restart transaction\n);
@@ -625,14 +631,14 @@ static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
{
unsigned long flags;
struct acpi_ec *ec = data;
+ bool wakeup;
spin_lock_irqsave(ec-lock, flags);
- advance_transaction(ec);
+ wakeup = advance_transaction(ec);
spin_unlock_irqrestore(ec-lock, flags);
- if (ec_transaction_completed(ec)) {
+ if (wakeup)
wake_up(ec-wait);
- ec_check_sci(ec, acpi_ec_read_status(ec));
- }
+ ec_check_sci(ec, acpi_ec_read_status(ec));
return ACPI_INTERRUPT_HANDLED | ACPI_REENABLE_GPE;
}
--
1.7.10
--
[PATCH 5/7] ACPI/EC: Update revision due to full asynchrnous command support.
The bug fixes and asynchronous improvements have been done to the EC driver by the previous commits. This patch increases the revision 2.2 to indicate the difference. The copyright/authorship notices are also updated. Authorship of Alexey is updated according to the following diff block: - * ec.c - ACPI Embedded Controller Driver (v2.0) + * ec.c - ACPI Embedded Controller Driver (v2.1) - * Copyright (C) 2006, 2007 Alexey Starikovskiy alexey.y.starikovs...@intel.com + * Copyright (C) 2006-2008 Alexey Starikovskiy astarikovs...@suse.de This change is made by the following commit: Commit: 7c6db4e050601f359081fde418ca6dc4fc2d0011 Subject: ACPI: EC: do transaction from interrupt context Signed-off-by: Lv Zheng lv.zh...@intel.com --- drivers/acpi/ec.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index f1fa899..7726adc 100644 --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -1,11 +1,14 @@ /* - * ec.c - ACPI Embedded Controller Driver (v2.1) + * ec.c - ACPI Embedded Controller Driver (v2.2) * - * Copyright (C) 2006-2008 Alexey Starikovskiy astarikovs...@suse.de - * Copyright (C) 2006 Denis Sadykov denis.m.sady...@intel.com - * Copyright (C) 2004 Luming Yu luming...@intel.com - * Copyright (C) 2001, 2002 Andy Grover andrew.gro...@intel.com - * Copyright (C) 2001, 2002 Paul Diefenbaugh paul.s.diefenba...@intel.com + * Copyright (C) 2001-2014 Intel Corporation + *Auther: 2014 Lv Zheng lv.zh...@intel.com + *2006, 2007 Alexey Starikovskiy alexey.y.starikovs...@intel.com + *2006 Denis Sadykov denis.m.sady...@intel.com + *2004 Luming Yu luming...@intel.com + *2001, 2002 Andy Grover andrew.gro...@intel.com + *2001, 2002 Paul Diefenbaugh paul.s.diefenba...@intel.com + * Copyright (C) 2008 Alexey Starikovskiy astarikovs...@suse.de * * ~~ * -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 6/7] ACPICA: Events: Fix edge-triggered GPE by disabling before acknowledging it.
Due to ACPI specificiation 5, chapter 5.6.4 General-Purpose Event Hnadling,
OSPMs need to disable GPE before clearing the status bit for edge-triggered
GPEs.
Signed-off-by: Lv Zheng lv.zh...@intel.com
Tested-by: Gareth Williams gar...@garethwilliams.me.uk
Tested-by: Steffen Weber steffen.we...@gmail.com
---
drivers/acpi/acpica/evgpe.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/acpi/acpica/evgpe.c b/drivers/acpi/acpica/evgpe.c
index 48f7001..e4ba4de 100644
--- a/drivers/acpi/acpica/evgpe.c
+++ b/drivers/acpi/acpica/evgpe.c
@@ -698,21 +698,6 @@ acpi_ev_gpe_dispatch(struct acpi_namespace_node
*gpe_device,
}
/*
-* If edge-triggered, clear the GPE status bit now. Note that
-* level-triggered events are cleared after the GPE is serviced.
-*/
- if ((gpe_event_info-flags ACPI_GPE_XRUPT_TYPE_MASK) ==
- ACPI_GPE_EDGE_TRIGGERED) {
- status = acpi_hw_clear_gpe(gpe_event_info);
- if (ACPI_FAILURE(status)) {
- ACPI_EXCEPTION((AE_INFO, status,
- Unable to clear GPE %02X,
- gpe_number));
- return_UINT32(ACPI_INTERRUPT_NOT_HANDLED);
- }
- }
-
- /*
* Always disable the GPE so that it does not keep firing before
* any asynchronous activity completes (either from the execution
* of a GPE method or an asynchronous GPE handler.)
@@ -729,6 +714,23 @@ acpi_ev_gpe_dispatch(struct acpi_namespace_node
*gpe_device,
}
/*
+* If edge-triggered, clear the GPE status bit now. Note that
+* level-triggered events are cleared after the GPE is serviced.
+*/
+ if ((gpe_event_info-flags ACPI_GPE_XRUPT_TYPE_MASK) ==
+ ACPI_GPE_EDGE_TRIGGERED) {
+ status = acpi_hw_clear_gpe(gpe_event_info);
+ if (ACPI_FAILURE(status)) {
+ ACPI_EXCEPTION((AE_INFO, status,
+ Unable to clear GPE %02X,
+ gpe_number));
+ (void)acpi_hw_low_set_gpe(gpe_event_info,
+ ACPI_GPE_CONDITIONAL_ENABLE);
+ return_UINT32(ACPI_INTERRUPT_NOT_HANDLED);
+ }
+ }
+
+ /*
* Dispatch the GPE to either an installed handler or the control
* method associated with this GPE (_Lxx or _Exx). If a handler
* exists, we invoke it and do not attempt to run the method.
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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.10 00/18] 3.10.44-stable review
On 06/12/2014 04:22 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.44 release. There are 18 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Jun 14 23:22:02 UTC 2014. Anything received after that time might be too late. Build results: total: 143 pass: 136 skipped: 6 fail: 1 Failed builds: unicore32:defconfig Qemu tests all passed. Results are as expected. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] ACPI/EC: Add detailed fields debugging support of EC_SC(R).
Developers really don't need to translate EC_SC(R) in mind as long as the
field details are decoded in the debugging message.
Signed-off-by: Lv Zheng lv.zh...@intel.com
Tested-by: Gareth Williams gar...@garethwilliams.me.uk
Tested-by: Steffen Weber steffen.we...@gmail.com
---
drivers/acpi/ec.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 7726adc..9aa9d6a 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -55,6 +55,7 @@
/* EC status register */
#define ACPI_EC_FLAG_OBF 0x01/* Output buffer full */
#define ACPI_EC_FLAG_IBF 0x02/* Input buffer full */
+#define ACPI_EC_FLAG_CMD 0x08/* Input buffer contains a command */
#define ACPI_EC_FLAG_BURST 0x10/* burst mode */
#define ACPI_EC_FLAG_SCI 0x20/* EC-SCI occurred */
@@ -133,26 +134,33 @@ static int EC_FLAGS_CLEAR_ON_RESUME; /* Needs
acpi_ec_clear() on boot/resume */
static inline u8 acpi_ec_read_status(struct acpi_ec *ec)
{
u8 x = inb(ec-command_addr);
- pr_debug(--- status = 0x%2.2x\n, x);
+ pr_debug(EC_SC(R) = 0x%2.2x
+SCI_EVT=%d BURST=%d CMD=%d IBF=%d OBF=%d\n,
+x,
+!!(x ACPI_EC_FLAG_SCI),
+!!(x ACPI_EC_FLAG_BURST),
+!!(x ACPI_EC_FLAG_CMD),
+!!(x ACPI_EC_FLAG_IBF),
+!!(x ACPI_EC_FLAG_OBF));
return x;
}
static inline u8 acpi_ec_read_data(struct acpi_ec *ec)
{
u8 x = inb(ec-data_addr);
- pr_debug(--- data = 0x%2.2x\n, x);
+ pr_debug(EC_DATA(R) = 0x%2.2x\n, x);
return x;
}
static inline void acpi_ec_write_cmd(struct acpi_ec *ec, u8 command)
{
- pr_debug(--- command = 0x%2.2x\n, command);
+ pr_debug(EC_SC(W) = 0x%2.2x\n, command);
outb(command, ec-command_addr);
}
static inline void acpi_ec_write_data(struct acpi_ec *ec, u8 data)
{
- pr_debug(--- data = 0x%2.2x\n, data);
+ pr_debug(EC_DATA(W) = 0x%2.2x\n, data);
outb(data, ec-data_addr);
}
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/7] ACPI/EC: Critical bug fixes related to EC and event handling.
This patchset fixes the following issues: 1. There are 2 race conditions in current EC driver. 2. Cleanup the first command byte write as one of the race condition fix requires additional cleanup for first command byte write. And this also helps us to do improvements in the BURST mode in the future. 3. ACPICA event not handled in the correct way. This patchset also improves debugging message, register details can be enabled by defining DEBUG. And bug fixes and reports are based on this improvement. All patches are tested to be valid fixes for the following bug: https://bugzilla.kernel.org/show_bug.cgi?id=70891 The EC driver version is upgraded to 2.2. The first 4 patches are useful stable materials. But the culprit of the bug appears so long time ago that patches cannot be applied cleanly any more. Thus 2 commit IDs are listed for the stable reviewers, one for the culprit, the other for the kernel versions that can have these stable materials cleanly applied. Lv Zheng (7): ACPI/EC: Fix an issue that advance_transaction() processes stale hardware status. ACPI/EC: Add asynchronous command byte write support. ACPI/EC: Remove duplicated ec_wait_ibf0() waiter. ACPI/EC: Fix a race condition in ec_transaction_completed(). ACPI/EC: Update revision due to full asynchrnous command support. ACPICA: Events: Fix edge-triggered GPE by disabling before acknowledging it. ACPI/EC: Add detailed fields debugging support of EC_SC(R). drivers/acpi/acpica/evgpe.c | 32 + drivers/acpi/ec.c | 161 ++- 2 files changed, 100 insertions(+), 93 deletions(-) -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] checkpatch: warn on missing spaces in broken up quoted strings
Checkpatch already complains when people break up quoted strings but
it's still pretty common. One mistake that people often make is they
leave out the space character between the two strings.
This check adds 453 new warnings. There very few false positives, here
is what they look like:
1) Most of the false positives are in crypto/testmgr.h where they just
want a 10x10 block of sample text and don't care about the content.
2) There one commented place like this:
das08-aoh
das08-aol
3) There is one place which breaks the alphabet at the lower and upper
case boundary.
4) There is one person who broke quoted strings at the 80 character mark
without considering the content (that's not really a false positive,
now that I think about it).
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 010b18e..c50eee2 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4009,6 +4009,12 @@ sub process {
}
}
+# check for missing a space in a string concatination
+if ($prevrawline =~ /[^\\][a-zA-Z]$/ $rawline =~ /^\+[\t
]+[a-zA-Z]/) {
+WARN('MISSING_SPACE',
+ break quoted strings at a space character\n . $hereprev);
+}
+
# check for bad placement of section $InitAttribute (e.g.: __initdata)
if ($line =~ /(\b$InitAttribute\b)/) {
my $attr = $1;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/19] 3.14.8-stable review
On 06/12/2014 04:21 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.8 release. There are 19 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Jun 14 23:21:28 UTC 2014. Anything received after that time might be too late. Build results: total: 143 pass: 136 skipped: 4 fail: 3 Failed builds: powerpc:allmodconfig (binutils 2.3, 2.4) unicore32:defconfig Qemu tests all passed. Results are as expected. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 03/19] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
Hi Jason, On Thursday 12 June 2014 07:35 PM, Jason Cooper wrote: On Thu, Jun 12, 2014 at 06:57:15AM -0700, Tony Lindgren wrote: * Jason Cooper ja...@lakedaemon.net [140612 05:52]: On Thu, Jun 12, 2014 at 05:23:11PM +0530, Sricharan R wrote: From: Nishanth Menon n...@ti.com When, in the system due to varied reasons, interrupts might be unusable due to hardware behavior, but register maps do exist, then those interrupts should be skipped while mapping irq to crossbars. Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com Tony, have you applied these somewhere already? I think some of these I had applied into a branch ready for merging but then it was discovered that further changes were needed and the branch was dropped. Ok. Sricharan, please remove my Signed-off-by from this series. If I end up applying it for merging my scripts will add it automatically. Do you have other changes outside of irqchip depending on this series? If so, I can set up a topic branch for you guys to base off of. Otherwise, I'll just apply them to irqchip/core when they're ready. There are dts changes which are dependent upon this series. http://www.spinics.net/lists/linux-omap/msg108116.html Also, Sricharan, when you respin this, please clearly identify (in the comment section) those patches that need to be flagged for stable. It would be helpful if they were the first patches in the series as well. Ok, i will point this out clearly. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Networking
On Fri, 2014-06-13 at 06:48 +, Linus Torvalds wrote: On Thu, Jun 12, 2014 at 12:14 PM, David Miller da...@davemloft.net wrote: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master Hmm. I get *lots* of the appended messages from iwlwifi now. Things still seem to work, but ... This is a Haswell laptop with bog-standard intel wireless: 01:00.0 Network controller: Intel Corporation Wireless 7260 (rev 6b) Any ideas? Looks odd. If the stacktrace/message [ 273.783438] unknown: hw csum failure [ 273.783449] CPU: 2 PID: 2199 Comm: Chrome_IOThread Not tainted 3.15.0-11906-g6d87c225f5d8 #8 [ 273.783451] Hardware name: Sony Corporation SVP11213CXB/VAIO, BIOS R0270V7 05/17/2013 [ 273.783461] Call Trace: [ 273.783477] [8159d199] ? dump_stack+0x41/0x51 [ 273.783488] [814a4f1d] ? skb_copy_and_csum_datagram_iovec+0xfd/0x110 [ 273.783494] [8150e2ea] ? udp_recvmsg+0x1ca/0x390 [ 273.783500] [81518e95] ? inet_recvmsg+0x65/0x80 [ 273.783506] [814971f5] ? sock_recvmsg+0x95/0xd0 [ 273.783511] [81197862] ? ep_send_events_proc+0xa2/0x1b0 [ 273.783513] [811977c0] ? ep_read_events_proc+0xb0/0xb0 [ 273.783516] [81497325] ? SYSC_recvfrom+0xb5/0x110 [ 273.783521] [8108bdc0] ? wake_up_state+0x10/0x10 [ 273.783527] [815a3d92] ? system_call_fastpath+0x16/0x1b is to be believed, then I'm not sure why you think iwlwifi is involved though. Either way, iwlwifi doesn't support HW checksumming, so it failing makes no sense, it's not there to start with. The only thing that touched this seems to be Tom's patch: commit 7e3cead5172927732f51fde77fef6f521e22f209 Author: Tom Herbert therb...@google.com Date: Tue Jun 10 18:54:19 2014 -0700 net: Save software checksum complete but I'm not familiar enough to say where this leads. If it's iwlwifi, then maybe that commit broke something with devices that don't support checksumming? johannes -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 Jun 13
Hi all, The powerpc allyesconfig is again broken more than usual. Changes since 20140612: Dropped trees: akpm-current, akpm (build problems) Undropped tree: drm-intel-fixes The drm-intel-fixes lost its build failure. The net-next tree lost its build failure. I dropped the akpm-current and akpm tree for today due to buld problems. Non-merge commits (relative to Linus' tree): 754 904 files changed, 23582 insertions(+), 17277 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 219 trees (counting Linus' and 29 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 (f9da455b93f6 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next) Merging fixes/master (4b660a7f5c80 Linux 3.15-rc6) Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1) Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4) Merging arm-current/fixes (3f8517e7937d ARM: 8063/1: bL_switcher: fix individual online status reporting of removed CPUs) Merging m68k-current/for-linus (e8d6dc5ad26e m68k/hp300: Convert printk to pr_foo()) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging powerpc-merge/merge (8212f58a9b15 powerpc: Wire renameat2() syscall) Merging sparc/master (8ecc1bad4c9b sparc64: fix format string mismatch in arch/sparc/kernel/sysfs.c) Merging net/master (c5b46160877a net/core: Add VF link state control policy) Merging ipsec/master (6d004d6cc739 vti: Use the tunnel mark for lookup in the error handlers.) Merging sound-current/for-linus (2afe8be85c2c ALSA: intel8x0: Use ktime and ktime_get()) Merging pci-current/for-linus (d0b4cc4e3270 PCI: Wrong register used to check pending traffic) Merging wireless/master (2c316e699fa4 Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (4b660a7f5c80 Linux 3.15-rc6) Merging tty.current/tty-linus (d6d211db37e7 Linux 3.15-rc5) Merging usb.current/usb-linus (5dc2808c4729 xhci: delete endpoints from bandwidth list before freeing whole device) Merging usb-gadget-fixes/fixes (886c7c426d46 usb: gadget: at91-udc: fix irq and iomem resource retrieval) Merging staging.current/staging-linus (9326c5ca0982 staging: r8192e_pci: fix htons error) Merging char-misc.current/char-misc-linus (d1db0eea8524 Linux 3.15-rc3) Merging input-current/for-linus (a292241cccb7 Merge branch 'next' into for-linus) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding discard stripe) Merging crypto-current/master (3901c1124ec5 crypto: s390 - fix aes,des ctr mode concurrency finding.) Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (4b660a7f5c80 Linux 3.15-rc6) Merging rr-fixes/fixes (79465d2fd48e module: remove warning about waiting module removal.) Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before cancelling delayed works) 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 drm-intel-fixes/for-linux-next-fixes (15d24aa5602f drm/i915: BDW: Adding missing cursor offsets.) Merging asm-generic/master (fb9de7ebc3a2 xtensa: Use generic asm/mmu.h for nommu) Merging arc/for-next (34ad3f06d377 ARC: remove checks for CONFIG_ARC_MMU_V4) Merging arm/for-next (bd63ce27d9d6
Re: [RFC PATCH] OF: fix of_find_node_by_path() assumption that of_allnodes is root
Hi Frank,
On Jun 13, 2014, at 8:53 AM, Frank Rowand wrote:
From: Frank Rowand frank.row...@sonymobile.com
Pantelis Antoniou reports that of_find_node_by_path() is borked because
of_allnodes is not guaranteed to contain the root of the tree after using
any of the dynamic update functions because some other nodes ends up as
of_allnodes.
Fixes: c22e650e66b8 of: Make of_find_node_by_path() handle /aliases
Signed-off-by: Frank Rowand frank.row...@sonymobile.com
---
Pantelis,
Can you test whether the problem you reported in irc?
This patch has not been tested, not even compile tested.
I can verify that this fixes the problem. Please make sure this gets
applied to mainline otherwise every arch which updates DT on runtime
is going to break in subtle ways.
Regards
-- Pantelis
Tested-by: Pantelis Antoniou pantelis.anton...@konsulko.com
drivers/of/base.c |8 6 + 2 - 0 !
1 file changed, 6 insertions(+), 2 deletions(-)
Index: b/drivers/of/base.c
===
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1948,6 +1948,9 @@ int of_reconfig_notify(unsigned long act
/**
* of_attach_node - Plug a device node into the tree and global list.
+ *
+ * Put the device node after of_allnodes in the global list so that
+ * of_allnodes remains the root.
*/
int of_attach_node(struct device_node *np)
{
@@ -1958,11 +1961,12 @@ int of_attach_node(struct device_node *n
if (rc)
return rc;
+ BUG_ON(!of_allnodes);
raw_spin_lock_irqsave(devtree_lock, flags);
np-sibling = np-parent-child;
- np-allnext = of_allnodes;
+ np-allnext = of_allnodes-allnext;
np-parent-child = np;
- of_allnodes = np;
+ of_allnodes-allnext = np;
of_node_clear_flag(np, OF_DETACHED);
raw_spin_unlock_irqrestore(devtree_lock, flags);
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] hwmon: Driver for TI TMP103 temperature sensor
Driver for the TI TMP103. The TI TMP103 is similar to the TMP102. It differs from the TMP102 by having only 8 bit registers. Signed-off-by: Heiko Schocher h...@denx.de --- Cc: Jean Delvare kh...@linux-fr.org Cc: Guenter Roeck li...@roeck-us.net Cc: linux-kernel@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-...@vger.kernel.org - change for v2: - add comments from GuenterRoeck: - remove Cc from commit subject - add devicetree mailinglist - move Documentation to Documentation/hwmon/tmp103 - remove devicetree bindings from Documentation - add compatible string to Documentation/devicetree/bindings/i2c/trivial-devices.txt - remove CamelCase - fix Codingstyle issues - use ATTRIBUTE_GROUPS and devm_hwmon_device_register_with_groups() - remove unsused define TMP103_CONFIG_RD_ONLY - restore config register when exit() - use regmap .../devicetree/bindings/i2c/trivial-devices.txt| 1 + Documentation/hwmon/tmp103 | 28 ++ drivers/hwmon/Kconfig | 10 + drivers/hwmon/Makefile | 1 + drivers/hwmon/tmp103.c | 304 + 5 files changed, 344 insertions(+) create mode 100644 Documentation/hwmon/tmp103 create mode 100644 drivers/hwmon/tmp103.c diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index bef86e5..fc944e0 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -83,5 +83,6 @@ stm,m41t80M41T80 - SERIAL ACCESS RTC WITH ALARMS taos,tsl2550 Ambient Light Sensor with SMBUS/Two Wire Serial Interface ti,tsc2003 I2C Touch-Screen Controller ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface +ti,tmp103 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface ti,tmp275 Digital Temperature Sensor winbond,wpct301i2c trusted platform module (TPM) diff --git a/Documentation/hwmon/tmp103 b/Documentation/hwmon/tmp103 new file mode 100644 index 000..559fea5 --- /dev/null +++ b/Documentation/hwmon/tmp103 @@ -0,0 +1,28 @@ +Kernel driver tmp103 + + +Supported chips: + * Texas Instruments TMP103 +Prefix: 'tmp103' +Addresses scanned: none +Product info and datasheet: http://www.ti.com/product/tmp103 + +Author: + Heiko Schocher h...@denx.de + +Description +--- + +The TMP103 is a digital output temperature sensor in a four-ball +wafer chip-scale package (WCSP). The TMP103 is capable of reading +temperatures to a resolution of 1°C. The TMP103 is specified for +operation over a temperature range of –40°C to +125°C. + +Resolution: 8 Bits +Accuracy: ±1°C Typ (–10°C to +100°C) + +The driver provides the common sysfs-interface for temperatures (see +Documentation/hwmon/sysfs-interface under Temperatures). + +please refer how to instantiate this driver: +Documentation/i2c/instantiating-devices diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 0034316..0f44dbb 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -1381,6 +1381,16 @@ config SENSORS_TMP102 This driver can also be built as a module. If so, the module will be called tmp102. +config SENSORS_TMP103 + tristate Texas Instruments TMP103 + depends on I2C + help + If you say yes here you get support for Texas Instruments TMP103 + sensor chips. + + This driver can also be built as a module. If so, the module + will be called tmp103. + config SENSORS_TMP401 tristate Texas Instruments TMP401 and compatibles depends on I2C diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 11798ad..8e2f6a2 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -134,6 +134,7 @@ obj-$(CONFIG_SENSORS_SMSC47M192)+= smsc47m192.o obj-$(CONFIG_SENSORS_AMC6821) += amc6821.o obj-$(CONFIG_SENSORS_THMC50) += thmc50.o obj-$(CONFIG_SENSORS_TMP102) += tmp102.o +obj-$(CONFIG_SENSORS_TMP103) += tmp103.o obj-$(CONFIG_SENSORS_TMP401) += tmp401.o obj-$(CONFIG_SENSORS_TMP421) += tmp421.o obj-$(CONFIG_SENSORS_TWL4030_MADC)+= twl4030-madc-hwmon.o diff --git a/drivers/hwmon/tmp103.c b/drivers/hwmon/tmp103.c new file mode 100644 index 000..01119a6 --- /dev/null +++ b/drivers/hwmon/tmp103.c @@ -0,0 +1,304 @@ +/* + * Texas Instruments TMP103 SMBus temperature sensor driver + * Copyright (C) 2014 Heiko Schocher h...@denx.de + * + * Based on: + * Texas Instruments TMP102 SMBus temperature sensor driver + * + * Copyright (C) 2010 Steven King sfk...@fdwdc.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the
Re: kmemleak: Unable to handle kernel paging request
On 6/12/14, Catalin Marinas catalin.mari...@arm.com wrote: On Thu, Jun 12, 2014 at 01:00:57PM +0100, Denis Kirjanov wrote: On 6/12/14, Denis Kirjanov k...@linux-powerpc.org wrote: On 6/12/14, Catalin Marinas catalin.mari...@arm.com wrote: On 11 Jun 2014, at 21:04, Denis Kirjanov k...@linux-powerpc.org wrote: On 6/11/14, Catalin Marinas catalin.mari...@arm.com wrote: On Wed, Jun 11, 2014 at 04:13:07PM +0400, Denis Kirjanov wrote: I got a trace while running 3.15.0-08556-gdfb9454: [ 104.534026] Unable to handle kernel paging request for data at address 0xc0007f00 Were there any kmemleak messages prior to this, like kmemleak disabled? There could be a race when kmemleak is disabled because of some fatal (for kmemleak) error while the scanning is taking place (which needs some more thinking to fix properly). No. I checked for the similar problem and didn't find anything relevant. I'll try to bisect it. Does this happen soon after boot? I guess it’s the first scan (scheduled at around 1min after boot). Something seems to be telling kmemleak that there is a valid memory block at 0xc0007f00. Yeah, it happens after a while with a booted system so that's the first kmemleak scan. I've bisected to this commit: d4c54919ed86302094c0ca7d48a8cbd4ee753e92 mm: add !pte_present() check on existing hugetlb_entry callbacks. Reverting the commit fixes the issue I can't figure how this causes the problem but I have more questions. Is 0xc0007f00 address always the same in all crashes? If yes, you could comment out start_scan_thread() in kmemleak_late_init() to avoid the scanning thread starting. Once booted, you can run: echo dump=0xc0007f00 /sys/kernel/debug/kmemleak and check the dmesg for what kmemleak knows about that address, when it was allocated and whether it should be mapped or not. The address is always the same. [ 179.466239] kmemleak: Object 0xc0007f00 (size 16777216): [ 179.466503] kmemleak: comm swapper/0, pid 0, jiffies 4294892300 [ 179.466508] kmemleak: min_count = 0 [ 179.466512] kmemleak: count = 0 [ 179.466517] kmemleak: flags = 0x1 [ 179.466522] kmemleak: checksum = 0 [ 179.466526] kmemleak: backtrace: [ 179.466531] [c0afc3dc] .memblock_alloc_range_nid+0x68/0x88 [ 179.466544] [c0afc444] .memblock_alloc_base+0x20/0x58 [ 179.466553] [c0ae96cc] .alloc_dart_table+0x5c/0xb0 [ 179.466561] [c0aea300] .pmac_probe+0x38/0xa0 [ 179.466569] [0002166c] 0x2166c [ 179.466579] [00ae0e68] 0xae0e68 [ 179.466587] [9bc4] 0x9bc4 -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 01/36] ARM: OMAP3: hwmod: Fix gpmc memory resource space
* Roger Quadros rog...@ti.com [140611 01:58]:
Missing description? Probably not an urgent fix or does
this fix something?
Regards,
Tony
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 71ac7d5..f2848a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3426,7 +3426,7 @@ static struct omap_hwmod_addr_space
omap3xxx_counter_32k_addrs[] = {
static struct omap_hwmod_addr_space omap3xxx_gpmc_addrs[] = {
{
.pa_start = 0x6e00,
- .pa_end = 0x6e000fff,
+ .pa_end = 0x6e0002d4,
.flags = ADDR_TYPE_RT
},
{ }
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/36] ARM: OMAP3: hwmod: Fix gpmc memory resource space
On 06/13/2014 10:13 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [140611 01:58]:
Missing description? Probably not an urgent fix or does
this fix something?
Doesn't fix anything. It is just for correctness. I'll add the description.
cheers,
-roger
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 71ac7d5..f2848a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3426,7 +3426,7 @@ static struct omap_hwmod_addr_space
omap3xxx_counter_32k_addrs[] = {
static struct omap_hwmod_addr_space omap3xxx_gpmc_addrs[] = {
{
.pa_start = 0x6e00,
-.pa_end = 0x6e000fff,
+.pa_end = 0x6e0002d4,
.flags = ADDR_TYPE_RT
},
{ }
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/36] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
* Roger Quadros rog...@ti.com [140611 01:58]: Since the Interrupt Events are used only by the NAND driver, there is no point in managing the Interrupt registers in the GPMC driver and complicating it with irqchip modeling. Let's manage the interrupt registers directly in the NAND driver and get rid of irqchip model from GPMC driver. Get rid of IRQ commands and unused commands from gpmc_configure() in the GPMC driver. This seems like a step backward to me. The GPMC interrupt enable register can do edge detection on the wait pins, how is that limited to NAND? Further, let's not start mixing GPMC hardware module register access with the NAND driver register access. They can be clocked separately. And bugs in the NAND driver can cause issues in other GPMC using drivers. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 06/36] mtd: nand: omap: Move gpmc_update_nand_reg to nand driver
* Roger Quadros rog...@ti.com [140611 01:58]: GPMC and NAND drivers share the same register space but never use the same registers. As there is no clear address seperation between the registers for GPMC and NAND, we can't easily split it up into 2 regions i.e. one for GPMC and other for NAND. Instead, we simply remap the entire register space in both the drivers. The NAND driver doesn't re-request the region as it is already requested by the GPMC driver (parent). Oh now, let's not do this. It's best to limit GPMC register access to the GPMC driver. Even if we need to export few NAND specific functions from the GPMC driver. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 07/36] mtd: nand: omap: Move NAND write protect code from GPMC to NAND driver
* Roger Quadros rog...@ti.com [140611 01:58]: The write protect (WP) pin is only used for NAND devices. So move the code into the NAND driver. Eek, n! Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Networking
On Fri, Jun 13, 2014 at 8:59 AM, Johannes Berg
johan...@sipsolutions.net wrote:
On Fri, 2014-06-13 at 06:48 +, Linus Torvalds wrote:
On Thu, Jun 12, 2014 at 12:14 PM, David Miller da...@davemloft.net wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
Hmm. I get *lots* of the appended messages from iwlwifi now. Things
still seem to work, but ...
This is a Haswell laptop with bog-standard intel wireless:
01:00.0 Network controller: Intel Corporation Wireless 7260 (rev 6b)
Any ideas?
Looks odd.
If the stacktrace/message
[ 273.783438] unknown: hw csum failure
[ 273.783449] CPU: 2 PID: 2199 Comm: Chrome_IOThread Not tainted
3.15.0-11906-g6d87c225f5d8 #8
[ 273.783451] Hardware name: Sony Corporation SVP11213CXB/VAIO, BIOS
R0270V7 05/17/2013
[ 273.783461] Call Trace:
[ 273.783477] [8159d199] ? dump_stack+0x41/0x51
[ 273.783488] [814a4f1d] ?
skb_copy_and_csum_datagram_iovec+0xfd/0x110
[ 273.783494] [8150e2ea] ? udp_recvmsg+0x1ca/0x390
[ 273.783500] [81518e95] ? inet_recvmsg+0x65/0x80
[ 273.783506] [814971f5] ? sock_recvmsg+0x95/0xd0
[ 273.783511] [81197862] ? ep_send_events_proc+0xa2/0x1b0
[ 273.783513] [811977c0] ? ep_read_events_proc+0xb0/0xb0
[ 273.783516] [81497325] ? SYSC_recvfrom+0xb5/0x110
[ 273.783521] [8108bdc0] ? wake_up_state+0x10/0x10
[ 273.783527] [815a3d92] ? system_call_fastpath+0x16/0x1b
is to be believed, then I'm not sure why you think iwlwifi is involved
though.
Either way, iwlwifi doesn't support HW checksumming, so it failing makes
no sense, it's not there to start with.
The only thing that touched this seems to be Tom's patch:
commit 7e3cead5172927732f51fde77fef6f521e22f209
Author: Tom Herbert therb...@google.com
Date: Tue Jun 10 18:54:19 2014 -0700
net: Save software checksum complete
but I'm not familiar enough to say where this leads.
If it's iwlwifi, then maybe that commit broke something with devices
that don't support checksumming?
Tom posted some fixes for this:
http://marc.info/?l=linux-netdevm=140261417832399w=2
I can confirm the first one fixes the issue I was having (10s delay in
ssh login), cfr. http://marc.info/?l=linux-netdevm=140257250715322w=2
However, the second patch reintroduces the bad behavior again?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/36] ARM: dts: OMAP2+: Fix NAND device nodes
* Roger Quadros rog...@ti.com [140611 01:58]: Add compatible id, GPMC register resource and interrupt resource to NAND controller nodes. Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/am335x-evm.dts | 8 ++-- arch/arm/boot/dts/am335x-igep0033.dtsi | 8 ++-- arch/arm/boot/dts/am43x-epos-evm.dts | 8 ++-- arch/arm/boot/dts/omap3-devkit8000.dts | 9 +++-- arch/arm/boot/dts/omap3-evm-37xx.dts | 10 +++--- arch/arm/boot/dts/omap3-igep0020.dts | 10 +++--- arch/arm/boot/dts/omap3-igep0030.dts | 8 ++-- arch/arm/boot/dts/omap3-ldp.dts | 10 +++--- arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 10 +++--- arch/arm/boot/dts/omap3-lilly-dbb056.dts | 7 --- arch/arm/boot/dts/omap3430-sdp.dts | 8 ++-- 11 files changed, 69 insertions(+), 27 deletions(-) diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts index 6028217..fa25f2b 100644 --- a/arch/arm/boot/dts/am335x-evm.dts +++ b/arch/arm/boot/dts/am335x-evm.dts @@ -437,9 +437,13 @@ status = okay; pinctrl-names = default; pinctrl-0 = nandflash_pins_s0; - ranges = 0 0 0x0800 0x1000; /* CS0: NAND */ + ranges = 0 0 0x0800 0x1000 /* CS0 space, 16MB */ + 255 0 0x5000 0x36c; /* GPMC reg */ And here too let's not let the NAND driver tinker with the GPMC registers. Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] tracing: Improve message of empty set_ftrace_notrace file
When there's no entry in set_ftrace_notrace, it'll print nothing, but
it's better to print something like below like set_graph_notrace does:
no functions disabled
Reported-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
also updated the ftrace/nograph-v3 branch..
kernel/trace/ftrace.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index b375cf2cd786..ff402e092df1 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2593,8 +2593,10 @@ static void *t_start(struct seq_file *m, loff_t *pos)
* off, we can short cut and just print out that all
* functions are enabled.
*/
- if (iter-flags FTRACE_ITER_FILTER
- ftrace_hash_empty(ops-filter_hash)) {
+ if ((iter-flags FTRACE_ITER_FILTER
+ftrace_hash_empty(ops-filter_hash)) ||
+ (iter-flags FTRACE_ITER_NOTRACE
+ftrace_hash_empty(ops-notrace_hash))) {
if (*pos 0)
return t_hash_start(m, pos);
iter-flags |= FTRACE_ITER_PRINTALL;
@@ -2639,7 +2641,10 @@ static int t_show(struct seq_file *m, void *v)
return t_hash_show(m, iter);
if (iter-flags FTRACE_ITER_PRINTALL) {
- seq_printf(m, all functions enabled \n);
+ if (iter-flags FTRACE_ITER_NOTRACE)
+ seq_printf(m, no functions disabled \n);
+ else
+ seq_printf(m, all functions enabled \n);
return 0;
}
--
1.7.9.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] Use Tegra's microsecond counter for udelay()
On Thu, Jun 12, 2014 at 09:38:28PM +0200, Stephen Warren wrote: On 06/12/2014 09:58 AM, Peter De Schrijver wrote: This patchset introduces support for Tegra's microsecond counter as the udelay() timer. This is useful on Tegra SoCs which do not have an arch timer such as Tegra20 and Tegra30. Using the microsecond counter instead of a delay based loop avoids potential problems during cpu frequency changes. The set consists of 3 patches: Patch 1 introduces a new call which is used by the ARM architecture delay timer code to prevent changing the delay timer after calibration is finished and thus can be in use. Patch 2 adds logic to choose the delay timer with the highest resolution. This allows the same registration code to be used on all Tegra SoCs and yet use the higher resolution arch timer when available (eg on Tegra114 or Tegra124). Patch 3 adds the actual delay timer code. Patch set has been verified on ventana (Tegra20), beaver (Tegra30), dalmore (Tegra114) and jetson TK1 (Tegra124). Russell, Paul, do patches 1 and 2 look good to you? If so, if you can ack them, I'd be happy to queue this series in the Tegra git tree. If that doesn't work for you, please let me know who will apply these patches. Thanks. Changes since v1: * Address review comments That's not a very useful description of the changes, and there's no V2 in the subject... Yes... something went wrong it seems... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] USB: ftdi_sio: add GPIO support
On Mon, Jun 9, 2014 at 3:21 PM, Sascha Silbe x-li...@infra-silbe.de wrote: The chips can operate either in regular or in bitbang mode. Care was taken to prevent using GPIOs if the serial device is in use and vice versa. Very interesting patch! I've seen USB-based GPIO things before but never a dual-mode thing. There was already a comment to move the implementation to a separate file, which I won't repeat. But I also want to bring the device model into question: normally when a mother device spawns children across different subsystems we model them as MFD devices (drivers/mfd) that instantiate children for the different subsystems. So you could spawn a serial and a GPIO device from a USB-based hub device there. I do not know if that is really apropriate in this case. It seems the device is first and foremost FTDI. But it could still spawn a child platform device for the GPIO stuff so that this can live as a separate driver under drivers/gpio/gpio-ftdi.c or similar. You could then use something like: struct platform_device *gdev; gdev = platform_device_alloc(gpio-ftdi, PLATFORM_DEVID_AUTO); /* pdata contains communication cookie for callbacks etc */ ret = platform_device_add_data(gdev, pdata, sizeof(*pdata)); ret = platform_device_add(gdev); Then we can probe that device normally in the GPIO subsystem like any other driver, just that it needs some linux/usb/ftdi.h header or similar to define the function calls to communicate with the FTDI driver. However Greg is device core maintainer and may have better ideas about this! Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/36] ARM: OMAP2+: gpmc: Allow drivers to reconfigure GPMC settings timings
* Roger Quadros rog...@ti.com [140611 01:58]: Some devices (e.g. TUSB6010, omap-onenand) need to reconfigure the GPMC timings in order to operate with different peripheral clock frequencies. Introduce omap_gpmc_retime() to allow them to do that. The driver needs to pass the chips select number, GPMC settings and Device timings to omap_gpmc_retime(). NOTE: Device tree and board code must still pass the most conservative timings to GPMC so that the device can be probed by the respective driver. e.g. Onenand must operate in asynchronous mode at bootup. The device driver can then request for more optimal timings via omap_gpmc_retime(). Hmm but many of the devices are Linux generic like sms91x and 8250 so it's not nice to start stuffing omap bus specific data there. I wonder if we should just keep device specific gpmc-smc91x.c etc in drivers/memory? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [-next] Regression: ssh log in slowdown
Hi Tom,
cc lkml, as this is now in mainline
On Fri, Jun 13, 2014 at 2:59 AM, Tom Herbert therb...@google.com wrote:
net: Save software checksum complete
In skb_checksum complete, if we need to compute the checksum for the
packet (via skb_checksum) save the result as CHECKSUM_COMPLETE.
Subsequent checksum verification can use this.
Also, added csum_complete_sw flag to distinguish between software and
hardware generated checksum complete, we should always be able to trust
the software computation.
Signed-off-by: Tom Herbert therb...@google.com
Signed-off-by: David S. Miller da...@davemloft.net
Reverting this commit fixes the issue.
Anyone with a clue?
Hi Geert,
I'm very sorry that I seemed to have missed your initial bug report,
thanks for bisecting the problem. I have posted a fix for this, please
verify it if you can
Thanks for your patches!
I assume this is the series [PATCH 0/4] Checksum fixes
(marc.info/?l=linux-netdevm=140261417832399w=2)?
As I'm not subscribed to netdev, I cannot reply to that thread.
[PATCH 1/4] net: Fix save software checksum complete fixes the issue
for me.
However, [PATCH 2/4] udp: call __skb_checksum_complete when doing full
checksum reintroduces the exact same bad behavior :-(
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/36] ARM: OMAP2+: gpmc: Allow drivers to query GPMC_CLK period
* Roger Quadros rog...@ti.com [140611 01:59]: GPMC_CLK is the external clock output pin that is used for syncronous accesses. Device drivers need to know the fastest possible GPMC_CLK period in order to calculate the most optimal device timings. Add the function omap_gpmc_get_clk_period() to allow drivers to get the nearset possible (equal to or greater than) GPMC_CLK period given the minimum clock period supported by the attached device. This is especially needed by the onenand driver as it calculates device timings on the fly for various onenand speed grades. Here too this should probably still be done by the gpmc to driver glue layer, not by the actual driver that shoud be Linux generic. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [Intel-gfx] video: X sets brightness to zero after resume
Hi, On 06/13/2014 03:28 AM, Aaron Lu wrote: On 06/12/2014 08:42 PM, Kalle Valo wrote: Hi Aaron, after your commit 0e9f81d3b7c (ACPI / video: Add systems that should favour native backlight interface) I have had an regression that every time after resume the display brightness has been set to zero and I need to manually set it to non-zero to see something again. Finally I started to investigate this more closely and it seems that X sets it to zero for some reason. I added a WARN_ON() and few printks to brightness_store() in drivers/video/backlight/backlight.c and this is what I see during resume: [ 49.228221] [ cut here ] [ 49.228229] WARNING: CPU: 1 PID: 1133 at drivers/video/backlight/backlight.c:173 brightness_store+0x3c/0x120( ) [ 49.228230] Modules linked in: ctr ccm uvcvideo videobuf2_core videodev videobuf2_vmalloc videobuf2_memops fu se arc4 iwldvm sha256_generic kvm_intel kvm mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_gene ric iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 snd_hda_intel snd_hda_controller nf_nat_ipv4 nf_nat snd_hda_cod ec nf_conntrack snd_hwdep snd_pcm_oss iwlwifi snd_mixer_oss snd_pcm ip_tables x_tables thinkpad_acpi snd_seq_dum my snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq cfg80211 snd_timer snd_seq_device snd bnep rfcomm bluetooth psmouse soundcore nvram ehci_pci ehci_hcd rfkill wmi binfmt_misc ext4 jbd2 mbcache sd_mod fbcon tileblit font bitblit softcursor i915 drm_kms_helper drm cfbcopyarea i2c_algo_bit intel_gtt agpgart i2c_core video xhci_hcd cfbimgblt cfbfillrect e1000e sdhci_pci sdhci ptp pps_core mmc_core ahci libahci [ 49.228281] CPU: 1 PID: 1133 Comm: Xorg Tainted: GW 3.15.0-rc7-wl-ath+ #259 [ 49.228282] Hardware name: LENOVO 2324JB2/2324JB2, BIOS G2ET82WW (2.02 ) 09/11/2012 [ 49.228283] 817e4000 814cbee3 [ 49.228285] 810493bc 88020e2d1c98 880213bc9f10 0002 [ 49.228287] 8800c5dfc198 88020d7cbf50 81290a1c 88020e792800 [ 49.228288] Call Trace: [ 49.228293] [814cbee3] ? dump_stack+0x41/0x51 [ 49.228296] [810493bc] ? warn_slowpath_common+0x8c/0xc0 [ 49.228298] [81290a1c] ? brightness_store+0x3c/0x120 [ 49.228301] [811d7242] ? kernfs_fop_write+0x112/0x170 [ 49.228304] [8116791b] ? vfs_write+0xcb/0x1f0 [ 49.228306] [81167e20] ? SyS_write+0x50/0xb0 [ 49.228308] [814dd312] ? system_call_fastpath+0x16/0x1b [ 49.228309] ---[ end trace a1f60d12df64bdbe ]--- [ 49.228310] brightness=0 [ 49.228310] set brightness to 0 And this is PID 1133: root 1133 0.7 0.2 131504 20192 tty7 Ss+ 15:16 0:00 /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch -background none If I set video.use_native_backlight=0 in kernel command line the problem goes away. Or if I revert your commit 0e9f81d3b7c the problem also goes away. Any ideas? Not really... I've added i915 people maybe they have an idea. This is a known issue in xf86-video-intel, which gets exposed due to the video.use_native_backlight=1 option. This should be fixed in the latest 2.99.912 xf86-video-intel release. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: Proposal to realize hot-add *several sections one time*
On 2014/6/12 15:07, David Rientjes wrote: On Thu, 12 Jun 2014, Zhang Zhen wrote: % echo start_address_of_new_memory count_of_sections /sys/devices/system/memory/probe Then, [start_address_of_new_memory, start_address_of_new_memory + count_of_sections * memory_block_size] memory range is hot-added. If this proposal is reasonable, i will send a patch to realize it. The problem is knowing how much memory is being onlined so that you can definitively determine what count_of_sections should be. The number of pages per memory section depends on PAGE_SIZE and SECTION_SIZE_BITS which differ depending on the architectures that support this interface. So if you support count_of_sections, it would return errno even though you have onlined some sections. Hum, sorry. My expression is not right. The count of sections one time hot-added depends on sections_per_block. Ok, so you know specifically what sections_per_block is for your platform so you know exactly how many sections need to be added. Now we are porting the memory-hotplug to arm. But we can only hot-add *fixed number of sections one time* on particular architecture. Whether we can add an argument on behalf of the count of the blocks to add ? % echo start_address_of_new_memory count_of_blocks /sys/devices/system/memory/probe Then, [start_address_of_new_memory, start_address_of_new_memory + count_of_blocks * memory_block_size] memory range is hot-added. As I said, if the above returns errno at some point, it still can result in some sections being onlined. To be clear: if echo 0x1000 /sys/devices/system/memory/probe fails, the section starting at address 0x1000 failed to be onlined for the reason specified by errno. If we follow your suggestion to specify how many sections to online, if echo '0x1000 16' /sys/devices/system/memory/probe fails, eight sections could have been successfully onlined at address 0x1000 and then we encountered a failure (perhaps because the next sections were already onlined, we get an -EEXIST). We don't know what we successfully onlined. This could be mitigated, but there would have to be a convincing reason that this is better than using the currently functionally in a loop and properly handling your error codes. Hi David, I think you are right. We had better to use the currently functionally in a loop if we need to add several blocks. In this way, we can get an errno in time if a block failed to be onlined. Thanks for your comments. I got it. -- 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: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [Intel-gfx] video: X sets brightness to zero after resume
Hans de Goede hdego...@redhat.com writes: If I set video.use_native_backlight=0 in kernel command line the problem goes away. Or if I revert your commit 0e9f81d3b7c the problem also goes away. Any ideas? Not really... I've added i915 people maybe they have an idea. This is a known issue in xf86-video-intel, which gets exposed due to the video.use_native_backlight=1 option. This should be fixed in the latest 2.99.912 xf86-video-intel release. Ok, thanks. As Ubuntu 12.04 doesn't have that I'll continue to use video.use_native_backlight=0 until I update my distro. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] lib/string_helpers.c: constify static arrays
Complement commit 68aecfb979 (lib/string_helpers.c: make arrays
static) by making the arrays const -- not only pointing to const
strings. This moves them out of the data section to the r/o data
section:
textdata bss dec hex filename
1150 176 01326 52e lib/string_helpers.old.o
1326 0 01326 52e lib/string_helpers.new.o
Cc: James Bottomley james.bottom...@hansenpartnership.com
Signed-off-by: Mathias Krause mini...@googlemail.com
---
lib/string_helpers.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/lib/string_helpers.c b/lib/string_helpers.c
index ed5c1454dd..29033f319a 100644
--- a/lib/string_helpers.c
+++ b/lib/string_helpers.c
@@ -25,12 +25,15 @@
int string_get_size(u64 size, const enum string_size_units units,
char *buf, int len)
{
- static const char *units_10[] = { B, kB, MB, GB, TB, PB,
- EB, ZB, YB, NULL};
- static const char *units_2[] = {B, KiB, MiB, GiB, TiB, PiB,
-EiB, ZiB, YiB, NULL };
- static const char **units_str[] = {
- [STRING_UNITS_10] = units_10,
+ static const char *const units_10[] = {
+ B, kB, MB, GB, TB, PB, EB, ZB, YB, NULL
+ };
+ static const char *const units_2[] = {
+ B, KiB, MiB, GiB, TiB, PiB, EiB, ZiB, YiB,
+ NULL
+ };
+ static const char *const *const units_str[] = {
+ [STRING_UNITS_10] = units_10,
[STRING_UNITS_2] = units_2,
};
static const unsigned int divisor[] = {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] lib: add size unit t/p/e to memparse
On Fri, Jun 13, 2014 at 07:54:44AM +0200, Brendan Hide wrote: On 12/06/14 23:15, Andrew Morton wrote: On Wed, 2 Apr 2014 16:54:37 +0800 Gui Hecheng guihc.f...@cn.fujitsu.com wrote: + * %K (for kibibytes, or 1024 bytes), + * %M (for mebibytes, or 1048576 bytes), + * %G (for gibibytes, or 1073741824 bytes), + * %T (for tebibytes, or 1099511627776 bytes), + * %P (for pebibytes, or 1125899906842624 bytes), + * %E (for exbibytes, or 1152921504606846976 bytes). I'm afraid I find these names quite idiotic - we all know what the traditional terms mean so why go and muck with it. Also, kibibytes sounds like cat food. Hi, Andrew While I agree it sounds like cat food, it seemed like a good opportunity to fix a minor issue that is otherwise unlikely to be fixed for a very long time. Should we feel uncomfortable with the patch, as is, because of language/correctness friction? Pedantry included, the patch is correct. ;) Last night, I wrote a very grumpy reply to Andrew. I'm glad I didn't send it, because Brendan has managed to cover at least one of my points much more politely than I did. My other comment is that TB vs TiB is a 10% difference in the magnitude of the number, and so the accumulated error is now no longer small enough to be brushed under the carpet as we all did in days past. By Andrew's thinking, a 4 TB disk is 3.638 TB in size. I'd say a 4 TB disk is 3.638 TiB in size, and I can be precise (±1GB in the latter case) with both values. Hugo. PS. Let's just not talk about 1.44 MB floppy disks. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- 2 + 2 = 5, for sufficiently large values of 2. --- signature.asc Description: Digital signature
Re: [PATCH 05/36] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
On 06/13/2014 10:18 AM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140611 01:58]: Since the Interrupt Events are used only by the NAND driver, there is no point in managing the Interrupt registers in the GPMC driver and complicating it with irqchip modeling. Let's manage the interrupt registers directly in the NAND driver and get rid of irqchip model from GPMC driver. Get rid of IRQ commands and unused commands from gpmc_configure() in the GPMC driver. This seems like a step backward to me. The GPMC interrupt enable register can do edge detection on the wait pins, how is that limited to NAND? OK. But wait pin edge detection was not yet being used and I couldn't think of how it would ever be used. Any ideas? Further, let's not start mixing GPMC hardware module register access with the NAND driver register access. They can be clocked separately. And bugs in the NAND driver can cause issues in other GPMC using drivers. I understood that NAND controller is integrated into the GPMC module and they are clocked the same. Not sure why the hardware designers would keep the registers so closely knit. FYI. memory/ti-amif.c and mtd/nand/davinci_nand.c share the AMIF register space in the same way. I thought it'd be nice to be consistent across TI drivers. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/9] staging: dgap: remove unused paramter in dgap_parsefile()
remove parameter is not used in dgap_parsefile().
Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
---
drivers/staging/dgap/dgap.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 38749d0..c1f2798 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -174,7 +174,7 @@ static void dgap_remove_tty_sysfs(struct device *c);
/*
* Function prototypes from dgap_parse.h
*/
-static int dgap_parsefile(char **in, int remove);
+static int dgap_parsefile(char **in);
static struct cnode *dgap_find_config(int type, int bus, int slot);
static uint dgap_config_get_num_prts(struct board_t *bd);
static char *dgap_create_config_string(struct board_t *bd, char *string);
@@ -852,7 +852,7 @@ static int dgap_firmware_load(struct pci_dev *pdev, int
card_type)
*/
tmp_ptr = dgap_config_buf;
- if (dgap_parsefile(tmp_ptr, TRUE) != 0) {
+ if (dgap_parsefile(tmp_ptr) != 0) {
kfree(dgap_config_buf);
return -EINVAL;
}
@@ -6427,7 +6427,7 @@ static void dgap_remove_tty_sysfs(struct device *c)
/*
* Parse a configuration file read into memory as a string.
*/
-static int dgap_parsefile(char **in, int remove)
+static int dgap_parsefile(char **in)
{
struct cnode *p, *brd, *line, *conc;
int rc;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] staging: dgap: get rid of brd-firstminor because it is 0
firstminor in struct borad_t is always zero, so it
can be removed.
Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
---
drivers/staging/dgap/dgap.c |9 -
drivers/staging/dgap/dgap.h |1 -
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index c1f2798..352eb1b 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -684,7 +684,6 @@ static int dgap_found_board(struct pci_dev *pdev, int id,
int boardnum)
/* store the info for the board we've found */
brd-magic = DGAP_BOARD_MAGIC;
brd-boardnum = boardnum;
- brd-firstminor = 0;
brd-vendor = dgap_pci_tbl[id].vendor;
brd-device = dgap_pci_tbl[id].device;
brd-pdev = pdev;
@@ -4168,8 +4167,8 @@ static int dgap_tty_register_ports(struct board_t *brd)
struct device *classp;
classp = tty_port_register_device(brd-serial_ports[i],
- brd-serial_driver,
- brd-firstminor + i, NULL);
+ brd-serial_driver,
+ i, NULL);
if (IS_ERR(classp)) {
ret = PTR_ERR(classp);
@@ -4180,8 +4179,8 @@ static int dgap_tty_register_ports(struct board_t *brd)
ch-ch_tun.un_sysfs = classp;
classp = tty_port_register_device(brd-printer_ports[i],
- brd-print_driver,
- brd-firstminor + i, NULL);
+ brd-print_driver,
+ i, NULL);
if (IS_ERR(classp)) {
ret = PTR_ERR(classp);
diff --git a/drivers/staging/dgap/dgap.h b/drivers/staging/dgap/dgap.h
index 03c020e..c00b2e2 100644
--- a/drivers/staging/dgap/dgap.h
+++ b/drivers/staging/dgap/dgap.h
@@ -529,7 +529,6 @@ struct macounter {
struct board_t {
int magic; /* Board Magic number. */
int boardnum; /* Board number: 0-3 */
- int firstminor; /* First minor, e.g. 0, 30, 60 */
int type; /* Type of board */
char*name; /* Product Name */
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] staging: dgap: introduce dgap_tty_free() for freeing channels.
It should be called after dgap_tty_register_ports() is failed.
So channels which are allocated in dgap_tty_init() will be freed.
Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
---
drivers/staging/dgap/dgap.c | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 352eb1b..eab8fd5 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -123,6 +123,7 @@ static void dgap_tty_send_xchar(struct tty_struct *tty,
char ch);
static int dgap_tty_register(struct board_t *brd);
static int dgap_tty_init(struct board_t *);
+static void dgap_tty_free(struct board_t *);
static void dgap_cleanup_tty(struct board_t *);
static void dgap_carrier(struct channel_t *ch);
static void dgap_input(struct channel_t *ch);
@@ -960,8 +961,10 @@ static int dgap_firmware_load(struct pci_dev *pdev, int
card_type)
return ret;
ret = dgap_tty_register_ports(brd);
- if (ret)
+ if (ret) {
+ dgap_tty_free(brd);
return ret;
+ }
brd-state = BOARD_READY;
brd-dpastatus = BD_RUNNING;
@@ -1488,6 +1491,18 @@ free_chan:
}
/*
+ * dgap_tty_free()
+ *
+ * Free the channles which are allocated in dgap_tty_init().
+ */
+static void dgap_tty_free(struct board_t *brd)
+{
+ int i;
+
+ for (i = 0; i brd-nasync; i++)
+ kfree(brd-channels[i]);
+}
+/*
* dgap_cleanup_tty()
*
* Uninitialize the TTY portion of this driver. Free all memory and
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] staging: dgap: introduce dgap_free_irq()
dgap_free_irq() will free the irq which is requested in
dgap_request_irq().
Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
---
drivers/staging/dgap/dgap.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index eab8fd5..497e6f3 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -190,6 +190,7 @@ static void dgap_do_conc_load(struct board_t *brd, u8
*uaddr, int len);
#endif
static int dgap_after_config_loaded(struct board_t *brd);
static int dgap_request_irq(struct board_t *brd);
+static void dgap_free_irq(struct board_t *brd);
static void dgap_get_vpd(struct board_t *brd);
static void dgap_do_reset_board(struct board_t *brd);
@@ -634,8 +635,7 @@ static void dgap_cleanup_board(struct board_t *brd)
if (!brd || brd-magic != DGAP_BOARD_MAGIC)
return;
- if (brd-intr_used brd-irq)
- free_irq(brd-irq, brd);
+ dgap_free_irq(brd);
tasklet_kill(brd-helper_tasklet);
@@ -816,6 +816,12 @@ static int dgap_request_irq(struct board_t *brd)
return 0;
}
+static void dgap_free_irq(struct board_t *brd)
+{
+ if (brd-intr_used brd-irq)
+ free_irq(brd-irq, brd);
+}
+
static int dgap_firmware_load(struct pci_dev *pdev, int card_type)
{
struct board_t *brd = dgap_board[dgap_numboards - 1];
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/9] staging: dgap: introduce dgap_tty_unregister()
dgap_tty_unregister() will unregister serial_driver
and print_driver, and also free related variables.
Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
---
drivers/staging/dgap/dgap.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 497e6f3..4ea7a33 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -122,6 +122,7 @@ static int dgap_tty_put_char(struct tty_struct *tty,
unsigned char c);
static void dgap_tty_send_xchar(struct tty_struct *tty, char ch);
static int dgap_tty_register(struct board_t *brd);
+static void dgap_tty_unregister(struct board_t *brd);
static int dgap_tty_init(struct board_t *);
static void dgap_tty_free(struct board_t *);
static void dgap_cleanup_tty(struct board_t *);
@@ -1320,6 +1321,14 @@ free_serial_drv:
return rc;
}
+static void dgap_tty_unregister(struct board_t *brd)
+{
+ tty_unregister_driver(brd-print_driver);
+ tty_unregister_driver(brd-serial_driver);
+ put_tty_driver(brd-print_driver);
+ put_tty_driver(brd-serial_driver);
+}
+
/*
* dgap_tty_init()
*
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] staging: dgap: rename dgap_after_config_loaded() to dgap_alloc_flipbuf()
dgap_after_config_loaded() as function name doesn't tell
what it does.
Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
---
drivers/staging/dgap/dgap.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 4ea7a33..db8c93b 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -189,7 +189,7 @@ static void dgap_do_fep_load(struct board_t *brd, const u8
*ufep, int len);
#ifdef DIGI_CONCENTRATORS_SUPPORTED
static void dgap_do_conc_load(struct board_t *brd, u8 *uaddr, int len);
#endif
-static int dgap_after_config_loaded(struct board_t *brd);
+static int dgap_alloc_flipbuf(struct board_t *brd);
static int dgap_request_irq(struct board_t *brd);
static void dgap_free_irq(struct board_t *brd);
@@ -866,7 +866,7 @@ static int dgap_firmware_load(struct pci_dev *pdev, int
card_type)
kfree(dgap_config_buf);
}
- ret = dgap_after_config_loaded(brd);
+ ret = dgap_alloc_flipbuf(brd);
if (ret)
return ret;
/*
@@ -4142,7 +4142,7 @@ static int dgap_tty_ioctl(struct tty_struct *tty,
unsigned int cmd,
}
}
-static int dgap_after_config_loaded(struct board_t *brd)
+static int dgap_alloc_flipbuf(struct board_t *brd)
{
/*
* Initialize KME waitqueues...
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/9] staging: dgap: cleanup dgap_firmware_load() function
The dgap_firmware_load() has a lot of stuff beside
loding firmware. So some registering and initializing
for device are moved into dgap_init_one().
And also adds unwinding on error in dgap_init_one().
Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
---
drivers/staging/dgap/dgap.c | 81 ++
1 files changed, 50 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index c0016bd..e1347fb 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -199,7 +199,8 @@ static void dgap_do_reset_board(struct board_t *brd);
static int dgap_test_bios(struct board_t *brd);
static int dgap_test_fep(struct board_t *brd);
static int dgap_tty_register_ports(struct board_t *brd);
-static int dgap_firmware_load(struct pci_dev *pdev, int card_type);
+static int dgap_firmware_load(struct pci_dev *pdev, int card_type,
+ struct board_t* brd);
static void dgap_cleanup_module(void);
@@ -571,6 +572,7 @@ static int dgap_init_pci(void)
static int dgap_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
int rc;
+ struct board_t* brd;
if (dgap_numboards = MAXBOARDS)
return -EPERM;
@@ -583,8 +585,51 @@ static int dgap_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (rc)
return rc;
- dgap_numboards++;
- return dgap_firmware_load(pdev, ent-driver_data);
+ brd = dgap_board[dgap_numboards++];
+ rc = dgap_firmware_load(pdev, ent-driver_data, brd);
+ if (rc)
+ goto free_brd;
+
+ rc = dgap_alloc_flipbuf(brd);
+ if (rc)
+ goto free_brd;
+
+ rc = dgap_tty_register(brd);
+ if (rc)
+ goto free_flipbuf;
+
+ rc = dgap_request_irq(brd);
+ if (rc)
+ goto unregister_tty;
+
+ /*
+* Do tty device initialization.
+*/
+ rc = dgap_tty_init(brd);
+ if (rc 0)
+ goto free_irq;
+
+ rc = dgap_tty_register_ports(brd);
+ if (rc)
+ goto tty_free;
+
+ brd-state = BOARD_READY;
+ brd-dpastatus = BD_RUNNING;
+
+ return 0;
+
+tty_free:
+ dgap_tty_free(brd);
+free_irq:
+ dgap_free_irq(brd);
+unregister_tty:
+ dgap_tty_unregister(brd);
+free_flipbuf:
+ dgap_free_flipbuf(brd);
+free_brd:
+ kfree(brd);
+ dgap_board[--dgap_numboards] = NULL;
+ return rc;
}
static void dgap_remove_one(struct pci_dev *dev)
@@ -824,9 +869,9 @@ static void dgap_free_irq(struct board_t *brd)
free_irq(brd-irq, brd);
}
-static int dgap_firmware_load(struct pci_dev *pdev, int card_type)
+static int dgap_firmware_load(struct pci_dev *pdev, int card_type,
+ struct board_t* brd)
{
- struct board_t *brd = dgap_board[dgap_numboards - 1];
const struct firmware *fw;
char *tmp_ptr;
int ret;
@@ -867,9 +912,6 @@ static int dgap_firmware_load(struct pci_dev *pdev, int
card_type)
kfree(dgap_config_buf);
}
- ret = dgap_alloc_flipbuf(brd);
- if (ret)
- return ret;
/*
* Match this board to a config the user created for us.
*/
@@ -891,14 +933,6 @@ static int dgap_firmware_load(struct pci_dev *pdev, int
card_type)
return -EINVAL;
}
- ret = dgap_tty_register(brd);
- if (ret)
- return ret;
-
- ret = dgap_request_irq(brd);
- if (ret)
- return ret;
-
if (fw_info[card_type].bios_name) {
ret = request_firmware(fw, fw_info[card_type].bios_name,
pdev-dev);
@@ -961,21 +995,6 @@ static int dgap_firmware_load(struct pci_dev *pdev, int
card_type)
release_firmware(fw);
}
#endif
- /*
-* Do tty device initialization.
-*/
- ret = dgap_tty_init(brd);
- if (ret 0)
- return ret;
-
- ret = dgap_tty_register_ports(brd);
- if (ret) {
- dgap_tty_free(brd);
- return ret;
- }
-
- brd-state = BOARD_READY;
- brd-dpastatus = BD_RUNNING;
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/9] staging: dgap: introduce dgap_free_flipbuf()
dgap_free_flipbuf() will free flipbuf and flipflagbuf which
are allocated in dgap_alloc_flipbuf()
Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
---
drivers/staging/dgap/dgap.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index db8c93b..c0016bd 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -190,6 +190,7 @@ static void dgap_do_fep_load(struct board_t *brd, const u8
*ufep, int len);
static void dgap_do_conc_load(struct board_t *brd, u8 *uaddr, int len);
#endif
static int dgap_alloc_flipbuf(struct board_t *brd);
+static void dgap_free_flipbuf(struct board_t *brd);
static int dgap_request_irq(struct board_t *brd);
static void dgap_free_irq(struct board_t *brd);
@@ -4165,6 +4166,12 @@ static int dgap_alloc_flipbuf(struct board_t *brd)
return 0;
}
+static void dgap_free_flipbuf(struct board_t *brd)
+{
+ kfree(brd-flipbuf);
+ kfree(brd-flipflagbuf);
+}
+
/*
* Create pr and tty device entries
*/
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/36] ARM: OMAP2+: gpmc: Allow drivers to reconfigure GPMC settings timings
On 06/13/2014 10:25 AM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140611 01:58]: Some devices (e.g. TUSB6010, omap-onenand) need to reconfigure the GPMC timings in order to operate with different peripheral clock frequencies. Introduce omap_gpmc_retime() to allow them to do that. The driver needs to pass the chips select number, GPMC settings and Device timings to omap_gpmc_retime(). NOTE: Device tree and board code must still pass the most conservative timings to GPMC so that the device can be probed by the respective driver. e.g. Onenand must operate in asynchronous mode at bootup. The device driver can then request for more optimal timings via omap_gpmc_retime(). Hmm but many of the devices are Linux generic like sms91x and 8250 so it's not nice to start stuffing omap bus specific data there. Those drivers should never need to use this function. Hopefully they will work with a one time setup where we specify the timings in the DT. This function is primarily for use by omap-onenand and tusb6010, which are both OMAP specific. cheers, -roger I wonder if we should just keep device specific gpmc-smc91x.c etc in drivers/memory? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 9/9] staging: dgap: introduce dgap_release_remap()
The dgap_found_board() did request some memory region and
call ioremap, these should be released and unmaped
when one of functions which are called after dgap_found_board()
in dgap_init_one() is failed.
Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
---
drivers/staging/dgap/dgap.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index e1347fb..5c8e622 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -77,6 +77,7 @@ static int dgap_init_pci(void);
static int dgap_init_one(struct pci_dev *pdev, const struct pci_device_id
*ent);
static void dgap_remove_one(struct pci_dev *dev);
static int dgap_do_remap(struct board_t *brd);
+static void dgap_release_remap(struct board_t *brd);
static irqreturn_t dgap_intr(int irq, void *voidbrd);
static int dgap_tty_open(struct tty_struct *tty, struct file *file);
@@ -588,11 +589,11 @@ static int dgap_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
brd = dgap_board[dgap_numboards++];
rc = dgap_firmware_load(pdev, ent-driver_data, brd);
if (rc)
- goto free_brd;
+ goto cleanup_brd;
rc = dgap_alloc_flipbuf(brd);
if (rc)
- goto free_brd;
+ goto cleanup_brd;
rc = dgap_tty_register(brd);
if (rc)
@@ -626,7 +627,8 @@ unregister_tty:
dgap_tty_unregister(brd);
free_flipbuf:
dgap_free_flipbuf(brd);
-free_brd:
+cleanup_brd:
+ dgap_release_remap(brd);
kfree(brd);
dgap_board[--dgap_numboards] = NULL;
return rc;
@@ -1034,6 +1036,12 @@ static int dgap_do_remap(struct board_t *brd)
return 0;
}
+static void dgap_release_remap(struct board_t *brd)
+{
+ release_mem_region(brd-membase, 0x20);
+ release_mem_region(brd-membase + PCI_IO_OFFSET, 0x20);
+ iounmap(brd-re_map_membase);
+}
/*
*
* Function:
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Disable bus's drivers_autoprobe before rootfs has mounted
I am just worried if we change the behaviour of using gadget driver, can it be accepted by user? If you think it can be accepted if we can have some docs, we can implement manually binding for gadget driver from now on. user shouldn't have to deal with direct module insertion/removal (unless he's a developer and actually *wants* to do that). Docs are already in tree. The entire configfs interface has been documented, it's based on those documents that Matt started writing libusbg. -- balbi Yes, gadget-configfs is a good direction. I would like to know your plan for other gadget drivers (g_mass_storage, g_webcam, etc) they can be built dynamically too. We only provided a version of g_mass_storage in order to avoid regressions. We can't simply remove that driver from the kernel. All functions will be supported by configfs in future, and current driver will be deleted? I don't think we will be able to delete legacy drivers, but they're all supported through configfs. I guess only webcam is missing. - If yes, how to cover the user who still use the old file system? - If no, which binding way for udc and gadget driver will be used? going forward, we want to stick with configfs. ok, then, what's the plan for current bug for legacy gadget driver (eg, we can't load gadget driver before udc is ready)? I know this bug is existed from 3.10, we may need to at least 1 year for switch to configfs, it includes lots of user habit problems. The user will complaint this problem for more than 2 years. If you think we should fix this bug before we totally switch to configfs, I will continue to enhancement my gadget bus implementation, and let it support configfs and legacy gadget driver well. Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/36] ARM: OMAP2+: gpmc: Allow drivers to query GPMC_CLK period
On 06/13/2014 10:26 AM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140611 01:59]: GPMC_CLK is the external clock output pin that is used for syncronous accesses. Device drivers need to know the fastest possible GPMC_CLK period in order to calculate the most optimal device timings. Add the function omap_gpmc_get_clk_period() to allow drivers to get the nearset possible (equal to or greater than) GPMC_CLK period given the minimum clock period supported by the attached device. This is especially needed by the onenand driver as it calculates device timings on the fly for various onenand speed grades. Here too this should probably still be done by the gpmc to driver glue layer, not by the actual driver that shoud be Linux generic. Well, this is only needed by the omap-onenand driver to perform the timing calculations at run-time. Other option is to model the GPMC_CLK (external) as a clock and request the rate using the clock framework. But since this and the retime() is only used by 2 OMAP specific drivers, I'm not sure if it is worth the effort. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/13] kexec: Implementation of new syscall kexec_file_load
On Mon, Jun 09, 2014 at 11:41:37AM -0400, Vivek Goyal wrote: IIUC, COMMAND_LINE_SIZE gives max limits of running kernel and it does not tell us anything about command line size supported by kernel being loaded. Whatever you do, you do need a sane default because even querying the boot protocol is not reliable as the to-be-loaded kernel's boot protocol might be manipulated too, before signing (who knows what people do in the wild). So having a sane, unconditional fallback COMMAND_LINE_SIZE from the first kernel is a must, methinks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] pinctrl: sh-pfc: r8a7791: Add HSCIF pin support
On Tue, Jun 10, 2014 at 4:37 AM, Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com wrote: Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- V2: - Add pin map for hscif2_data_d. - Add Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com This v2 version applied for the v3.17 development cycle. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Networking
From: Linus Torvalds torva...@linux-foundation.org Date: Thu, 12 Jun 2014 23:48:57 -0700 On Thu, Jun 12, 2014 at 12:14 PM, David Miller da...@davemloft.net wrote: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master Hmm. I get *lots* of the appended messages from iwlwifi now. Things still seem to work, but ... This is a Haswell laptop with bog-standard intel wireless: 01:00.0 Network controller: Intel Corporation Wireless 7260 (rev 6b) Any ideas? Tom Herbert posted some checksumming fixes today, they might do the trick. I'll push them to you tomorrow. For reference: http://patchwork.ozlabs.org/patch/359390/ http://patchwork.ozlabs.org/patch/359391/ http://patchwork.ozlabs.org/patch/359392/ http://patchwork.ozlabs.org/patch/359393/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] spi/pxa2xx: fix incorrect SW mode chipselect setting for BayTrail LPSS SPI
From: Chew, Chiau Ee chiau.ee.c...@intel.com
It was observed that after module removal followed by insertion,
the SW mode chipselect is not properly set. Thus causing transfer
failure due to incorrect CS toggling.
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
---
drivers/spi/spi-pxa2xx.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index a98df7e..fe79210 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -118,6 +118,7 @@ static void lpss_ssp_setup(struct driver_data *drv_data)
*/
orig = readl(drv_data-ioaddr + offset + SPI_CS_CONTROL);
+ /* Test SPI_CS_CONTROL_SW_MODE bit enabling */
value = orig | SPI_CS_CONTROL_SW_MODE;
writel(value, drv_data-ioaddr + offset + SPI_CS_CONTROL);
value = readl(drv_data-ioaddr + offset + SPI_CS_CONTROL);
@@ -126,10 +127,13 @@ static void lpss_ssp_setup(struct driver_data *drv_data)
goto detection_done;
}
- value = ~SPI_CS_CONTROL_SW_MODE;
+ orig = readl(drv_data-ioaddr + offset + SPI_CS_CONTROL);
+
+ /* Test SPI_CS_CONTROL_SW_MODE bit disabling */
+ value = orig ~SPI_CS_CONTROL_SW_MODE;
writel(value, drv_data-ioaddr + offset + SPI_CS_CONTROL);
value = readl(drv_data-ioaddr + offset + SPI_CS_CONTROL);
- if (value != orig) {
+ if (value != (orig ~SPI_CS_CONTROL_SW_MODE)) {
offset = 0x800;
goto detection_done;
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] leds: USB: HID: Add support for MSI GT683R led panels
On Thu, Jun 12, 2014 at 11:34:12PM +0300, Janne Kanniainen wrote:
This driver adds support for USB controlled led panels that exists in
MSI GT683R laptop
Signed-off-by: Janne Kanniainen janne.kanniai...@gmail.com
---
Changes in v2:
- sorted headers to alphabetic order
- using devm_kzalloc
- using BIT(n)
- using usb_control_msg instead of usb_submit_urb
- removing unneeded code
Changes in v3:
- implemented as HID device
- some cleanups and bug fixes
Changes in v4:
- more cleanups
- support for selecting leds
- suppport for selecting status
Changes in v5:
- mode attribute documented under Documentation/ABI
- made array for led_classdev
- led devices uses now recommended naming scheme
.../ABI/testing/sysfs-class-hid-driver-gt683r | 10 +
drivers/hid/Kconfig| 11 +
drivers/hid/Makefile | 1 +
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-gt683r.c | 294
+
drivers/hid/hid-ids.h | 2 +-
drivers/hid/usbhid/hid-quirks.c| 2 +-
7 files changed, 319 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
create mode 100644 drivers/hid/hid-gt683r.c
diff --git a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
new file mode 100644
index 000..c4d604e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
@@ -0,0 +1,10 @@
+What:/sys/class/hidraw/hidraw/device/state
You should probably stick to mode (rather than state) throughout (it
seems you just forgot to update a few uses).
+Date:Jun 2014
+KernelVersion: 3.15
This should be 3.17.
+Contact: Janne Kanniainen janne.kanniai...@gmail.com
+Description:
+ Set the mode of LEDs
+
+ 0 - normal
+ 1 - audio
+ 2 - breathing
Perhaps expand this with a short paragraph describing the different
modes.
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 7af9d0b..d93e0ae 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -261,6 +261,17 @@ config HOLTEK_FF
Say Y here if you have a Holtek On Line Grip based game controller
and want to have force feedback support for it.
+config HID_GT683R
+ tristate MSI GT68xR LED support
+ depends on LEDS_CLASS USB_HID
+ ---help---
+ Say Y here if you want to enable support for the MSI GT68xR LEDS
+
+ This driver support following states normal, breathing and audio.
You could also use modes and expand this with the same description.
+ You can also select which leds you want to enable.
+ Currently the following devices are know to be supported:
+ - MSI GT683R
+
config HID_HUION
tristate Huion tablets
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index fc712dd..7129311 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_HID_EMS_FF)+= hid-emsff.o
obj-$(CONFIG_HID_ELECOM) += hid-elecom.o
obj-$(CONFIG_HID_ELO)+= hid-elo.o
obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
+obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-mouse.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index da52279..ec88fdb 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1827,6 +1827,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_2) },
diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
new file mode 100644
index 000..6dffb76
--- /dev/null
+++ b/drivers/hid/hid-gt683r.c
@@ -0,0 +1,294 @@
+/*
+ * MSI GT683R led driver
+ *
+ * Copyright (c) 2014 Janne Kanniainen janne.kanniai...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either
Re: [PATCH 18/36] ARM: OMAP2+: gpmc-onenand: Move Synchronous setting code to drivers/
* Roger Quadros rog...@ti.com [140611 01:59]: Move the code that puts the onenand in synchronous mode into the appropriate place i.e. drivers/mtd/onenand/omap2.c. Make use of omap_gpmc_get_clk_period() and omap_gpmc_retime() to calculate the necessary timings and configure the GPMC parent's timings. Ideally we would just use the drivers/mtd/onenand/generic.c and get rid of drivers/mtd/onenand/omap2.c. We still need the bus glue, which should probably be in drivers/memory? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 05/36] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
* Roger Quadros rog...@ti.com [140613 00:40]: On 06/13/2014 10:18 AM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140611 01:58]: Since the Interrupt Events are used only by the NAND driver, there is no point in managing the Interrupt registers in the GPMC driver and complicating it with irqchip modeling. Let's manage the interrupt registers directly in the NAND driver and get rid of irqchip model from GPMC driver. Get rid of IRQ commands and unused commands from gpmc_configure() in the GPMC driver. This seems like a step backward to me. The GPMC interrupt enable register can do edge detection on the wait pins, how is that limited to NAND? OK. But wait pin edge detection was not yet being used and I couldn't think of how it would ever be used. Any ideas? Maybe to wake-up the system on bus activity or something? Further, let's not start mixing GPMC hardware module register access with the NAND driver register access. They can be clocked separately. And bugs in the NAND driver can cause issues in other GPMC using drivers. I understood that NAND controller is integrated into the GPMC module and they are clocked the same. Not sure why the hardware designers would keep the registers so closely knit. Yeah. Maybe regmap could provide some abstraction to the the NAND registers. FYI. memory/ti-amif.c and mtd/nand/davinci_nand.c share the AMIF register space in the same way. I thought it'd be nice to be consistent across TI drivers. Probably they did not yet learn the problems caused by it :) Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] staging: dgap: introduce dgap_tty_unregister()
On Fri, Jun 13, 2014 at 04:41:47PM +0900, Daeseok Youn wrote: dgap_tty_unregister() will unregister serial_driver and print_driver, and also free related variables. Introducing a static function without a caller will cause a GCC warning about unused functions. Fold 5,7 and 8 together into one patch. This is still one thing per patch because they can't be done separately. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 07/13] kexec: Implementation of new syscall kexec_file_load
On 06/13/14 at 09:50am, Borislav Petkov wrote: On Mon, Jun 09, 2014 at 11:41:37AM -0400, Vivek Goyal wrote: IIUC, COMMAND_LINE_SIZE gives max limits of running kernel and it does not tell us anything about command line size supported by kernel being loaded. Whatever you do, you do need a sane default because even querying the boot protocol is not reliable as the to-be-loaded kernel's boot protocol might be manipulated too, before signing (who knows what people do in the wild). Make sense. So having a sane, unconditional fallback COMMAND_LINE_SIZE from the first kernel is a must, methinks. By greping for COMMAND_LINE_SIZE for different arch, I think 8K being the fallback, in general, is good for now and the future: alpha/include/uapi/asm/setup.h 4:#define COMMAND_LINE_SIZE 256 arm/include/uapi/asm/setup.h 19:#define COMMAND_LINE_SIZE 1024 avr32/include/uapi/asm/setup.h 14:#define COMMAND_LINE_SIZE 256 cris/include/uapi/asm/setup.h 4:#define COMMAND_LINE_SIZE 256 frv/include/uapi/asm/setup.h 15:#define COMMAND_LINE_SIZE 512 ia64/include/uapi/asm/setup.h 4:#define COMMAND_LINE_SIZE 2048 m32r/include/uapi/asm/setup.h 8:#define COMMAND_LINE_SIZE 512 m68k/include/uapi/asm/setup.h 14:#define COMMAND_LINE_SIZE 256 mips/include/uapi/asm/setup.h 4:#define COMMAND_LINE_SIZE 4096 parisc/include/uapi/asm/setup.h 4:#define COMMAND_LINE_SIZE 1024 powerpc/include/uapi/asm/setup.h 4:#define COMMAND_LINE_SIZE 2048 s390/include/uapi/asm/setup.h 9:#define COMMAND_LINE_SIZE 4096 um/include/asm/setup.h 8:#define COMMAND_LINE_SIZE 4096 x86/include/asm/setup.h 6:#define COMMAND_LINE_SIZE 2048 xtensa/include/uapi/asm/setup.h 14:#define COMMAND_LINE_SIZE256 c6x/include/uapi/asm/setup.h 4:#define COMMAND_LINE_SIZE 1024 microblaze/include/uapi/asm/setup.h 14:#define COMMAND_LINE_SIZE256 mn10300/include/uapi/asm/param.h 16:#define COMMAND_LINE_SIZE 256 score/include/uapi/asm/setup.h 4:#define COMMAND_LINE_SIZE 256 tile/include/uapi/asm/setup.h 18:#define COMMAND_LINE_SIZE2048 arc/include/asm/setup.h 15:#define COMMAND_LINE_SIZE 256 arm64/include/uapi/asm/setup.h 24:#define COMMAND_LINE_SIZE2048 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 RESEND] clk: flatten clk tree in debugfs
On Fri, May 30, 2014 at 05:03:57PM +0200, Peter De Schrijver wrote: This patch flattens the clk tree in CCF debugfs. Instead of representing the clocks and their hierarchy as a directory structure under /sys/kernel/debug/clk, each clock gets a single directory directly under /sys/kernel/debug/clk. The orphans directory is replaced by a file called clk_orphan_summary. Mike, Any problems with this? What needs to be done to make this patch go forward? Thanks! Peter. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 14/36] ARM: OMAP2+: gpmc: Allow drivers to reconfigure GPMC settings timings
* Roger Quadros rog...@ti.com [140613 00:46]: On 06/13/2014 10:25 AM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140611 01:58]: Some devices (e.g. TUSB6010, omap-onenand) need to reconfigure the GPMC timings in order to operate with different peripheral clock frequencies. Introduce omap_gpmc_retime() to allow them to do that. The driver needs to pass the chips select number, GPMC settings and Device timings to omap_gpmc_retime(). NOTE: Device tree and board code must still pass the most conservative timings to GPMC so that the device can be probed by the respective driver. e.g. Onenand must operate in asynchronous mode at bootup. The device driver can then request for more optimal timings via omap_gpmc_retime(). Hmm but many of the devices are Linux generic like sms91x and 8250 so it's not nice to start stuffing omap bus specific data there. Those drivers should never need to use this function. Hopefully they will work with a one time setup where we specify the timings in the DT. This function is primarily for use by omap-onenand and tusb6010, which are both OMAP specific. Well those were the only ones so far that had to tolerate with L3 speed changes at some point, so others may need it potentially too. And we could get rid of the omap specific onenand driver at some point.. But yeah, I'm fine keeping those recalc functions in the device drivers if it makes things simpler. Just something to consider in any case. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] sched: Fix compiler warnings
Hi Guenter,
There are also such kind of function in ARM and powerpc architecture
with the additional changes below, you can add my
Acked-by Vincent Guittot vincent.guit...@linaro.org
Vincent
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 1576d05..7e56b2f 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -275,7 +275,7 @@ void store_cpu_topology(unsigned int cpuid)
cpu_topology[cpuid].socket_id, mpidr);
}
-static inline const int cpu_corepower_flags(void)
+static inline int cpu_corepower_flags(void)
{
return SD_SHARE_PKG_RESOURCES | SD_SHARE_POWERDOMAIN;
}
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 10e..49d5d4e 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -768,7 +768,7 @@ int setup_profiling_timer(unsigned int multiplier)
#ifdef CONFIG_SCHED_SMT
/* cpumask of CPUs with asymetric SMT dependancy */
-static const int powerpc_smt_flags(void)
+static int powerpc_smt_flags(void)
{
int flags = SD_SHARE_CPUPOWER | SD_SHARE_PKG_RESOURCES;
On 13 June 2014 01:08, Guenter Roeck li...@roeck-us.net wrote:
Commit 143e1e28cb (sched: Rework sched_domain topology definition)
introduced a number of functions with a return value of 'const int'.
gcc doesn't know what to do with that and, if the kernel is compiled
with W=1, complains with the following warnings whenever sched.h
is included.
include/linux/sched.h:875:25: warning:
type qualifiers ignored on function return type
include/linux/sched.h:882:25: warning:
type qualifiers ignored on function return type
include/linux/sched.h:889:25: warning:
type qualifiers ignored on function return type
include/linux/sched.h:1002:21: warning:
type qualifiers ignored on function return type
Drop 'const' from the function declarations to fix the problem.
Cc: Vincent Guittot vincent.guit...@linaro.org
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
include/linux/sched.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index ea74596..65046b3 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -872,21 +872,21 @@ enum cpu_idle_type {
#define SD_NUMA0x4000 /* cross-node balancing */
#ifdef CONFIG_SCHED_SMT
-static inline const int cpu_smt_flags(void)
+static inline int cpu_smt_flags(void)
{
return SD_SHARE_CPUPOWER | SD_SHARE_PKG_RESOURCES;
}
#endif
#ifdef CONFIG_SCHED_MC
-static inline const int cpu_core_flags(void)
+static inline int cpu_core_flags(void)
{
return SD_SHARE_PKG_RESOURCES;
}
#endif
#ifdef CONFIG_NUMA
-static inline const int cpu_numa_flags(void)
+static inline int cpu_numa_flags(void)
{
return SD_NUMA;
}
@@ -999,7 +999,7 @@ void free_sched_domains(cpumask_var_t doms[], unsigned
int ndoms);
bool cpus_share_cache(int this_cpu, int that_cpu);
typedef const struct cpumask *(*sched_domain_mask_f)(int cpu);
-typedef const int (*sched_domain_flags_f)(void);
+typedef int (*sched_domain_flags_f)(void);
#define SDTL_OVERLAP 0x01
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/7] mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources
Doug, On Wed, 2014-06-11 at 08:11 -0700, Doug Anderson wrote: On Wed, Jun 11, 2014 at 3:37 AM, Paul Bolle pebo...@tiscali.nl wrote: On Tue, 2014-05-20 at 09:46 +0100, Lee Jones wrote: On Wed, 30 Apr 2014, Doug Anderson wrote: From: Bill Richardson wfric...@chromium.org This just updates include/linux/mfd/cros_ec_commands.h to match the latest EC version (which is the One True Source for such things). See https://chromium.googlesource.com/chromiumos/platform/ec I believe most of your questions are answered by checking out the git tree referenced above. ...but see below for details. This header is a common interface between the kernel and the EC. I didn't realize that this was a link to a tree. CONFIG_CHARGER_PROFILE_OVERRIDE doesn't match anything in linux-next. Is a Kconfig symbol CHARGER_PROFILE_OVERRIDE perhaps queued somewhere? This is a config option on the ChromeOS EC https://chromium.googlesource.com/chromiumos/platform/ec. Doing a grep there: board/samus/board.h:#define CONFIG_CHARGER_PROFILE_OVERRIDE common/charge_state_v2.c:#ifdef CONFIG_CHARGER_PROFILE_OVERRIDE common/charge_state_v2.c:#ifdef CONFIG_CHARGER_PROFILE_OVERRIDE common/charge_state_v2.c:#ifdef CONFIG_CHARGER_PROFILE_OVERRIDE driver/battery/samus.c:#ifdef CONFIG_CHARGER_PROFILE_OVERRIDE driver/battery/samus.c:#endif /* CONFIG_CHARGER_PROFILE_OVERRIDE */ include/config.h:#undef CONFIG_CHARGER_PROFILE_OVERRIDE include/ec_commands.h: /* Range for CONFIG_CHARGER_PROFILE_OVERRIDE params */ test/test_config.h:#define CONFIG_CHARGER_PROFILE_OVERRIDE I see. So this is not a Kconfig macro but a general macro with a CONFIG_ prefix. There are quite a bit of those in the tree already, but still, would another prefix also do? Thanks, Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 07/13] kexec: Implementation of new syscall kexec_file_load
On Fri, Jun 13, 2014 at 04:00:28PM +0800, WANG Chao wrote: By greping for COMMAND_LINE_SIZE for different arch, I think 8K being the fallback, in general, is good for now and the future: Why - we could simply use the arch default one. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 05/36] mtd: nand: omap: Move IRQ handling from GPMC to NAND driver
From: Tony Lindgren [mailto:t...@atomide.com] * Roger Quadros rog...@ti.com [140613 00:40]: On 06/13/2014 10:18 AM, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [140611 01:58]: Since the Interrupt Events are used only by the NAND driver, there is no point in managing the Interrupt registers in the GPMC driver and complicating it with irqchip modeling. Let's manage the interrupt registers directly in the NAND driver and get rid of irqchip model from GPMC driver. Get rid of IRQ commands and unused commands from gpmc_configure() in the GPMC driver. This seems like a step backward to me. The GPMC interrupt enable register can do edge detection on the wait pins, how is that limited to NAND? OK. But wait pin edge detection was not yet being used and I couldn't think of how it would ever be used. Any ideas? Maybe to wake-up the system on bus activity or something? Sorry, I wasn't able to review this series. But just as pointer, GPMC driver was used for interfacing many non-memory devices like Ethernet (smc91x) and in past GPMC has been proved to work with camera devices too, but that's wasn't mainlined. So keeping IRQ and few other things in GPMC driver is helpful. Further, let's not start mixing GPMC hardware module register access with the NAND driver register access. They can be clocked separately. And bugs in the NAND driver can cause issues in other GPMC using drivers. I understood that NAND controller is integrated into the GPMC module and they are clocked the same. Not sure why the hardware designers would keep the registers so closely knit. Yeah. Maybe regmap could provide some abstraction to the the NAND registers. As you mentioned, GPMC has two set of registers: (a) Chip-select registers (CONFIGx_cs) for device specific parameters (like device-width, signal-timings, etc) which are statically programmed during probe or via DT. (b) ECC registers which are continuously reconfigured based on ECC engine. *Ideal Scenario* NAND driver should be considered equivalent to protocol driver, Therefore ideally it should use only those registers which are specific to NAND (b). *Actual Scenario* But most NAND device today are ONFI compliant and they have almost all device parameters like device-width, signal-timings burned on-die in an ONFI page. These values are read back from NAND device during device_probe() and then re-configured back Chip-select registers (a). Hence NAND driver needs access of both (a) and (b), which is why You need to export complete GPMC register set to NAND driver. However this is not the case and has been discussed earlier too.. http://lists.infradead.org/pipermail/linux-mtd/2013-October/049284.html http://lists.infradead.org/pipermail/linux-mtd/2013-October/049347.html (Just pointing out my version of history, would be good to read the entire discussion. But the summary was that we need to re-configure some GPMC chip-select registers (a) based on probe done in NAND driver. So we need all GPMC registers exposed to NAND driver). FYI. memory/ti-amif.c and mtd/nand/davinci_nand.c share the AMIF register space in the same way. I thought it'd be nice to be consistent across TI drivers. Probably they did not yet learn the problems caused by it :) I havn't reviewed the ti-amif.c driver completely but I think they too configure device signal timing statically based on DT. But as per today this is frowned upon because: (1) Its difficult for layman user to decipher NAND signal timings from datasheet and then convert it into controller understandable DT (2) ONFI parameter page on NAND has these timings specified on-die itself, and these timings are characterized for best performance so NAND driver should re-configure these timings after probe. Refer below mail from 'Rob Herring robherri...@gmail.com' http://lists.infradead.org/pipermail/linux-mtd/2014-April/053488.html Considering all these details, please re-review the changes you plan for GPMC driver. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] staging: dgap: introduce dgap_tty_unregister()
Hi, Dan 2014-06-13 17:00 GMT+09:00 Dan Carpenter dan.carpen...@oracle.com: On Fri, Jun 13, 2014 at 04:41:47PM +0900, Daeseok Youn wrote: dgap_tty_unregister() will unregister serial_driver and print_driver, and also free related variables. Introducing a static function without a caller will cause a GCC warning about unused functions. Fold 5,7 and 8 together into one patch. This is still one thing per patch because they can't be done separately. OK. I will do. And then this series of patches will resend, right? Thanks. regards, Daeseok Youn regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
News for €EUROMILLIONS
-- Good day.. Is this account still in use? -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-next] Regression: ssh log in slowdown
I assume this is the series [PATCH 0/4] Checksum fixes (marc.info/?l=linux-netdevm=140261417832399w=2)? Yes. As I'm not subscribed to netdev, I cannot reply to that thread. [PATCH 1/4] net: Fix save software checksum complete fixes the issue for me. However, [PATCH 2/4] udp: call __skb_checksum_complete when doing full checksum reintroduces the exact same bad behavior :-( This implies the problem is happening in UDP path. AFAICT skb-csum is correct, and I don't seem to be able to reproduce the issue on my setup. It is possible that an skb copy is happening in which case we don't copy csum_valid so that checksum_unnecessary would fail in this case. Can you try with the patch below. Thanks! diff --git a/net/core/skbuff.c b/net/core/skbuff.c index bf92824..9cd5344 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -689,6 +689,9 @@ static void __copy_skb_header(struct sk_buff *new, const struct sk_buff *old) new-ooo_okay = old-ooo_okay; new-no_fcs = old-no_fcs; new-encapsulation = old-encapsulation; + new-encap_hdr_csum = old-encap_hdr_csum; + new-csum_valid = old-csum_valid; + new-csum_complete_sw = old-csum_complete_sw; #ifdef CONFIG_XFRM new-sp = secpath_get(old-sp); #endif -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
