Re: [PATCH -mm] vmscan: move reclaim_state handling to shrink_slab
On Wed, Jan 14, 2015 at 03:34:49PM -0800, Andrew Morton wrote: > On Wed, 14 Jan 2015 16:55:36 +0300 Vladimir Davydov > wrote: > > This patch also makes shrink_slab() return the number of reclaimed slab > > pages (obtained from reclaim_state) instead of the number of reclaimed > > objects, because the latter is not of much use - it was only checked by > > drop_slab() to decide whether it should continue reclaim or abort. The > > number of reclaimed pages is more appropriate, because it also can be > > used by shrink_zone() to accumulate scan_control->nr_reclaimed. > > Not sure that this is a good change. If shrink_slab() managed to free > some objects but didn't free any pages then that's a good sign that > additional calls to shrink_slab() *will* free some pages. With this > change, drop_slab_node() can give up too early. Fair enough. We'd better leave the return value intact then. I think we should add an additional argument to add the number of reclaimed slab pages to, as I intended to do initially. Will resend. Thanks, Vladimir -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sound/oss: use current->state helpers
On Thu, 2015-01-15 at 08:33 +0100, Takashi Iwai wrote: > At Wed, 14 Jan 2015 23:11:43 -0800, > Davidlohr Bueso wrote: > > > > From: Davidlohr Bueso > > > > Call __set_current_state() instead of assigning the new state directly. > > These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping > > track of who changed the state. > > > > Signed-off-by: Davidlohr Bueso > > The author and sign-off have different addresses. Could you align? I don't see a problem with that. All my patches are the same. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: PROBLEM: [3.4] neigh_destroy() crashes on unplug netdev.
Dear Eric: 3.6 or later kernels (including recent mainline) do not have this problem. 3.4.105 is based on an old kernel, but it is a latest kernel of 3.4 LTS branch. I think it is better to backport 20 patches to LTS branch. But if you do not have such support policy, I will apply these patches to my 3.4 kernel only. Thanks -Original Message- From: Eric Dumazet [mailto:eric.duma...@gmail.com] Sent: Thursday, January 15, 2015 4:03 PM To: Nakashima Akihiro Cc: da...@davemloft.net; net...@vger.kernel.org; Ueda Motoki; Otsu Takahiro; Tomono Mitsunori; linux-kernel@vger.kernel.org Subject: Re: PROBLEM: [3.4] neigh_destroy() crashes on unplug netdev. On Thu, 2015-01-15 at 05:57 +, Nakashima Akihiro wrote: > Dear David and networking developers: > > I got kernel panic on 3.4.105 kernel. > Please see a report below. Please try a recent kernel. We are not going to debug such an old one, given there are chances we already fixed the problem ages ago. Thanks
ia64: use current->state helpers
Call __set_current_state() instead of assigning the new state directly.
These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping
track of who changed the state.
Signed-off-by: Davidlohr Bueso
---
Completely untested.
arch/ia64/kernel/mca.c| 2 +-
arch/ia64/kernel/ptrace.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
index 8bfd36a..9797d01 100644
--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -1821,7 +1821,7 @@ format_mca_init_stack(void *mca_data, unsigned long
offset,
ti->task = p;
ti->cpu = cpu;
p->stack = ti;
- p->state = TASK_UNINTERRUPTIBLE;
+ __set_task_state(p, TASK_UNINTERRUPTIBLE);
cpu_set(cpu, p->cpus_allowed);
INIT_LIST_HEAD(>tasks);
p->parent = p->real_parent = p->group_leader = p;
diff --git a/arch/ia64/kernel/ptrace.c b/arch/ia64/kernel/ptrace.c
index 6f54d51..67bb42c 100644
--- a/arch/ia64/kernel/ptrace.c
+++ b/arch/ia64/kernel/ptrace.c
@@ -643,7 +643,7 @@ ptrace_attach_sync_user_rbs (struct task_struct *child)
!test_and_set_tsk_thread_flag(child, TIF_RESTORE_RSE)) {
set_notify_resume(child);
- child->state = TASK_TRACED;
+ __set_task_state(child, TASK_TRACED);
stopped = 1;
}
spin_unlock_irq(>sighand->siglock);
@@ -665,7 +665,7 @@ ptrace_attach_sync_user_rbs (struct task_struct *child)
spin_lock_irq(>sighand->siglock);
if (child->state == TASK_TRACED &&
(child->signal->flags & SIGNAL_STOP_STOPPED)) {
- child->state = TASK_STOPPED;
+ __set_task_state(child, TASK_STOPPED);
}
spin_unlock_irq(>sighand->siglock);
}
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: zynq: Setup default gpio number for Xilinx Zynq
Signed-off-by: Michal Simek --- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 97d07ed60a0b..da77f786f99f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1488,7 +1488,7 @@ config ARM_PSCI # selected platforms. config ARCH_NR_GPIO int - default 1024 if ARCH_SHMOBILE || ARCH_TEGRA + default 1024 if ARCH_SHMOBILE || ARCH_TEGRA || ARCH_ZYNQ default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || \ SOC_DRA7XX || ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210 default 416 if ARCH_SUNXI -- 1.8.2.3 pgpb1hpXgmJeh.pgp Description: PGP signature
[PATCH v3 5/5] mm/compaction: add tracepoint to observe behaviour of compaction defer
compaction deferring logic is heavy hammer that block the way to
the compaction. It doesn't consider overall system state, so it
could prevent user from doing compaction falsely. In other words,
even if system has enough range of memory to compact, compaction would be
skipped due to compaction deferring logic. This patch add new tracepoint
to understand work of deferring logic. This will also help to check
compaction success and fail.
Changes from v2: Remove reason part from tracepoint output
Signed-off-by: Joonsoo Kim
---
include/linux/compaction.h| 65 +++--
include/trace/events/compaction.h | 54
mm/compaction.c | 72 +
3 files changed, 131 insertions(+), 60 deletions(-)
diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index d82181a..026ff64 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -44,66 +44,11 @@ extern void reset_isolation_suitable(pg_data_t *pgdat);
extern unsigned long compaction_suitable(struct zone *zone, int order,
int alloc_flags, int classzone_idx);
-/* Do not skip compaction more than 64 times */
-#define COMPACT_MAX_DEFER_SHIFT 6
-
-/*
- * Compaction is deferred when compaction fails to result in a page
- * allocation success. 1 << compact_defer_limit compactions are skipped up
- * to a limit of 1 << COMPACT_MAX_DEFER_SHIFT
- */
-static inline void defer_compaction(struct zone *zone, int order)
-{
- zone->compact_considered = 0;
- zone->compact_defer_shift++;
-
- if (order < zone->compact_order_failed)
- zone->compact_order_failed = order;
-
- if (zone->compact_defer_shift > COMPACT_MAX_DEFER_SHIFT)
- zone->compact_defer_shift = COMPACT_MAX_DEFER_SHIFT;
-}
-
-/* Returns true if compaction should be skipped this time */
-static inline bool compaction_deferred(struct zone *zone, int order)
-{
- unsigned long defer_limit = 1UL << zone->compact_defer_shift;
-
- if (order < zone->compact_order_failed)
- return false;
-
- /* Avoid possible overflow */
- if (++zone->compact_considered > defer_limit)
- zone->compact_considered = defer_limit;
-
- return zone->compact_considered < defer_limit;
-}
-
-/*
- * Update defer tracking counters after successful compaction of given order,
- * which means an allocation either succeeded (alloc_success == true) or is
- * expected to succeed.
- */
-static inline void compaction_defer_reset(struct zone *zone, int order,
- bool alloc_success)
-{
- if (alloc_success) {
- zone->compact_considered = 0;
- zone->compact_defer_shift = 0;
- }
- if (order >= zone->compact_order_failed)
- zone->compact_order_failed = order + 1;
-}
-
-/* Returns true if restarting compaction after many failures */
-static inline bool compaction_restarting(struct zone *zone, int order)
-{
- if (order < zone->compact_order_failed)
- return false;
-
- return zone->compact_defer_shift == COMPACT_MAX_DEFER_SHIFT &&
- zone->compact_considered >= 1UL << zone->compact_defer_shift;
-}
+extern void defer_compaction(struct zone *zone, int order);
+extern bool compaction_deferred(struct zone *zone, int order);
+extern void compaction_defer_reset(struct zone *zone, int order,
+ bool alloc_success);
+extern bool compaction_restarting(struct zone *zone, int order);
#else
static inline unsigned long try_to_compact_pages(struct zonelist *zonelist,
diff --git a/include/trace/events/compaction.h
b/include/trace/events/compaction.h
index d465358..a770166 100644
--- a/include/trace/events/compaction.h
+++ b/include/trace/events/compaction.h
@@ -238,6 +238,60 @@ DEFINE_EVENT(mm_compaction_suitable_template,
mm_compaction_suitable,
TP_ARGS(zone, order, ret)
);
+DECLARE_EVENT_CLASS(mm_compaction_defer_template,
+
+ TP_PROTO(struct zone *zone, int order),
+
+ TP_ARGS(zone, order),
+
+ TP_STRUCT__entry(
+ __field(int, nid)
+ __field(char *, name)
+ __field(int, order)
+ __field(unsigned int, considered)
+ __field(unsigned int, defer_shift)
+ __field(int, order_failed)
+ ),
+
+ TP_fast_assign(
+ __entry->nid = zone_to_nid(zone);
+ __entry->name = (char *)zone->name;
+ __entry->order = order;
+ __entry->considered = zone->compact_considered;
+ __entry->defer_shift = zone->compact_defer_shift;
+ __entry->order_failed = zone->compact_order_failed;
+ ),
+
+ TP_printk("node=%d zone=%-8s order=%d order_failed=%d consider=%u
limit=%lu",
+ __entry->nid,
+ __entry->name,
+ __entry->order,
[PATCH v3 3/5] mm/compaction: print current range where compaction work
It'd be useful to know current range where compaction work for detailed
analysis. With it, we can know pageblock where we actually scan and
isolate, and, how much pages we try in that pageblock and can guess why
it doesn't become freepage with pageblock order roughly.
Acked-by: Vlastimil Babka
Signed-off-by: Joonsoo Kim
---
include/trace/events/compaction.h | 30 +++---
mm/compaction.c |9 ++---
2 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/include/trace/events/compaction.h
b/include/trace/events/compaction.h
index 839f6fa..139020b 100644
--- a/include/trace/events/compaction.h
+++ b/include/trace/events/compaction.h
@@ -11,39 +11,55 @@
DECLARE_EVENT_CLASS(mm_compaction_isolate_template,
- TP_PROTO(unsigned long nr_scanned,
+ TP_PROTO(
+ unsigned long start_pfn,
+ unsigned long end_pfn,
+ unsigned long nr_scanned,
unsigned long nr_taken),
- TP_ARGS(nr_scanned, nr_taken),
+ TP_ARGS(start_pfn, end_pfn, nr_scanned, nr_taken),
TP_STRUCT__entry(
+ __field(unsigned long, start_pfn)
+ __field(unsigned long, end_pfn)
__field(unsigned long, nr_scanned)
__field(unsigned long, nr_taken)
),
TP_fast_assign(
+ __entry->start_pfn = start_pfn;
+ __entry->end_pfn = end_pfn;
__entry->nr_scanned = nr_scanned;
__entry->nr_taken = nr_taken;
),
- TP_printk("nr_scanned=%lu nr_taken=%lu",
+ TP_printk("range=(0x%lx ~ 0x%lx) nr_scanned=%lu nr_taken=%lu",
+ __entry->start_pfn,
+ __entry->end_pfn,
__entry->nr_scanned,
__entry->nr_taken)
);
DEFINE_EVENT(mm_compaction_isolate_template,
mm_compaction_isolate_migratepages,
- TP_PROTO(unsigned long nr_scanned,
+ TP_PROTO(
+ unsigned long start_pfn,
+ unsigned long end_pfn,
+ unsigned long nr_scanned,
unsigned long nr_taken),
- TP_ARGS(nr_scanned, nr_taken)
+ TP_ARGS(start_pfn, end_pfn, nr_scanned, nr_taken)
);
DEFINE_EVENT(mm_compaction_isolate_template, mm_compaction_isolate_freepages,
- TP_PROTO(unsigned long nr_scanned,
+
+ TP_PROTO(
+ unsigned long start_pfn,
+ unsigned long end_pfn,
+ unsigned long nr_scanned,
unsigned long nr_taken),
- TP_ARGS(nr_scanned, nr_taken)
+ TP_ARGS(start_pfn, end_pfn, nr_scanned, nr_taken)
);
TRACE_EVENT(mm_compaction_migratepages,
diff --git a/mm/compaction.c b/mm/compaction.c
index 2d86a20..be28469 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -429,11 +429,12 @@ isolate_fail:
}
+ trace_mm_compaction_isolate_freepages(*start_pfn, blockpfn,
+ nr_scanned, total_isolated);
+
/* Record how far we have got within the block */
*start_pfn = blockpfn;
- trace_mm_compaction_isolate_freepages(nr_scanned, total_isolated);
-
/*
* If strict isolation is requested by CMA then check that all the
* pages requested were isolated. If there were any failures, 0 is
@@ -589,6 +590,7 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
unsigned long flags = 0;
bool locked = false;
struct page *page = NULL, *valid_page = NULL;
+ unsigned long start_pfn = low_pfn;
/*
* Ensure that there are not too many pages isolated from the LRU
@@ -749,7 +751,8 @@ isolate_success:
if (low_pfn == end_pfn)
update_pageblock_skip(cc, valid_page, nr_isolated, true);
- trace_mm_compaction_isolate_migratepages(nr_scanned, nr_isolated);
+ trace_mm_compaction_isolate_migratepages(start_pfn, low_pfn,
+ nr_scanned, nr_isolated);
count_compact_events(COMPACTMIGRATE_SCANNED, nr_scanned);
if (nr_isolated)
--
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 v3 4/5] mm/compaction: more trace to understand when/why compaction start/finish
It is not well analyzed that when/why compaction start/finish or not. With
these new tracepoints, we can know much more about start/finish reason of
compaction. I can find following bug with these tracepoint.
http://www.spinics.net/lists/linux-mm/msg81582.html
Change from v2: omit alloc_flag, classzone_idx from tracepoint output
Signed-off-by: Joonsoo Kim
---
include/linux/compaction.h|3 ++
include/trace/events/compaction.h | 74 +
mm/compaction.c | 38 +--
3 files changed, 111 insertions(+), 4 deletions(-)
diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index a9547b6..d82181a 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -12,6 +12,9 @@
#define COMPACT_PARTIAL3
/* The full zone was compacted */
#define COMPACT_COMPLETE 4
+/* For more detailed tracepoint output */
+#define COMPACT_NO_SUITABLE_PAGE 5
+#define COMPACT_NOT_SUITABLE_ZONE 6
/* When adding new state, please change compaction_status_string, too */
/* Used to signal whether compaction detected need_sched() or lock contention
*/
diff --git a/include/trace/events/compaction.h
b/include/trace/events/compaction.h
index 139020b..d465358 100644
--- a/include/trace/events/compaction.h
+++ b/include/trace/events/compaction.h
@@ -164,6 +164,80 @@ TRACE_EVENT(mm_compaction_end,
compaction_status_string[__entry->status])
);
+TRACE_EVENT(mm_compaction_try_to_compact_pages,
+
+ TP_PROTO(
+ int order,
+ gfp_t gfp_mask,
+ enum migrate_mode mode),
+
+ TP_ARGS(order, gfp_mask, mode),
+
+ TP_STRUCT__entry(
+ __field(int, order)
+ __field(gfp_t, gfp_mask)
+ __field(enum migrate_mode, mode)
+ ),
+
+ TP_fast_assign(
+ __entry->order = order;
+ __entry->gfp_mask = gfp_mask;
+ __entry->mode = mode;
+ ),
+
+ TP_printk("order=%d gfp_mask=0x%x mode=%d",
+ __entry->order,
+ __entry->gfp_mask,
+ (int)__entry->mode)
+);
+
+DECLARE_EVENT_CLASS(mm_compaction_suitable_template,
+
+ TP_PROTO(struct zone *zone,
+ int order,
+ int ret),
+
+ TP_ARGS(zone, order, ret),
+
+ TP_STRUCT__entry(
+ __field(int, nid)
+ __field(char *, name)
+ __field(int, order)
+ __field(int, ret)
+ ),
+
+ TP_fast_assign(
+ __entry->nid = zone_to_nid(zone);
+ __entry->name = (char *)zone->name;
+ __entry->order = order;
+ __entry->ret = ret;
+ ),
+
+ TP_printk("node=%d zone=%-8s order=%d ret=%s",
+ __entry->nid,
+ __entry->name,
+ __entry->order,
+ compaction_status_string[__entry->ret])
+);
+
+DEFINE_EVENT(mm_compaction_suitable_template, mm_compaction_finished,
+
+ TP_PROTO(struct zone *zone,
+ int order,
+ int ret),
+
+ TP_ARGS(zone, order, ret)
+);
+
+DEFINE_EVENT(mm_compaction_suitable_template, mm_compaction_suitable,
+
+ TP_PROTO(struct zone *zone,
+ int order,
+ int ret),
+
+ TP_ARGS(zone, order, ret)
+);
+
#endif /* _TRACE_COMPACTION_H */
/* This part must be outside protection */
diff --git a/mm/compaction.c b/mm/compaction.c
index be28469..97702a8 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -25,6 +25,8 @@ char *compaction_status_string[] = {
"continue",
"partial",
"complete",
+ "no_suitable_page",
+ "not_suitable_zone",
};
static inline void count_compact_event(enum vm_event_item item)
@@ -1048,7 +1050,7 @@ static isolate_migrate_t isolate_migratepages(struct zone
*zone,
return cc->nr_migratepages ? ISOLATE_SUCCESS : ISOLATE_NONE;
}
-static int compact_finished(struct zone *zone, struct compact_control *cc,
+static int __compact_finished(struct zone *zone, struct compact_control *cc,
const int migratetype)
{
unsigned int order;
@@ -1103,7 +1105,20 @@ static int compact_finished(struct zone *zone, struct
compact_control *cc,
return COMPACT_PARTIAL;
}
- return COMPACT_CONTINUE;
+ return COMPACT_NO_SUITABLE_PAGE;
+}
+
+static int compact_finished(struct zone *zone, struct compact_control *cc,
+ const int migratetype)
+{
+ int ret;
+
+ ret = __compact_finished(zone, cc, migratetype);
+ trace_mm_compaction_finished(zone, cc->order, ret);
+ if (ret == COMPACT_NO_SUITABLE_PAGE)
+ ret = COMPACT_CONTINUE;
+
+ return ret;
}
/*
@@ -1113,7 +1128,7 @@ static int compact_finished(struct zone *zone, struct
compact_control *cc,
* COMPACT_PARTIAL - If the allocation
[PATCH v3 2/5] mm/compaction: enhance tracepoint output for compaction begin/end
We now have tracepoint for begin event of compaction and it prints
start position of both scanners, but, tracepoint for end event of
compaction doesn't print finish position of both scanners. It'd be
also useful to know finish position of both scanners so this patch
add it. It will help to find odd behavior or problem on compaction
internal logic.
And, mode is added to both begin/end tracepoint output, since
according to mode, compaction behavior is quite different.
And, lastly, status format is changed to string rather than
status number for readability.
Acked-by: Vlastimil Babka
Signed-off-by: Joonsoo Kim
---
include/linux/compaction.h|2 ++
include/trace/events/compaction.h | 49 ++---
mm/compaction.c | 14 +--
3 files changed, 49 insertions(+), 16 deletions(-)
diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index 3238ffa..a9547b6 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -12,6 +12,7 @@
#define COMPACT_PARTIAL3
/* The full zone was compacted */
#define COMPACT_COMPLETE 4
+/* When adding new state, please change compaction_status_string, too */
/* Used to signal whether compaction detected need_sched() or lock contention
*/
/* No contention detected */
@@ -22,6 +23,7 @@
#define COMPACT_CONTENDED_LOCK 2
#ifdef CONFIG_COMPACTION
+extern char *compaction_status_string[];
extern int sysctl_compact_memory;
extern int sysctl_compaction_handler(struct ctl_table *table, int write,
void __user *buffer, size_t *length, loff_t *ppos);
diff --git a/include/trace/events/compaction.h
b/include/trace/events/compaction.h
index 1337d9e..839f6fa 100644
--- a/include/trace/events/compaction.h
+++ b/include/trace/events/compaction.h
@@ -85,46 +85,67 @@ TRACE_EVENT(mm_compaction_migratepages,
);
TRACE_EVENT(mm_compaction_begin,
- TP_PROTO(unsigned long zone_start, unsigned long migrate_start,
- unsigned long free_start, unsigned long zone_end),
+ TP_PROTO(unsigned long zone_start, unsigned long migrate_pfn,
+ unsigned long free_pfn, unsigned long zone_end, bool sync),
- TP_ARGS(zone_start, migrate_start, free_start, zone_end),
+ TP_ARGS(zone_start, migrate_pfn, free_pfn, zone_end, sync),
TP_STRUCT__entry(
__field(unsigned long, zone_start)
- __field(unsigned long, migrate_start)
- __field(unsigned long, free_start)
+ __field(unsigned long, migrate_pfn)
+ __field(unsigned long, free_pfn)
__field(unsigned long, zone_end)
+ __field(bool, sync)
),
TP_fast_assign(
__entry->zone_start = zone_start;
- __entry->migrate_start = migrate_start;
- __entry->free_start = free_start;
+ __entry->migrate_pfn = migrate_pfn;
+ __entry->free_pfn = free_pfn;
__entry->zone_end = zone_end;
+ __entry->sync = sync;
),
- TP_printk("zone_start=0x%lx migrate_start=0x%lx free_start=0x%lx
zone_end=0x%lx",
+ TP_printk("zone_start=0x%lx migrate_pfn=0x%lx free_pfn=0x%lx
zone_end=0x%lx, mode=%s",
__entry->zone_start,
- __entry->migrate_start,
- __entry->free_start,
- __entry->zone_end)
+ __entry->migrate_pfn,
+ __entry->free_pfn,
+ __entry->zone_end,
+ __entry->sync ? "sync" : "async")
);
TRACE_EVENT(mm_compaction_end,
- TP_PROTO(int status),
+ TP_PROTO(unsigned long zone_start, unsigned long migrate_pfn,
+ unsigned long free_pfn, unsigned long zone_end, bool sync,
+ int status),
- TP_ARGS(status),
+ TP_ARGS(zone_start, migrate_pfn, free_pfn, zone_end, sync, status),
TP_STRUCT__entry(
+ __field(unsigned long, zone_start)
+ __field(unsigned long, migrate_pfn)
+ __field(unsigned long, free_pfn)
+ __field(unsigned long, zone_end)
+ __field(bool, sync)
__field(int, status)
),
TP_fast_assign(
+ __entry->zone_start = zone_start;
+ __entry->migrate_pfn = migrate_pfn;
+ __entry->free_pfn = free_pfn;
+ __entry->zone_end = zone_end;
+ __entry->sync = sync;
__entry->status = status;
),
- TP_printk("status=%d", __entry->status)
+ TP_printk("zone_start=0x%lx migrate_pfn=0x%lx free_pfn=0x%lx
zone_end=0x%lx, mode=%s status=%s",
+ __entry->zone_start,
+ __entry->migrate_pfn,
+ __entry->free_pfn,
+ __entry->zone_end,
+ __entry->sync ? "sync" : "async",
+ compaction_status_string[__entry->status])
);
Re: [PATCH v2] drm/panel: Add support for AUO b101ean01 panel
Hi hl,
On Thu, Jan 15, 2015 at 2:15 PM, huang lin wrote:
> The AUO b101ean01 panel is a 10.1" 1280x800 panel,
> which can be supported by the simple panel driver.
>
> Signed-off-by: huang lin
>
> ---
>
> Changes in v2:
> - changed panel timing
>
> drivers/gpu/drm/panel/panel-simple.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index e95385b..c02f0e6 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -392,6 +392,29 @@ static const struct panel_desc auo_b116xw03 = {
> },
> };
>
> +static const struct drm_display_mode auo_b101ean01_mode = {
Perhaps you missed my last review where I suggested moving the
definitions for auo_b101ean01 under auo_b101aw03.
With that change, this patch is
Reviewed-by: Daniel Kurtz
> + .clock = 72500,
> + .hdisplay = 1280,
> + .hsync_start = 1280 + 147,
> + .hsync_end = 1280 + 147 + 32,
> + .htotal = 1280 + 147 + 32 + 21,
> + .vdisplay = 800,
> + .vsync_start = 800 + 4,
> + .vsync_end = 800 + 4 + 4,
> + .vtotal = 800 + 4 + 4 + 8,
> + .vrefresh = 60,
> +};
> +
> +static const struct panel_desc auo_b101ean01 = {
> + .modes = _b101ean01_mode,
> + .num_modes = 1,
> + .bpc = 6,
> + .size = {
> + .width = 217,
> + .height = 136,
> + },
> +};
> +
> static const struct drm_display_mode auo_b133xtn01_mode = {
> .clock = 69500,
> .hdisplay = 1366,
> @@ -727,6 +750,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "auo,b101aw03",
> .data = _b101aw03,
> }, {
> + .compatible = "auo,b101ean01",
> + .data = _b101ean01,
> + }, {
> .compatible = "auo,b101xtn01",
> .data = _b101xtn01,
> }, {
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/5] mm/compaction: change tracepoint format from decimal to hexadecimal
To check the range that compaction is working, tracepoint print
start/end pfn of zone and start pfn of both scanner with decimal format.
Since we manage all pages in order of 2 and it is well represented by
hexadecimal, this patch change the tracepoint format from decimal to
hexadecimal. This would improve readability. For example, it makes us
easily notice whether current scanner try to compact previously
attempted pageblock or not.
Acked-by: Vlastimil Babka
Signed-off-by: Joonsoo Kim
---
include/trace/events/compaction.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/trace/events/compaction.h
b/include/trace/events/compaction.h
index c6814b9..1337d9e 100644
--- a/include/trace/events/compaction.h
+++ b/include/trace/events/compaction.h
@@ -104,7 +104,7 @@ TRACE_EVENT(mm_compaction_begin,
__entry->zone_end = zone_end;
),
- TP_printk("zone_start=%lu migrate_start=%lu free_start=%lu
zone_end=%lu",
+ TP_printk("zone_start=0x%lx migrate_start=0x%lx free_start=0x%lx
zone_end=0x%lx",
__entry->zone_start,
__entry->migrate_start,
__entry->free_start,
--
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] mm/slub: optimize alloc/free fastpath by removing preemption on/off
We had to insert a preempt enable/disable in the fastpath a while ago in order to guarantee that tid and kmem_cache_cpu are retrieved on the same cpu. It is the problem only for CONFIG_PREEMPT in which scheduler can move the process to other cpu during retrieving data. Now, I reach the solution to remove preempt enable/disable in the fastpath. If tid is matched with kmem_cache_cpu's tid after tid and kmem_cache_cpu are retrieved by separate this_cpu operation, it means that they are retrieved on the same cpu. If not matched, we just have to retry it. With this guarantee, preemption enable/disable isn't need at all even if CONFIG_PREEMPT, so this patch removes it. I saw roughly 5% win in a fast-path loop over kmem_cache_alloc/free in CONFIG_PREEMPT. (14.821 ns -> 14.049 ns) Below is the result of Christoph's slab_test reported by Jesper Dangaard Brouer. * Before Single thread testing = 1. Kmalloc: Repeatedly allocate then free test 1 times kmalloc(8) -> 49 cycles kfree -> 62 cycles 1 times kmalloc(16) -> 48 cycles kfree -> 64 cycles 1 times kmalloc(32) -> 53 cycles kfree -> 70 cycles 1 times kmalloc(64) -> 64 cycles kfree -> 77 cycles 1 times kmalloc(128) -> 74 cycles kfree -> 84 cycles 1 times kmalloc(256) -> 84 cycles kfree -> 114 cycles 1 times kmalloc(512) -> 83 cycles kfree -> 116 cycles 1 times kmalloc(1024) -> 81 cycles kfree -> 120 cycles 1 times kmalloc(2048) -> 104 cycles kfree -> 136 cycles 1 times kmalloc(4096) -> 142 cycles kfree -> 165 cycles 1 times kmalloc(8192) -> 238 cycles kfree -> 226 cycles 1 times kmalloc(16384) -> 403 cycles kfree -> 264 cycles 2. Kmalloc: alloc/free test 1 times kmalloc(8)/kfree -> 68 cycles 1 times kmalloc(16)/kfree -> 68 cycles 1 times kmalloc(32)/kfree -> 69 cycles 1 times kmalloc(64)/kfree -> 68 cycles 1 times kmalloc(128)/kfree -> 68 cycles 1 times kmalloc(256)/kfree -> 68 cycles 1 times kmalloc(512)/kfree -> 74 cycles 1 times kmalloc(1024)/kfree -> 75 cycles 1 times kmalloc(2048)/kfree -> 74 cycles 1 times kmalloc(4096)/kfree -> 74 cycles 1 times kmalloc(8192)/kfree -> 75 cycles 1 times kmalloc(16384)/kfree -> 510 cycles * After Single thread testing = 1. Kmalloc: Repeatedly allocate then free test 1 times kmalloc(8) -> 46 cycles kfree -> 61 cycles 1 times kmalloc(16) -> 46 cycles kfree -> 63 cycles 1 times kmalloc(32) -> 49 cycles kfree -> 69 cycles 1 times kmalloc(64) -> 57 cycles kfree -> 76 cycles 1 times kmalloc(128) -> 66 cycles kfree -> 83 cycles 1 times kmalloc(256) -> 84 cycles kfree -> 110 cycles 1 times kmalloc(512) -> 77 cycles kfree -> 114 cycles 1 times kmalloc(1024) -> 80 cycles kfree -> 116 cycles 1 times kmalloc(2048) -> 102 cycles kfree -> 131 cycles 1 times kmalloc(4096) -> 135 cycles kfree -> 163 cycles 1 times kmalloc(8192) -> 238 cycles kfree -> 218 cycles 1 times kmalloc(16384) -> 399 cycles kfree -> 262 cycles 2. Kmalloc: alloc/free test 1 times kmalloc(8)/kfree -> 65 cycles 1 times kmalloc(16)/kfree -> 66 cycles 1 times kmalloc(32)/kfree -> 65 cycles 1 times kmalloc(64)/kfree -> 66 cycles 1 times kmalloc(128)/kfree -> 66 cycles 1 times kmalloc(256)/kfree -> 71 cycles 1 times kmalloc(512)/kfree -> 72 cycles 1 times kmalloc(1024)/kfree -> 71 cycles 1 times kmalloc(2048)/kfree -> 71 cycles 1 times kmalloc(4096)/kfree -> 71 cycles 1 times kmalloc(8192)/kfree -> 65 cycles 1 times kmalloc(16384)/kfree -> 511 cycles Most of the results are better than before. Note that this change slightly worses performance in !CONFIG_PREEMPT, roughly 0.3%. Implementing each case separately would help performance, but, since it's so marginal, I didn't do that. This would help maintanance since we have same code for all cases. Change from v1: add comment about barrier() usage Acked-by: Christoph Lameter Tested-by: Jesper Dangaard Brouer Signed-off-by: Joonsoo Kim --- mm/slub.c | 35 +++ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index fe376fe..ceee1d7 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2398,13 +2398,24 @@ redo: * reading from one cpu area. That does not matter as long * as we end up on the original cpu again when doing the cmpxchg. * -* Preemption is disabled for the retrieval of the tid because that -* must occur from the current processor. We cannot allow rescheduling -* on a different processor between the determination of the pointer -* and the retrieval of the tid. +* We should guarantee that tid and kmem_cache are retrieved on +* the same cpu. It could be different if CONFIG_PREEMPT so we need +* to check if it is matched or not. */ - preempt_disable(); - c =
[PATCH v2 2/2] mm: don't use compound_head() in virt_to_head_page()
compound_head() is implemented with assumption that there would be
race condition when checking tail flag. This assumption is only true
when we try to access arbitrary positioned struct page.
The situation that virt_to_head_page() is called is different case.
We call virt_to_head_page() only in the range of allocated pages,
so there is no race condition on tail flag. In this case, we don't
need to handle race condition and we can reduce overhead slightly.
This patch implements compound_head_fast() which is similar with
compound_head() except tail flag race handling. And then,
virt_to_head_page() uses this optimized function to improve performance.
I saw 1.8% win in a fast-path loop over kmem_cache_alloc/free,
(14.063 ns -> 13.810 ns) if target object is on tail page.
Acked-by: Christoph Lameter
Signed-off-by: Joonsoo Kim
---
include/linux/mm.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index f80d019..0460e2e 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -453,6 +453,13 @@ static inline struct page *compound_head(struct page *page)
return page;
}
+static inline struct page *compound_head_fast(struct page *page)
+{
+ if (unlikely(PageTail(page)))
+ return page->first_page;
+ return page;
+}
+
/*
* The atomic page->_mapcount, starts from -1: so that transitions
* both from it and to it can be tracked, using atomic_inc_and_test
@@ -531,7 +538,8 @@ static inline void get_page(struct page *page)
static inline struct page *virt_to_head_page(const void *x)
{
struct page *page = virt_to_page(x);
- return compound_head(page);
+
+ return compound_head_fast(page);
}
/*
--
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: [PATCH 1/3] input: tsc2007: Add pre-calibration, flipping and rotation
Hi, Am 15.01.2015 um 01:59 schrieb Dmitry Torokhov : > On Sat, Jan 10, 2015 at 03:15:39PM +0100, Belisko Marek wrote: >> Ping for input maintainer. DT changes was acked. Thanks. >> >> On Tue, Sep 30, 2014 at 10:17 PM, Marek Belisko wrote: >>> This patch adds new parameters that allow to address typical hardware >>> design differences: touch screens may be wired or oriented differently >>> (portrait or landscape). And usually the active area of the touch is a >>> little larger than the active area of the LCD. This results in the touch >>> coordinates that have some significant deviation from LCD coordinates. >>> Usually this is addressed in user space by a calibration tool (e.g. tslib >>> or xinput-calibrator) but some systems don't have these tools or require >>> that the screen is already roughly calibrated (e.g. Replicant) to operate >>> the device until a better calibration can be done. And, some systems >>> react very strangely if the touch event stream reports coordinates >>> outside of the active area. >>> >>> This makes it necessry to be able to configure: >>> 1. swapping x and y wires (coordinate values) >>> 2. flipping of x (left - right) or y (top - bottom) or even both >>> 3. define an active area so that an uncalibrated screen already >>> roughly matches the LCD to be useful. >>> 4. clip reported coordinates to the active area. >>> >>> If none of the new parameters is defined (in DT) or set in a board file, >>> the driver behaves the same as without this patch. >>> >>> Author (1&2): H. Nikolaus Schaller >>> Author (3&4): Paul Kocialkowski >>> >>> Signed-off-by: H. Nikolaus Schaller > > OK, I was hesitant of adding these as normally we have tslib to perform > the conversion, but maybe it is time to allow it in the kernel and > standardize users. Well, tslib isn’t a good replacement for this problem any more and pre-initializing tslib makes some deep hardware dependency visible in user space (each board needs a different tslib config and pointercal default - and on some user spaces tslib is broken with Xorg). But the issue to be solved is more hardware related, i.e. if the Y- and Y+ pins of the controller are connected in a swapped way to the resistor ends of the panel. Hence in a DT based system, this must IMHO be described by the DT and can not be left to some user-space functions any more. > However, this seems like a general issue and we > should: > > 1. Perform conversion in input core rather than individual drivers. I > think we should allocate a new bitmaps for some transformations and have > the code do X/Y flip/clip of the coordinates. Do you have a suggestion where this should be (I have no clue how the input system works or is structured - we just know how to extend a driver that uses it)? > > 2. Standardize on bindings. We already have of-touchscreen.c doing > rudimentary parsing, we shoudl look into extending it rather than > creating myriad of driver-specific bindings. Ok, looks reasonable. > > Also, do we need swap and flip or do we simply need rotation (like the > proposed Broadcom iproc driver has)? Well, since the DT should describe hardware, there are 3 sets of wires which can have a cross-over: X+ and X-, Y+ and Y-, X and Y. So IMHO hardware has no “rotation”, just crossover of wires. Rotation is an interpretation of the result of these connections in combination with some panel the touch is glued to and should therefore not be represented in the DT. As a result we have proposed a scheme without explicit rotation. We specify what coordinates X- and X+ should report at their ends (min, max) because the DT programmer has to specify them anyways. Flipping is a result of defining these coordinates in an ascending or descending way. Only swapping of the X and Y wires can’t be implicitly defined so it has its own property. So the scheme we have proposed tries to optimize the efforts needed to adapt new boards and write DTs and focus the DT on hardware description. As a bonus we also specify the min and max value to be reported for the touch pressure (Z axis) using the same basic principle. And it is a pure add-on on top of the existing driver so that it attempts not to break existing device trees. Maybe could you accept it as a first step for this specific driver (and let’s do the big standardization work later on)? — hns -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Makefile: allow building selected tests with non-NPTL toolchain
Hi Clark, John, On Mon, 2014-11-10 at 10:16 +0300, Alexey Brodkin wrote: > Some architectures are still stuck with non-NPTL toolchains. > These are for example ARC, Blackfin, Xtensa etc. > > Still rt-tests are very good benchmarks and it would be good to enable use of > at least selected (those that will be built) tests on those architectures. > > This change makes it possible to only build subset of tests that don't require > NPTL calls. > > By default behavior is not modified - all tests are built, but if one wants > to build with non-NPTL toolchain just add "HAVE_NPTL=no" in command line > or modify "HAVE_NPTL" variable right in Makefile and execute "make". > > Signed-off-by: Alexey Brodkin > Cc: Vineet Gupta > Cc: Clark Williams > --- > Makefile | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/Makefile b/Makefile > index 318a5c6..675edf7 100644 > --- a/Makefile > +++ b/Makefile > @@ -1,8 +1,13 @@ > VERSION_STRING = 0.89 > > -sources = cyclictest.c signaltest.c pi_stress.c rt-migrate-test.c\ > - ptsematest.c sigwaittest.c svsematest.c pmqtest.c sendme.c\ > - pip_stress.c hackbench.c > +HAVE_NPTL ?= yes > + > +ifeq ($(HAVE_NPTL),yes) > +sources = cyclictest.c pi_stress.c pip_stress.c pmqtest.c rt-migrate-test.c > +endif > + > +sources += signaltest.c ptsematest.c sigwaittest.c svsematest.c sendme.c \ > + hackbench.c > > TARGETS = $(sources:.c=) I'm wondering if there's a chance to get this patch reviewed and if there're no objections applied? Regards, Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sound/oss: use current->state helpers
At Wed, 14 Jan 2015 23:11:43 -0800,
Davidlohr Bueso wrote:
>
> From: Davidlohr Bueso
>
> Call __set_current_state() instead of assigning the new state directly.
> These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping
> track of who changed the state.
>
> Signed-off-by: Davidlohr Bueso
The author and sign-off have different addresses. Could you align?
thanks,
Takashi
> ---
> sound/oss/msnd_pinnacle.c | 4 ++--
> sound/oss/swarm_cs4297a.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/sound/oss/msnd_pinnacle.c b/sound/oss/msnd_pinnacle.c
> index c23f9f9..a8ceef8 100644
> --- a/sound/oss/msnd_pinnacle.c
> +++ b/sound/oss/msnd_pinnacle.c
> @@ -675,7 +675,7 @@ static void dsp_write_flush(void)
> timeout);
> clear_bit(F_WRITEFLUSH, );
> if (!signal_pending(current)) {
> - current->state = TASK_INTERRUPTIBLE;
> + __set_current_state(TASK_INTERRUPTIBLE);
> schedule_timeout(get_play_delay_jiffies(DAP_BUFF_SIZE));
> }
> clear_bit(F_WRITING, );
> @@ -1288,7 +1288,7 @@ static int __init calibrate_adc(WORD srate)
> & ~0x0001, dev.SMA + SMA_wCurrHostStatusFlags);
> if (msnd_send_word(, 0, 0, HDEXAR_CAL_A_TO_D) == 0 &&
> chk_send_dsp_cmd(, HDEX_AUX_REQ) == 0) {
> - current->state = TASK_INTERRUPTIBLE;
> + __set_current_state(TASK_INTERRUPTIBLE);
> schedule_timeout(HZ / 3);
> return 0;
> }
> diff --git a/sound/oss/swarm_cs4297a.c b/sound/oss/swarm_cs4297a.c
> index a33e8ce..213a416 100644
> --- a/sound/oss/swarm_cs4297a.c
> +++ b/sound/oss/swarm_cs4297a.c
> @@ -1654,7 +1654,7 @@ static int drain_dac(struct cs4297a_state *s, int
> nonblock)
> s->dma_dac.hwptr = s->dma_dac.swptr = hwptr;
> spin_unlock_irqrestore(>lock, flags);
> remove_wait_queue(>dma_dac.wait, );
> - current->state = TASK_RUNNING;
> + __set_current_state(TASK_RUNNING);
> return 0;
> }
>
> --
> 2.1.2
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] mcb: request_mem_region() returns NULL on error
On Thu, Jan 15, 2015 at 12:08:40AM +0300, Dan Carpenter wrote:
> The code here is checking for IS_ERR() when request_mem_region() only
> returns NULL on error and never an ERR_PTR.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/mcb/mcb-pci.c b/drivers/mcb/mcb-pci.c
> index 5e1bd5d..2d6524a 100644
> --- a/drivers/mcb/mcb-pci.c
> +++ b/drivers/mcb/mcb-pci.c
> @@ -56,9 +56,9 @@ static int mcb_pci_probe(struct pci_dev *pdev, const struct
> pci_device_id *id)
>
> res = request_mem_region(priv->mapbase, CHAM_HEADER_SIZE,
>KBUILD_MODNAME);
> - if (IS_ERR(res)) {
> + if (!res) {
> dev_err(>dev, "Failed to request PCI memory\n");
> - ret = PTR_ERR(res);
> + ret = -EBUSY;
> goto err_start;
> }
>
Applied to mcb-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] mfd: rtsx_usb: Defer autosuspend while card exists
A card insertion happens after the lastest polling before reader is
suspended may never have a chance to be detected. Under current 1-HZ
polling interval setting in mmc_core, the worst case of such
undetectablility is about 1 second.
To further reduce the undetectability, detect card slot again in suspend
method and defer the autosuspend if the slot is loaded. The default 2
second autosuspend delay of USB subsystem should let the next polling
detects the card.
Signed-off-by: Roger Tseng
---
drivers/mfd/rtsx_usb.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
index 076694126e5d..63883fd025c0 100644
--- a/drivers/mfd/rtsx_usb.c
+++ b/drivers/mfd/rtsx_usb.c
@@ -687,6 +687,20 @@ static int rtsx_usb_suspend(struct usb_interface *intf,
pm_message_t message)
dev_dbg(>dev, "%s called with pm message 0x%04x\n",
__func__, message.event);
+ if (PMSG_IS_AUTO(message)) {
+ if (mutex_trylock(>dev_mutex)) {
+ rtsx_usb_get_card_status(ucr, );
+ mutex_unlock(>dev_mutex);
+
+ /* Defer the autosuspend if card exists */
+ if (val & (SD_CD | MS_CD))
+ return -EAGAIN;
+ } else {
+ /* There is an ongoing operation*/
+ return -EAGAIN;
+ }
+ }
+
return 0;
}
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Fix PM deadlock and card detection problem
The patchset fixes a deadlock situation of runtime PM methods and minimize card detection "deadtime" during runtime suspending. Roger Tseng (2): mfd: rtsx_usb: Fix runtime PM deadlock mfd: rtsx_usb: Defer autosuspend while card exists drivers/mfd/rtsx_usb.c | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sound/oss: use current->state helpers
From: Davidlohr Bueso
Call __set_current_state() instead of assigning the new state directly.
These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping
track of who changed the state.
Signed-off-by: Davidlohr Bueso
---
sound/oss/msnd_pinnacle.c | 4 ++--
sound/oss/swarm_cs4297a.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/oss/msnd_pinnacle.c b/sound/oss/msnd_pinnacle.c
index c23f9f9..a8ceef8 100644
--- a/sound/oss/msnd_pinnacle.c
+++ b/sound/oss/msnd_pinnacle.c
@@ -675,7 +675,7 @@ static void dsp_write_flush(void)
timeout);
clear_bit(F_WRITEFLUSH, );
if (!signal_pending(current)) {
- current->state = TASK_INTERRUPTIBLE;
+ __set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(get_play_delay_jiffies(DAP_BUFF_SIZE));
}
clear_bit(F_WRITING, );
@@ -1288,7 +1288,7 @@ static int __init calibrate_adc(WORD srate)
& ~0x0001, dev.SMA + SMA_wCurrHostStatusFlags);
if (msnd_send_word(, 0, 0, HDEXAR_CAL_A_TO_D) == 0 &&
chk_send_dsp_cmd(, HDEX_AUX_REQ) == 0) {
- current->state = TASK_INTERRUPTIBLE;
+ __set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(HZ / 3);
return 0;
}
diff --git a/sound/oss/swarm_cs4297a.c b/sound/oss/swarm_cs4297a.c
index a33e8ce..213a416 100644
--- a/sound/oss/swarm_cs4297a.c
+++ b/sound/oss/swarm_cs4297a.c
@@ -1654,7 +1654,7 @@ static int drain_dac(struct cs4297a_state *s, int
nonblock)
s->dma_dac.hwptr = s->dma_dac.swptr = hwptr;
spin_unlock_irqrestore(>lock, flags);
remove_wait_queue(>dma_dac.wait, );
- current->state = TASK_RUNNING;
+ __set_current_state(TASK_RUNNING);
return 0;
}
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] mfd: rtsx_usb: Fix runtime PM deadlock
sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c
acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the
device is awake while initializing a newly inserted card. Once it is
called during suspending state and explicitly before rtsx_usb_suspend()
acquires the same dev_mutex, both routine deadlock and further hang the
driver because pm_runtime_get_sync() waits the pending PM operations.
Fix this by using an empty suspend method. mmc_core always turns the
LED off after a request is done and thus it is ok to remove the only
rtsx_usb_turn_off_led() here.
Cc: # v3.16+
Fixes: 730876be2566 ("mfd: Add realtek USB card reader driver")
Signed-off-by: Roger Tseng
---
drivers/mfd/rtsx_usb.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
index dbdd0faeb6ce..076694126e5d 100644
--- a/drivers/mfd/rtsx_usb.c
+++ b/drivers/mfd/rtsx_usb.c
@@ -687,15 +687,6 @@ static int rtsx_usb_suspend(struct usb_interface *intf,
pm_message_t message)
dev_dbg(>dev, "%s called with pm message 0x%04x\n",
__func__, message.event);
- /*
-* Call to make sure LED is off during suspend to save more power.
-* It is NOT a permanent state and could be turned on anytime later.
-* Thus no need to call turn_on when resunming.
-*/
- mutex_lock(>dev_mutex);
- rtsx_usb_turn_off_led(ucr);
- mutex_unlock(>dev_mutex);
-
return 0;
}
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/6] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
(2015/01/12 21:51), Steve Capper wrote:
> On Sat, Jan 10, 2015 at 11:03:16PM -0500, David Long wrote:
>> From: "David A. Long"
>>
>> Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.
>>
>> Signed-off-by: David A. Long
>> ---
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/include/asm/ptrace.h | 29 +
>> arch/arm64/include/uapi/asm/ptrace.h | 36 +++
>> arch/arm64/kernel/ptrace.c | 119
>> +++
>> 4 files changed, 185 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index b1f9a20..12b3fd6 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -64,6 +64,7 @@ config ARM64
>> select HAVE_PERF_EVENTS
>> select HAVE_PERF_REGS
>> select HAVE_PERF_USER_STACK_DUMP
>> +select HAVE_REGS_AND_STACK_ACCESS_API
>> select HAVE_RCU_TABLE_FREE
>> select HAVE_SYSCALL_TRACEPOINTS
>> select IRQ_DOMAIN
>> diff --git a/arch/arm64/include/asm/ptrace.h
>> b/arch/arm64/include/asm/ptrace.h
>> index 41ed9e1..3613e49 100644
>> --- a/arch/arm64/include/asm/ptrace.h
>> +++ b/arch/arm64/include/asm/ptrace.h
>> @@ -111,6 +111,8 @@ struct pt_regs {
>> u64 syscallno;
>> };
>>
>> +#define MAX_REG_OFFSET (sizeof(struct user_pt_regs) - sizeof(u64))
>> +
>> #define arch_has_single_step() (1)
>>
>> #ifdef CONFIG_COMPAT
>> @@ -139,11 +141,38 @@ struct pt_regs {
>> #define user_stack_pointer(regs) \
>> (!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
>>
>> +/**
>> + * regs_get_register() - get register value from its offset
>> + * @regs: pt_regs from which register value is gotten
>> + * @offset:offset number of the register.
>> + *
>> + * regs_get_register returns the value of a register whose offset from
>> @regs.
>> + * The @offset is the offset of the register in struct pt_regs.
>> + * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
>> + */
>> +static inline u64 regs_get_register(struct pt_regs *regs,
>> + unsigned int offset)
>> +{
>> +if (unlikely(offset > MAX_REG_OFFSET))
>> +return 0;
>> +return *(u64 *)((u64)regs + offset);
>> +}
>> +
>> +/* Valid only for Kernel mode traps. */
>> +static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
>> +{
>> +return regs->ARM_sp;
>> +}
>> +
>> static inline unsigned long regs_return_value(struct pt_regs *regs)
>> {
>> return regs->regs[0];
>> }
>>
>> +extern int regs_query_register_offset(const char *name);
>> +extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
>> + unsigned int n);
>> +
>> /*
>> * Are the current registers suitable for user mode? (used to maintain
>> * security in signal handlers)
>> diff --git a/arch/arm64/include/uapi/asm/ptrace.h
>> b/arch/arm64/include/uapi/asm/ptrace.h
>> index 6913643..700d28b 100644
>> --- a/arch/arm64/include/uapi/asm/ptrace.h
>> +++ b/arch/arm64/include/uapi/asm/ptrace.h
>> @@ -61,6 +61,42 @@
>>
>> #ifndef __ASSEMBLY__
>>
>> +#define ARM_cpsrpstate
>> +#define ARM_pc pc
>> +#define ARM_sp sp
>> +#define ARM_lr regs[30]
>> +#define ARM_fp regs[29]
>> +#define ARM_x28 regs[28]
>> +#define ARM_x27 regs[27]
>> +#define ARM_x26 regs[26]
>> +#define ARM_x25 regs[25]
>> +#define ARM_x24 regs[24]
>> +#define ARM_x23 regs[23]
>> +#define ARM_x22 regs[22]
>> +#define ARM_x21 regs[21]
>> +#define ARM_x20 regs[20]
>> +#define ARM_x19 regs[19]
>> +#define ARM_x18 regs[18]
>> +#define ARM_ip1 regs[17]
>> +#define ARM_ip0 regs[16]
>> +#define ARM_x15 regs[15]
>> +#define ARM_x14 regs[14]
>> +#define ARM_x13 regs[13]
>> +#define ARM_x12 regs[12]
>> +#define ARM_x11 regs[11]
>> +#define ARM_x10 regs[10]
>> +#define ARM_x9 regs[9]
>> +#define ARM_x8 regs[8]
>> +#define ARM_x7 regs[7]
>> +#define ARM_x6 regs[6]
>> +#define ARM_x5 regs[5]
>> +#define ARM_x4 regs[4]
>> +#define ARM_x3 regs[3]
>> +#define ARM_x2 regs[2]
>> +#define ARM_x1 regs[1]
>> +#define ARM_x0 regs[0]
>> +#define ARM_ORIG_x0 orig_x0
>> +
>> /*
>> * User structures for general purpose, floating point and debug registers.
>> */
>> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
>> index d882b83..9115b25 100644
>> --- a/arch/arm64/kernel/ptrace.c
>> +++ b/arch/arm64/kernel/ptrace.c
>> @@ -48,6 +48,125 @@
>> #define CREATE_TRACE_POINTS
>> #include
>>
>> +struct pt_regs_offset {
>> +const char *name;
>> +int offset;
>> +};
>> +
>> +#define REG_OFFSET_NAME(r) \
>> +{.name = #r, .offset =
linux-next: Tree for Jan 15
Hi all, Changes since 20150114: The renesas tree gained a conflict against the arm-soc tree. The net-next tree gained a conflict against the net tree. Non-merge commits (relative to Linus' tree): 2952 2909 files changed, 90289 insertions(+), 49341 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 234 trees (counting Linus' and 32 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (a6391a924cf5 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (a16c5f99a28c kbuild: Fix removal of the debian/ directory) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (1e3479225acb ARM: 8275/1: mm: fix PMD_SECT_RDONLY undeclared compile error) Merging m68k-current/for-linus (f27bd5bfeda5 m68k: Wire up execveat) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused force_32bit_msi quirk) Merging powerpc-merge-mpe/fixes (a87e810f61b4 powerpc: Work around gcc bug in current_thread_info()) Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() needs to disable interrupts.) Merging net/master (c637dbcedf31 Merge branch 'tg3-net') Merging ipsec/master (f855691975bb xfrm6: Fix the nexthdr offset in _decode_session6.) Merging sound-current/for-linus (92cb46584e10 ALSA: fireworks: fix an endianness bug for transaction length) Merging pci-current/for-linus (97bf6af1f928 Linux 3.19-rc1) Merging wireless-drivers/master (81a07128214e Merge tag 'wireless-drivers-for-davem-2015-01-09' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers) Merging driver-core.current/driver-core-linus (72392ed0eb6f kernfs: Fix kernfs_name_compare) Merging tty.current/tty-linus (31ec77aca72e serial: samsung: Add the support for Exynos5433 SoC) Merging usb.current/usb-linus (06087cb42dc1 Merge tag 'fixes-for-v3.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging usb-gadget-fixes/fixes (39e60635a015 usb: dwc3: gadget: Stop TRB preparation after limit is reached) Merging usb-serial-fixes/usb-linus (04f9c6e6d175 usb: serial: handle -ENODEV quietly in generic_submit_read_urb) Merging staging.current/staging-linus (a307d1d6d4cf staging: vt6655: fix sparse warning: argument type) Merging char-misc.current/char-misc-linus (7b7c54914f73 mcb: mcb-pci: Only remap the 1st 0x200 bytes of BAR 0) Merging input-current/for-linus (9333caeaeae4 Input: I8042 - add Acer Aspire 7738 to the nomux list) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (3e14dcf7cb80 crypto: add missing crypto module aliases) Merging ide/master (f96fe225677b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (094cb98179f1 of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap) Merging rr-fixes/fixes (574732c73d15 param: initialize store function to NULL if not available.) Merging vfio-fixes/for-linus (7c2e211f3c95 vfio-pci: Fix the check on pci device type in vfio_pci_probe()) Merging kselftest-fixes/fi
[PATCH 1/3] ipc,sem: use current->state helpers
Call __set_current_state() instead of assigning the new state directly. These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping track of who changed the state. Signed-off-by: Davidlohr Bueso --- ipc/sem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipc/sem.c b/ipc/sem.c index 6115146..9284211 100644 --- a/ipc/sem.c +++ b/ipc/sem.c @@ -1941,7 +1941,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf __user *, tsops, queue.sleeper = current; sleep_again: - current->state = TASK_INTERRUPTIBLE; + __set_current_state(TASK_INTERRUPTIBLE); sem_unlock(sma, locknum); rcu_read_unlock(); -- 2.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 06/10] iommu/vt-d: datatypes and functions used for kdump
On 01/15/15 at 01:45pm, Li, ZhenHua wrote:
> Hi Baoquan,
> Thank you very much for your review. But according to the latest
> discussion, the page tables will not be copied from old kernel. We keep
> using the old page tables before driver is loaded. So there are many
> changes in next version;
Oh, yes. So please ignore this comment.
>
> See my comments.
>
> On 01/15/2015 11:28 AM, Baoquan He wrote:
> >On 01/12/15 at 03:06pm, Li, Zhen-Hua wrote:
> >>+/*
> >>+ * Interface to the "copy translation tables" set of functions
> >>+ * from mainline code.
> >>+ */
> >>+static int intel_iommu_load_translation_tables(struct dmar_drhd_unit *drhd,
> >>+ int g_num_of_iommus)
> >
> >The argument g_num_of_iommus is the same as the global variable, it's better
> >to rename it as num_of_iommus. And even it can be removed since you can
> >just use the global variable g_num_of_iommus in this function.
> >
> >Argument drhd can be intel_iommu because no other member variable in
> >drhd is needed.
>
> This function is no longer used. So forget the parameters.
>
> >
> >>+{
> >>+ struct intel_iommu *iommu; /* Virt(iommu hardware registers) */
> >>+ unsigned long long q; /* quadword scratch */
> >>+ int ret = 0;/* Integer return code */
> >>+ int i = 0; /* Loop index */
> >>+ unsigned long flags;
> >>+
> >>+ /* Structure so copy_page_addr() can accumulate things
> >>+* over multiple calls and returns
> >>+*/
> >>+ struct copy_page_addr_parms ppa_parms = copy_page_addr_parms_init;
> >>+ struct copy_page_addr_parms *ppap = _parms;
> >>+
> >>+
> >>+ iommu = drhd->iommu;
> >>+ q = dmar_readq(iommu->reg + DMAR_RTADDR_REG);
> >>+ if (!q)
> >>+ return -1;
> >>+
> >>+ /* If (list needs initializing) do it here */
> >
> >This initializing should not be here, because it's not only for this
> >drhd. It should be done in init_dmars().
> >
> Yes you are right. Though the variable domain_values_list will not be
> used in next version, I think I need to check if there are any other
> similar problems.
>
> >>+ if (!domain_values_list) {
> >>+ domain_values_list =
> >>+kcalloc(g_num_of_iommus, sizeof(struct list_head),
> >>+ GFP_KERNEL);
> >>+
> >>+ if (!domain_values_list) {
> >>+ pr_err("Allocation failed for domain_values_list
> >>array\n");
> >>+ return -ENOMEM;
> >>+ }
> >>+ for (i = 0; i < g_num_of_iommus; i++)
> >>+ INIT_LIST_HEAD(_values_list[i]);
> >>+ }
> >>+
> >>+ spin_lock_irqsave(>lock, flags);
> >>+
> >>+ /* Load the root-entry table from the old kernel
> >>+* foreach context_entry_table in root_entry
> >>+*foreach context_entry in context_entry_table
> >>+* foreach level-1 page_table_entry in context_entry
> >>+* foreach level-2 page_table_entry in level 1 page_table_entry
> >>+* Above pattern continues up to 6 levels of page tables
> >>+*Sanity-check the entry
> >>+*Process the bus, devfn, page_address, page_size
> >>+*/
> >>+ if (!iommu->root_entry) {
> >>+ iommu->root_entry =
> >>+ (struct root_entry *)alloc_pgtable_page(iommu->node);
> >>+ if (!iommu->root_entry) {
> >>+ spin_unlock_irqrestore(>lock, flags);
> >>+ return -ENOMEM;
> >>+ }
> >>+ }
> >>+
> >>+ iommu->root_entry_old_phys = q & VTD_PAGE_MASK;
> >>+ if (!iommu->root_entry_old_phys) {
> >>+ pr_err("Could not read old root entry address.");
> >>+ return -1;
> >>+ }
> >>+
> >>+ iommu->root_entry_old_virt = ioremap_cache(iommu->root_entry_old_phys,
> >>+ VTD_PAGE_SIZE);
> >>+ if (!iommu->root_entry_old_virt) {
> >>+ pr_err("Could not map the old root entry.");
> >>+ return -ENOMEM;
> >>+ }
> >>+
> >>+ __iommu_load_old_root_entry(iommu);
> >>+ ret = copy_root_entry_table(iommu, ppap);
> >>+ __iommu_flush_cache(iommu, iommu->root_entry, PAGE_SIZE);
> >>+ __iommu_update_old_root_entry(iommu, -1);
> >>+
> >>+ spin_unlock_irqrestore(>lock, flags);
> >>+
> >>+ __iommu_free_mapped_mem();
> >>+
> >>+ if (ret)
> >>+ return ret;
> >>+
> >>+ ppa_parms.last = 1;
> >>+ copy_page_addr(0, 0, 0, 0, 0, NULL, ppap);
> >>+
> >>+ return 0;
> >>+}
> >>+
> >> #endif /* CONFIG_CRASH_DUMP */
> >>--
> >>2.0.0-rc0
> >>
> >>
> >>___
> >>kexec mailing list
> >>ke...@lists.infradead.org
> >>http://lists.infradead.org/mailman/listinfo/kexec
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] jbd: drop jbd_ENOSYS debug
A quick search shows that there are no users, drop the
macro for both jbd and jbd2.
Signed-off-by: Davidlohr Bueso
Cc: Jan Kara
---
My goal here was to just change how we set current state, however
I realized that the function is not used.
include/linux/jbd.h | 9 -
include/linux/jbd2.h | 9 -
2 files changed, 18 deletions(-)
diff --git a/include/linux/jbd.h b/include/linux/jbd.h
index 31229e0..d326152 100644
--- a/include/linux/jbd.h
+++ b/include/linux/jbd.h
@@ -956,15 +956,6 @@ void __log_wait_for_space(journal_t *journal);
extern void__journal_drop_transaction(journal_t *, transaction_t *);
extern int cleanup_journal_tail(journal_t *);
-/* Debugging code only: */
-
-#define jbd_ENOSYS() \
-do { \
- printk (KERN_ERR "JBD unimplemented function %s\n", __func__); \
- current->state = TASK_UNINTERRUPTIBLE; \
- schedule();\
-} while (1)
-
/*
* is_journal_abort
*
diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
index 704b9a5..20e7f78 100644
--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -1251,15 +1251,6 @@ void __jbd2_log_wait_for_space(journal_t *journal);
extern void __jbd2_journal_drop_transaction(journal_t *, transaction_t *);
extern int jbd2_cleanup_journal_tail(journal_t *);
-/* Debugging code only: */
-
-#define jbd_ENOSYS() \
-do { \
- printk (KERN_ERR "JBD unimplemented function %s\n", __func__); \
- current->state = TASK_UNINTERRUPTIBLE; \
- schedule();\
-} while (1)
-
/*
* is_journal_abort
*
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] signal: use current->state helpers
Call __set_current_state() instead of assigning the new state directly.
These interfaces also aid CONFIG_DEBUG_ATOMIC_SLEEP environments, keeping
track of who changed the state.
Signed-off-by: Davidlohr Bueso
Cc: Oleg Nesterov
---
kernel/signal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index 33a5275..a390499 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -3550,7 +3550,7 @@ SYSCALL_DEFINE2(signal, int, sig, __sighandler_t, handler)
SYSCALL_DEFINE0(pause)
{
while (!signal_pending(current)) {
- current->state = TASK_INTERRUPTIBLE;
+ __set_current_state(TASK_INTERRUPTIBLE);
schedule();
}
return -ERESTARTNOHAND;
@@ -3563,7 +3563,7 @@ int sigsuspend(sigset_t *set)
current->saved_sigmask = current->blocked;
set_current_blocked(set);
- current->state = TASK_INTERRUPTIBLE;
+ __set_current_state(TASK_INTERRUPTIBLE);
schedule();
set_restore_sigmask();
return -ERESTARTNOHAND;
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [3.4] neigh_destroy() crashes on unplug netdev.
On Thu, 2015-01-15 at 05:57 +, Nakashima Akihiro wrote: > Dear David and networking developers: > > I got kernel panic on 3.4.105 kernel. > Please see a report below. Please try a recent kernel. We are not going to debug such an old one, given there are chances we already fixed the problem ages ago. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] Please pull mpe/linux.git powerpc-3.19-4 tag
Hi Linus, Please pull some more powerpc fixes for 3.19: The following changes since commit eaa27f34e91a14cdceed26ed6c6793ec1d186115: linux 3.19-rc4 (2015-01-11 12:44:53 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git tags/powerpc-3.19-4 for you to fetch changes up to a87e810f61b49f19bd29ea564b7cd1e92e43d989: powerpc: Work around gcc bug in current_thread_info() (2015-01-12 16:40:02 +1100) Anton Blanchard (1): powernv: Fix OPAL tracepoint code Ian Munsie (1): cxl: Fix issues when unmapping contexts Michael Ellerman (1): powerpc: Work around gcc bug in current_thread_info() arch/powerpc/include/asm/thread_info.h | 13 ++-- arch/powerpc/platforms/powernv/opal-wrappers.S | 1 - drivers/misc/cxl/context.c | 82 -- drivers/misc/cxl/file.c| 14 +++-- 4 files changed, 78 insertions(+), 32 deletions(-) signature.asc Description: This is a digitally signed message part
[PATCH v2] drm/panel: Add support for AUO b101ean01 panel
The AUO b101ean01 panel is a 10.1" 1280x800 panel,
which can be supported by the simple panel driver.
Signed-off-by: huang lin
---
Changes in v2:
- changed panel timing
drivers/gpu/drm/panel/panel-simple.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index e95385b..c02f0e6 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -392,6 +392,29 @@ static const struct panel_desc auo_b116xw03 = {
},
};
+static const struct drm_display_mode auo_b101ean01_mode = {
+ .clock = 72500,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 147,
+ .hsync_end = 1280 + 147 + 32,
+ .htotal = 1280 + 147 + 32 + 21,
+ .vdisplay = 800,
+ .vsync_start = 800 + 4,
+ .vsync_end = 800 + 4 + 4,
+ .vtotal = 800 + 4 + 4 + 8,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_b101ean01 = {
+ .modes = _b101ean01_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+};
+
static const struct drm_display_mode auo_b133xtn01_mode = {
.clock = 69500,
.hdisplay = 1366,
@@ -727,6 +750,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b101aw03",
.data = _b101aw03,
}, {
+ .compatible = "auo,b101ean01",
+ .data = _b101ean01,
+ }, {
.compatible = "auo,b101xtn01",
.data = _b101xtn01,
}, {
--
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 v2] usb: dwc2: call dwc2_is_controller_alive() under spinlock
Hi, On Wed, Jan 14, 2015 at 11:04:27PM +, Paul Zimmerman wrote: > > > > > > > > > > This is really, really odd. Register accesses are atomic, > > > > > > > > > > so the lock > > > > > > > > > > isn't really doing anything. Besides, you're calling > > > > > > > > > > dwc2_is_controller_alive() from within the IRQ handler, so > > > > > > > > > > IRQs are > > > > > > > > > > already disabled. > > > > > > > > > > > > > > > > > > Spinlocks sometimes do more than you think. For instance, > > > > > > > > > here the > > > > > > > > > lock prevents the register access from happening while some > > > > > > > > > other CPU > > > > > > > > > is holding the lock. If a silicon quirk causes the register > > > > > > > > > access to > > > > > > > > > interfere with other activities, this could be important. > > > > > > > > > > > > > > > > readl() (which is used by dwc2_is_controller_alive()) adds a > > > > > > > > memory > > > > > > > > barrier to the register accesses, that should force all register > > > > > > > > accesses the be correctly ordered. > > > > > > > > > > > > > > Memory barriers will order accesses that are all made on the same > > > > > > > CPU > > > > > > > with respect to each other. They do not order these accesses > > > > > > > against > > > > > > > accesses made from another CPU -- that's why we have spinlocks. > > > > > > > :-) > > > > > > > > > > > > a fair point :-) The register is still read-only, so that shouldn't > > > > > > matter either :-) > > > > > > > > > > > > > > I fail to see how a silicon quirk > > > > > > > > could cause this and if, indeed, it does, I'd be more > > > > > > > > comfortable with a > > > > > > > > proper STARS tickect number from synopsys :-s > > > > > > > > > > > > > > Maybe accessing this register somehow resets something else. I > > > > > > > don't > > > > > > > know. It seems unlikely, but at least it explains how adding a > > > > > > > spinlock could fix the problem. > > > > > > > > > > > > I would really need Paul (or someone at Synopsys) to confirm this > > > > > > somehow. Maybe it has something to do with how the register is > > > > > > implemented, dunno. > > > > > > > > > > > > Paul, do you have any idea what could cause this ? Could the HW into > > > > > > some weird state if we read GSNPSID at random locations or when > > > > > > data is > > > > > > being transferred, or anything like that ? > > > > > > > > > > Only thing I can think of is that there is some silicon bug in > > > > > Robert's > > > > > platform. But I am not aware of any STARs that mention accesses to the > > > > > GSNPSID register as being problematic. > > > > > > > > > > Funny thing is, this code has been basically the same since at least > > > > > November 2013. So I think some other recent change must have modified > > > > > the timing of the register accesses, or something like that. But > > > > > that's > > > > > just handwaving, really. > > > > > > > > Alright, I'll apply this patch but for 3.20 with a stable tag as I have > > > > already sent my last pull request to Greg. Unless someone has a really > > > > big complaint about doing things as such. > > > > > > It should go to 3.19-rc shouldn't it? It's a fix, and Robert's platform > > > is broken without it, IIUC. > > > > It can also be categorized as "has-never-worked-before" before the code > > has been like this forever. Since we don't really have a git bisect > > result pointing to a commit that went in v3.19 merge window, I'm not > > sure how I can convince myself that this absolutely needs to be in > > v3.19. > > > > At a minimum, I need a proper bisection with a proper commit being > > blamed (even if it's a commit from months ago). From my point of view, > > debugging of this "regression" has not been finalized and we're just > > "assuming" it's caused by GSNPSID because moving that inside the > > spin_lock seems to fix the problem. > > On further investigation, I was wrong about "this code has been > basically the same since at least November 2013". Prior to commit > db8178c33db "usb: dwc2: Update common interrupt handler to call gadget > interrupt handler" from November 2014, the gadget interrupt handler > did not read from the GSNPSID register. right, but the common IRQ always did. So unless Robert's SoC has always been used only for peripheral, then I agree with you that behavior did, in fact, change. > So likely the bug in Robert's hardware has been there all along, and > that commit just caused it to manifest itself. Robert, out of curiosity, which SoC are you using ? Is it UP or SMP ? I guess we need a mention on commit log that at least SoC XYZ is known to break unless the register access is done with locks held. -- balbi signature.asc Description: Digital signature
Re: [alsa-devel] unload Audio drivers while playback stream is active case kernel crash
At Wed, 14 Jan 2015 16:34:15 +, Mark Brown wrote: > > On Wed, Jan 14, 2015 at 02:01:33PM +0100, Takashi Iwai wrote: > > Mark Brown wrote: > > > > > Above all, disallowing the module unload while using is the common > > > > behavior of any other drivers. Why do we have to be a rebel against > > > > all civil manner? :) > > > > That's not true for everything > > > Hmm, which driver does behave so intentionally? I'm interested in the > > supposed reason behind it. > > Relatively few of the subsystems in drivers have references to > module_get(). Time flys... At the time of Linux 2.2 kernels, it was fairly common to run a regular auto-cleanup of unused modules via cron running "rmmod -a". Thus, each driver was mandated to deal with the module refcount while used, or set it to -1 to avoid the auto-unload permanently (like ipv6). > > > and for ASoC I'd tend to assume that the > > > user knows what they're doing and has a good reason for it; it's > > > certainly something that can be helpful in development. > > > The module unload is never considered to be equivalent with hot > > unplug It's more than that. > > I'm not sure that's the case from a user perspective. Unloading a module means to remove the functionality. Unbinding is to remove a device aka hotunplug. Conceptually totally different. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [alsa-devel] unload Audio drivers while playback stream is active case kernel crash
At Thu, 15 Jan 2015 13:40:49 +0900, jiwang wrote: > > Hi > On 01/14/2015 10:43 PM, Fabio Estevam wrote: > > On Wed, Jan 14, 2015 at 10:57 AM, Lars-Peter Clausen > > wrote: > > > >> My personal opinion on this is that disallowing module removal while a > >> driver registered by the module when is in use, while there is no technical > >> reason to do so, is a anti-feature. Whether in ALSA or elsewhere. > >> > >> But looking at the source it seems that this is a core feature of ALSA and > >> at least for the card module itself it will do the ref-counting when a > >> stream is started/stopped. And we even support setting the owner of a card > >> in ASoC. It's just that pretty much no ASoC card driver bothers to set the > >> owner field in the snd_soc_card struct. So this particular problem can be > >> fixed by updating the imx-wm8962 driver to set the owner field. > > Thanks, Lars_Peter. This fixes the issue: > > > > root@freescale /$ modprobe -r snd_soc_imx_wm8962 > > modprobe: can't unload module snd_soc_imx_wm8962: Resource temporarily > > unavailable > > > > Will send a patch with your suggestion soon. > I think by set owner field in imx_wm8962 machine driver can fix the > crash I saw on sabreSD board, > but as this is a generic issue which I suppose should exist on other > boards with different > machine drivers. > > Can we have a more generic fix to this issue? > Or shall we set owner field for all machine drivers? This is two folds. The lack of card's owner field is a bug of each driver. Another is the missing of a hotplug-safe cleanup in ASoC core. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [media] dvb-core: Fix frontend thread serialization
From 2384c119d04b54e6e6c282a8693246c4e7d1347e Mon Sep 17 00:00:00 2001
From: "bk0121.shin"
Date: Wed, 14 Jan 2015 20:35:57 +0900
Subject: [PATCH] [media] dvb-core: Fix frontend thread serialization
dvb_frontend_thread's life cycle is controlled by dvb_frontend_start
and dvb_frontend_release.
But, if user opens frontend device before the thread exits completely,
dvb_frontend_start doesn't create a new thread.
When exit condition of thread that is jiffies is triggered
by dvb_frontend_release, dvb_frontend_thread wakes up and checks
exit condition without semaphore acquiring.
In this case, if user context checks existence of thread(fepriv->thread),
it is true, and exit flage has DVB_FE_NO_EXIT.
Therefore, dvb_frontend_start doesn't make a new thread,
previous old thread is going to terminate.
To fix this problem, semaphore should preserve thread exit condition and
checking it, which are dvb_frontend_is_exiting and fe->exit.
Signed-off-by: bk0121.shin
---
drivers/media/dvb-core/dvb_frontend.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 2cf3057..a8e8d44 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -620,14 +620,17 @@ restart:
|| freezing(current),
fepriv->delay);
+ if (down_interruptible(>sem))
+ break;
+
if (kthread_should_stop() || dvb_frontend_is_exiting(fe)) {
/* got signal or quitting */
- if (!down_interruptible(>sem))
- semheld = true;
+ semheld = true;
fe->exit = DVB_FE_NORMAL_EXIT;
break;
}
+ up(>sem);
if (try_to_freeze())
goto restart;
@@ -821,17 +824,22 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
dev_dbg(fe->dvb->device, "%s:\n", __func__);
+ if (down_interruptible(>sem))
+ return -EINTR;
+
if (fepriv->thread) {
- if (fe->exit == DVB_FE_NO_EXIT)
+ if (fe->exit == DVB_FE_NO_EXIT) {
+ up(>sem);
return 0;
- else
+ } else {
dvb_frontend_stop (fe);
+ }
}
- if (signal_pending(current))
- return -EINTR;
- if (down_interruptible (>sem))
+ if (signal_pending(current)) {
+ up(>sem);
return -EINTR;
+ }
fepriv->state = FESTATE_IDLE;
fe->exit = DVB_FE_NO_EXIT;
--
1.9.1
---
Byeongki Shin
Senior Engineer
Office:
Mobile: +82-10-3268-8201
E-Mail: bk0121.s...@samsung.com
0001-media-dvb-core-Fix-frontend-thread-serialization.patch
Description: Binary data
Re: [PATCH] tracing: Allow raw_syscall tracepoints to work from boot
On Wed, 2015-01-14 at 13:03 -0500, Steven Rostedt wrote: > On Wed, 14 Jan 2015 09:35:17 +1100 > Michael Ellerman wrote: > > > In commit 5f893b2639b2 "tracing: Move enabling tracepoints to just after > > rcu_init()", tracing was enabled earlier in boot. > > > > This broke tracing of the raw_syscall tracepoints from boot using the > > trace_event kernel parameter. > > > > We can fix it by explicitly setting TIF_SYSCALL_TRACEPOINT for the > > init_task. That way when pid 1 is cloned from init_task it will inherit > > TIF_SYSCALL_TRACEPOINT. > > I don't like setting the swap task flag for syscall tracing, as nothing > will unset it. We could unset it in the unregfunc(), I did that in my original patch but took it out because I wasn't sure it was necessary. > > It feels a bit naughty to be whacking init_task like this, but it also > > seems like the right fix? > > No, I tried the following instead. > > > Should we also clear it in the unregfunc? I can't see how that would > > ever be needed in practice? > > It just seems hacky to set swapper in the first place. Actually I thought it was neat, basically everything else comes from init_task via copy_process(). > Try my patch and let me know if it works for you? Sure. It works. I can still see the first syscalls in the trace: # entries-in-buffer/entries-written: 1021354/1021354 #P:8 # # _-=> irqs-off # / _=> need-resched #| / _---=> hardirq/softirq #|| / _--=> preempt-depth #||| / delay # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | init-1 [000] 3.706370: sys_exit: NR -1 = 0 init-1 [000] 3.706394: sys_enter: NR 45 (0, 0, 3fffa2e2, 3fffcfd4eac2, 80, 3fffa2e61820) init-1 [000] 3.706395: sys_exit: NR 45 = 70367490932736 init-1 [000] 3.706409: sys_enter: NR 33 (3fffa2e694d0, 0, 3fffa2e7be20, 0, 1, e000) init-1 [000] 3.713325: sys_exit: NR 33 = -2 I like my version better, but your call. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: [3.4] neigh_destroy() crashes on unplug netdev.
Dear David and networking developers: I got kernel panic on 3.4.105 kernel. Please see a report below. [1.] One line summary of the problem: [3.4] neigh_destroy() crashes on unplug netdev. [2.] Full description of the problem/report: I got kernel panic: neigh_destroy() crashes on unplug my wlan dongle. Please see Oops.. message for detail. I found this problem is occured on kernel 3.4 branch, but kernel 3.6 or later do not have it. It does not occur on every netdev device, but I think it is not a driver specific problem. And I found 20 patches that you released on 05-Jul-2012 look effective to solve it. Patches are below: 01. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a263b3093641fb1ec377582c90986a7fd0625184 02. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3c521f2ba9646c5543963cbc2b9c9d3f02a82594 03. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=60d354ebebd9d0f760cb6c3b9f53a7ade0f8cd0e 04. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5110effee8fde2edfacac9cd12a9960ab2dc39ea 05. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f894cbf847c9bea1955095bf37aca6c050553167 06. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dbedbe6d56e8944f220e34deb9ebdf4bec2a2afd 07. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=178709bbfe9d4fe432c272ed65a34b8582703c23 08. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=24db1ba866eebf5b516df80ea2212d2479bfb502 09. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0b399d46b317a6d0a73ad523e014ecfa4d449769 10. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c473737765c0f72ceb5b245ada7ead798d88b4f6 11. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f9d751667fd60788fe3641738938e0968e99cece 12. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=13a43d94ab026c423dc8902170ef27c2bd36aa87 13. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fccd7d5c77ff61d5283e7ce8242791d5f00dcc17 14. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1d248b1cf4e09dbec8cef5f7fbeda5874248bd09 15. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=534cb283efef9fdbd9f70f4615054d26aa444dd6 16. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=97cac0821af4474ec4ba3a9e7a36b98ed9b6db88 17. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f187bc6efb7250afee0e2009b6106370319b0c8b 18. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1e31fb02b31ba88d5650d97c35eb58f52bfe0e1 19. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=36bdbcae2fa2a6dfa99344d4190fcea0aa7b7c25 20. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a2de86f63cfc92f7aaf11e7b9d9f2150946a1622 I applied these patches to 3.4.105 kernel, and confirmed the problem is solved on my box. Could you confirm and backport them to 3.4 branch? [3.] Keywords (i.e., modules, networking, kernel): networking [4.] Kernel version (from /proc/version): Linux version 3.4.105 (root@JP1201393) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #2 SMP Tue Jan 13 13:39:40 JST 2015 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) BUG: unable to handle kernel paging request at f87be0ac IP: [] neigh_destroy+0x8f/0x110 *pdpt = 018c0001 *pde = 32f7c067 *pte = Oops: [#1] SMP Modules linked in: mt7603u_sta(0) nls_iso8859_1 bnep rfcomm bluetooth snd_hda_codec_realtek snd_hda_intel snd_hda_codec i915 snd_hwdep snd_pcm drm_kms_helper binfmt_misc snd_seq_midi drm snd_rawmidi snd_seq_midi_event snd_seq aesni_intel snd_timer snd_seq_device snd cryptd aes_i586 i2c_algo_bit microcode soundcore psmouse video snd_page_alloc serio_raw mac_hid ppdev parport_pc lp parport usbhid hid usb_storage ahci firewire_ohci libahci firewire_core crc_itu_te1000e Pid: 19, comm: ksoftirqd/3 Tainted: G O 3.4.105 #1 EPSON DIRECT CORP. MR690D0F61/MR6900 EIP: 0060:[] EFLAGS: 00010206 CPU: 3 EIP is at neigh_destroy+0x8f/0x110 EAX: f87be000 EBX: f1fd461c ECX: 80150006 EDX: 0100 ESI: f1fd4600 EDI: ec5ae000 EBP: f2d71ef4 ESP: f2d71edc DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 8005003b CR2: f87be0ac CR3: 3184b000 CR4: 000407f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process ksoftirqd/3 (pid: 19, ti=f2d7 task=f2d68000 task.ti=f2d7) Stack: c1472b23 c1472b23 f1fd4614 ee27b0c0 0005 f2d71f0c c1472b95 c1552da3 000a ee26a9c0 0005 f2d71f14 c149292c f2d71f44 c10a80f6 f33bc0e0 000a f1b1cc8c f33bc0f8 c17b9ec0 f2d68000 0003 Call Trace: [] ?
Re: [PATCH v2 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver
On Wed, Jan 14, 2015 at 09:44:39PM -0800, Scott Branden wrote:
> On 15-01-14 05:02 PM, Dmitry Torokhov wrote:
> >Hi Jonathan,
> >
> >On Fri, Dec 19, 2014 at 02:17:49PM -0800, Jonathan Richardson wrote:
> >>+ if (of_property_read_u32(np, "scanning_period", ) >= 0) {
> >>+ if (val < 1 || val > 256) {
> >>+ dev_err(dev, "scanning_period must be [1-256]\n");
> >>+ return -EINVAL;
> >>+ }
> >>+ priv->cfg_params.scanning_period = val;
> >>+ }
> >>+
> >>+ if (of_property_read_u32(np, "debounce_timeout", ) >= 0) {
> >>+ if (val < 0 || val > 255) {
> >>+ dev_err(dev, "debounce_timeout must be [0-255]\n");
> >>+ return -EINVAL;
> >>+ }
> >>+ priv->cfg_params.debounce_timeout = val;
> >>+ }
> >>+
> >>+ if (of_property_read_u32(np, "settling_timeout", ) >= 0) {
> >>+ if (val < 0 || val > 11) {
> >>+ dev_err(dev, "settling_timeout must be [0-11]\n");
> >>+ return -EINVAL;
> >>+ }
> >>+ priv->cfg_params.settling_timeout = val;
> >>+ }
> >>+
> >>+ if (of_property_read_u32(np, "touch_timeout", ) >= 0) {
> >>+ if (val < 0 || val > 255) {
> >>+ dev_err(dev, "touch_timeout must be [0-255]\n");
> >>+ return -EINVAL;
> >>+ }
> >>+ priv->cfg_params.touch_timeout = val;
> >>+ }
> >>+
> >>+ if (of_property_read_u32(np, "average_data", ) >= 0) {
> >>+ if (val < 0 || val > 8) {
> >>+ dev_err(dev, "average_data must be [0-8]\n");
> >>+ return -EINVAL;
> >>+ }
> >>+ priv->cfg_params.average_data = val;
> >>+ }
> >>+
> >>+ if (of_property_read_u32(np, "fifo_threshold", ) >= 0) {
> >>+ if (val < 0 || val > 31) {
> >>+ dev_err(dev, "fifo_threshold must be [0-31]\n");
> >>+ return -EINVAL;
> >>+ }
> >>+ priv->cfg_params.fifo_threshold = val;
> >>+ }
> >
> >I think these are dveice specific and thus should have "brcm," prefix.
> I'm confused as to why we need the brcm prefix? Other device tree
> bindings we have for other drivers do not need such prefix.
Properties that are not standard on the system (reg, interrupts,
clkocks, etc) or subsystem level customarily carry the vendor prefix so
that they do not clash with newly added global or subsystem properties.
> Is this
> convention documented somewhere?
Not sure. I glanced through Documentation/devicetree and do not see it
spelled out. Device tree overlords, what say you?
> >
> >>+
> >>+ priv->ts_rotation = TS_ROTATION_0;
> >>+ if (of_property_read_u32(np, "ts-rotation", ) >= 0) {
> >>+ priv->ts_rotation = val;
> >>+ dev_dbg(dev, "ts rotation [%d] degrees\n",
> >>+ 90 * priv->ts_rotation);
> >>+ }
> >
> >This I am not quite sure about - if we want rotation or swap+invert. You
> >are CCed on another email (tsc2007) that talks about need of generic
> >touchscreen transforms in input core/of bindings.
> Does such generic binding exist today? If not, I would like to go
> with this implementation and update to the new binding if/when it
> exists?
Not yet but there several people interested. I think we have enough time
till 3.20 to hash it out properly.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell
Date: Thu, 15 Jan 2015 13:47:35 +1100
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/xen-netfront.c between commit 900e183301b5 ("xen-netfront:
> use different locks for Rx and Tx stats") from the net tree and commit
> a55e8bb8fb89 ("xen-netfront: refactor making Tx requests") from the
> net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Thanks a lot Stephen, I just resolved this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf: perl: force to use stdbool.
When building perf for arm64 I hit a warning (and be treated as an error) like below: aarch64-oe-linux-gcc -o .../util/scripting-engines/trace-event-python.o -c -Wbad-function-cast \ ... util/scripting-engines/trace-event-python.c In file included from .../usr/lib64/perl/5.14.3/CORE/perl.h:2464:0, from Context.xs:23: /.../usr/lib64/perl/5.14.3/CORE/handy.h:108:0: error: "bool" redefined [-Werror] # define bool char ^ In file included from /.../usr/src/kernel/tools/include/linux/types.h:4:0, from /.../usr/src/kernel/arch/arm64/include/uapi/asm/sigcontext.h:19, from /.../usr/include/bits/sigcontext.h:27, from /.../usr/include/signal.h:340, from /.../usr/include/sys/param.h:28, from /.../usr/lib64/perl/5.14.3/CORE/perl.h:678, from Context.xs:23: /.../usr/lib/aarch64-oe-linux/gcc/aarch64-oe-linux/4.9.2/include/stdbool.h:33:0: note: this is the location of the previous definition #define bool _Bool Looks like the failure is caused by arm64 uapi/asm/sigcontext.h, which includes linux/types.h while other archs not. This patch includes stdbool.h before Context.xs and define HAS_BOOL to prevent perl'e headers define its own 'bool'. Signed-off-by: Wang Nan --- tools/perf/scripts/perl/Perf-Trace-Util/Context.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/perf/scripts/perl/Perf-Trace-Util/Context.c b/tools/perf/scripts/perl/Perf-Trace-Util/Context.c index 790ceba..69c3572 100644 --- a/tools/perf/scripts/perl/Perf-Trace-Util/Context.c +++ b/tools/perf/scripts/perl/Perf-Trace-Util/Context.c @@ -5,7 +5,8 @@ * ANY CHANGES MADE HERE WILL BE LOST! * */ - +#include +#define HAS_BOOL 1 #line 1 "Context.xs" /* * Context.xs. XS interfaces for perf script. -- 1.8.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 RESEND] pm: at91: Workaround DDRSDRC self-refresh bug with LPDDR1 memories
> -Original Message- > From: Ferre, Nicolas > Sent: Thursday, January 15, 2015 12:48 AM > To: Peter Rosin; linux-arm-ker...@lists.infradead.org; Yang, Wenyou > Cc: Peter Rosin; Andrew Victor; Jean-Christophe Plagniol-Villard; Russell > King; > linux-kernel@vger.kernel.org; Alexandre Belloni; Boris BREZILLON > Subject: Re: [PATCH RESEND] pm: at91: Workaround DDRSDRC self-refresh bug > with LPDDR1 memories > > Le 14/01/2015 14:20, Peter Rosin a écrit : > > From: Peter Rosin > > > > The DDRSDR controller (on the ATSAMA5D31) fails miserably to put > > LPDDR1 memories in self-refresh. Force the controller to think it has > > DDR2 memories during the self-refresh period, as the DDR2 self-refresh > > spec is equivalent to LPDDR1, and is correctly implemented in the > > controller. > > > > Assume that the second controller has the same fault, and that other > > CPUs in the family has the same problem, but that is untested. > > > > Signed-off-by: Peter Rosin > > I've just verified your code and the scope of this issue and your > implementation > makes perfect sense. > > Acked-by: Nicolas Ferre > > Peter, > Thanks for your patch. You will probably see it appearing in 3.20 or 3.21. > > Wenyou, > Can you please integrate the patch from Peter in your current rework of the PM > routines (keeping his authorship of course)? Of course, I will integrate. > Please tell me if I can help with this. > > Best regards, > > > > --- > > arch/arm/mach-at91/pm_slowclock.S | 43 > +++- > > include/soc/at91/at91sam9_ddrsdr.h |2 +- > > 2 files changed, 39 insertions(+), 6 deletions(-) > > > > diff --git a/arch/arm/mach-at91/pm_slowclock.S > > b/arch/arm/mach-at91/pm_slowclock.S > > index 20018779bae7..63a9e0b0a17d 100644 > > --- a/arch/arm/mach-at91/pm_slowclock.S > > +++ b/arch/arm/mach-at91/pm_slowclock.S > > @@ -143,6 +143,16 @@ ddr_sr_enable: > > cmp memctrl, #AT91_MEMCTRL_DDRSDR > > bne sdr_sr_enable > > > > + /* LPDDR1 --> force DDR2 mode during self-refresh */ > > + ldr tmp1, [sdramc, #AT91_DDRSDRC_MDR] > > + str tmp1, .saved_sam9_mdr > > + bic tmp1, tmp1, #~AT91_DDRSDRC_MD > > + cmp tmp1, #AT91_DDRSDRC_MD_LOW_POWER_DDR > > + ldreq tmp1, [sdramc, #AT91_DDRSDRC_MDR] > > + biceq tmp1, tmp1, #AT91_DDRSDRC_MD > > + orreq tmp1, tmp1, #AT91_DDRSDRC_MD_DDR2 > > + streq tmp1, [sdramc, #AT91_DDRSDRC_MDR] > > + > > /* prepare for DDRAM self-refresh mode */ > > ldr tmp1, [sdramc, #AT91_DDRSDRC_LPR] > > str tmp1, .saved_sam9_lpr > > @@ -151,14 +161,26 @@ ddr_sr_enable: > > > > /* figure out if we use the second ram controller */ > > cmp ramc1, #0 > > - ldrne tmp2, [ramc1, #AT91_DDRSDRC_LPR] > > - strne tmp2, .saved_sam9_lpr1 > > - bicne tmp2, #AT91_DDRSDRC_LPCB > > - orrne tmp2, #AT91_DDRSDRC_LPCB_SELF_REFRESH > > + beq ddr_no_2nd_ctrl > > + > > + ldr tmp2, [ramc1, #AT91_DDRSDRC_MDR] > > + str tmp2, .saved_sam9_mdr1 > > + bic tmp2, tmp2, #~AT91_DDRSDRC_MD > > + cmp tmp2, #AT91_DDRSDRC_MD_LOW_POWER_DDR > > + ldreq tmp2, [ramc1, #AT91_DDRSDRC_MDR] > > + biceq tmp2, tmp2, #AT91_DDRSDRC_MD > > + orreq tmp2, tmp2, #AT91_DDRSDRC_MD_DDR2 > > + streq tmp2, [ramc1, #AT91_DDRSDRC_MDR] > > + > > + ldr tmp2, [ramc1, #AT91_DDRSDRC_LPR] > > + str tmp2, .saved_sam9_lpr1 > > + bic tmp2, #AT91_DDRSDRC_LPCB > > + orr tmp2, #AT91_DDRSDRC_LPCB_SELF_REFRESH > > > > /* Enable DDRAM self-refresh mode */ > > + str tmp2, [ramc1, #AT91_DDRSDRC_LPR] > > +ddr_no_2nd_ctrl: > > str tmp1, [sdramc, #AT91_DDRSDRC_LPR] > > - strne tmp2, [ramc1, #AT91_DDRSDRC_LPR] > > > > b sdr_sr_done > > > > @@ -289,12 +311,17 @@ sdr_sr_done: > > */ > > cmp memctrl, #AT91_MEMCTRL_DDRSDR > > bne sdr_en_restore > > + /* Restore MDR in case of LPDDR1 */ > > + ldr tmp1, .saved_sam9_mdr > > + str tmp1, [sdramc, #AT91_DDRSDRC_MDR] > > /* Restore LPR on AT91 with DDRAM */ > > ldr tmp1, .saved_sam9_lpr > > str tmp1, [sdramc, #AT91_DDRSDRC_LPR] > > > > /* if we use the second ram controller */ > > cmp ramc1, #0 > > + ldrne tmp2, .saved_sam9_mdr1 > > + strne tmp2, [ramc1, #AT91_DDRSDRC_MDR] > > ldrne tmp2, .saved_sam9_lpr1 > > strne tmp2, [ramc1, #AT91_DDRSDRC_LPR] > > > > @@ -328,5 +355,11 @@ ram_restored: > > .saved_sam9_lpr1: > > .word 0 > > > > +.saved_sam9_mdr: > > + .word 0 > > + > > +.saved_sam9_mdr1: > > + .word 0 > > + > > ENTRY(at91_slow_clock_sz) > > .word .-at91_slow_clock > > diff --git a/include/soc/at91/at91sam9_ddrsdr.h > > b/include/soc/at91/at91sam9_ddrsdr.h > > index 0210797abf2e..cd2c18787833 100644 > > --- a/include/soc/at91/at91sam9_ddrsdr.h > > +++ b/include/soc/at91/at91sam9_ddrsdr.h > > @@ -92,7 +92,7 @@ > > #defineAT91_DDRSDRC_UPD_MR (3 << 20)/* Update > load mode register and
Re: [PATCH v8 06/10] iommu/vt-d: datatypes and functions used for kdump
Hi Baoquan,
Thank you very much for your review. But according to the latest
discussion, the page tables will not be copied from old kernel. We keep
using the old page tables before driver is loaded. So there are many
changes in next version;
See my comments.
On 01/15/2015 11:28 AM, Baoquan He wrote:
On 01/12/15 at 03:06pm, Li, Zhen-Hua wrote:
+/*
+ * Interface to the "copy translation tables" set of functions
+ * from mainline code.
+ */
+static int intel_iommu_load_translation_tables(struct dmar_drhd_unit *drhd,
+ int g_num_of_iommus)
The argument g_num_of_iommus is the same as the global variable, it's better
to rename it as num_of_iommus. And even it can be removed since you can
just use the global variable g_num_of_iommus in this function.
Argument drhd can be intel_iommu because no other member variable in
drhd is needed.
This function is no longer used. So forget the parameters.
+{
+ struct intel_iommu *iommu; /* Virt(iommu hardware registers) */
+ unsigned long long q; /* quadword scratch */
+ int ret = 0;/* Integer return code */
+ int i = 0; /* Loop index */
+ unsigned long flags;
+
+ /* Structure so copy_page_addr() can accumulate things
+* over multiple calls and returns
+*/
+ struct copy_page_addr_parms ppa_parms = copy_page_addr_parms_init;
+ struct copy_page_addr_parms *ppap = _parms;
+
+
+ iommu = drhd->iommu;
+ q = dmar_readq(iommu->reg + DMAR_RTADDR_REG);
+ if (!q)
+ return -1;
+
+ /* If (list needs initializing) do it here */
This initializing should not be here, because it's not only for this
drhd. It should be done in init_dmars().
Yes you are right. Though the variable domain_values_list will not be
used in next version, I think I need to check if there are any other
similar problems.
+ if (!domain_values_list) {
+ domain_values_list =
+kcalloc(g_num_of_iommus, sizeof(struct list_head),
+ GFP_KERNEL);
+
+ if (!domain_values_list) {
+ pr_err("Allocation failed for domain_values_list
array\n");
+ return -ENOMEM;
+ }
+ for (i = 0; i < g_num_of_iommus; i++)
+ INIT_LIST_HEAD(_values_list[i]);
+ }
+
+ spin_lock_irqsave(>lock, flags);
+
+ /* Load the root-entry table from the old kernel
+* foreach context_entry_table in root_entry
+*foreach context_entry in context_entry_table
+* foreach level-1 page_table_entry in context_entry
+* foreach level-2 page_table_entry in level 1 page_table_entry
+* Above pattern continues up to 6 levels of page tables
+*Sanity-check the entry
+*Process the bus, devfn, page_address, page_size
+*/
+ if (!iommu->root_entry) {
+ iommu->root_entry =
+ (struct root_entry *)alloc_pgtable_page(iommu->node);
+ if (!iommu->root_entry) {
+ spin_unlock_irqrestore(>lock, flags);
+ return -ENOMEM;
+ }
+ }
+
+ iommu->root_entry_old_phys = q & VTD_PAGE_MASK;
+ if (!iommu->root_entry_old_phys) {
+ pr_err("Could not read old root entry address.");
+ return -1;
+ }
+
+ iommu->root_entry_old_virt = ioremap_cache(iommu->root_entry_old_phys,
+ VTD_PAGE_SIZE);
+ if (!iommu->root_entry_old_virt) {
+ pr_err("Could not map the old root entry.");
+ return -ENOMEM;
+ }
+
+ __iommu_load_old_root_entry(iommu);
+ ret = copy_root_entry_table(iommu, ppap);
+ __iommu_flush_cache(iommu, iommu->root_entry, PAGE_SIZE);
+ __iommu_update_old_root_entry(iommu, -1);
+
+ spin_unlock_irqrestore(>lock, flags);
+
+ __iommu_free_mapped_mem();
+
+ if (ret)
+ return ret;
+
+ ppa_parms.last = 1;
+ copy_page_addr(0, 0, 0, 0, 0, NULL, ppap);
+
+ return 0;
+}
+
#endif /* CONFIG_CRASH_DUMP */
--
2.0.0-rc0
___
kexec mailing list
ke...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver
On 15-01-14 05:02 PM, Dmitry Torokhov wrote:
Hi Jonathan,
On Fri, Dec 19, 2014 at 02:17:49PM -0800, Jonathan Richardson wrote:
+ if (of_property_read_u32(np, "scanning_period", ) >= 0) {
+ if (val < 1 || val > 256) {
+ dev_err(dev, "scanning_period must be [1-256]\n");
+ return -EINVAL;
+ }
+ priv->cfg_params.scanning_period = val;
+ }
+
+ if (of_property_read_u32(np, "debounce_timeout", ) >= 0) {
+ if (val < 0 || val > 255) {
+ dev_err(dev, "debounce_timeout must be [0-255]\n");
+ return -EINVAL;
+ }
+ priv->cfg_params.debounce_timeout = val;
+ }
+
+ if (of_property_read_u32(np, "settling_timeout", ) >= 0) {
+ if (val < 0 || val > 11) {
+ dev_err(dev, "settling_timeout must be [0-11]\n");
+ return -EINVAL;
+ }
+ priv->cfg_params.settling_timeout = val;
+ }
+
+ if (of_property_read_u32(np, "touch_timeout", ) >= 0) {
+ if (val < 0 || val > 255) {
+ dev_err(dev, "touch_timeout must be [0-255]\n");
+ return -EINVAL;
+ }
+ priv->cfg_params.touch_timeout = val;
+ }
+
+ if (of_property_read_u32(np, "average_data", ) >= 0) {
+ if (val < 0 || val > 8) {
+ dev_err(dev, "average_data must be [0-8]\n");
+ return -EINVAL;
+ }
+ priv->cfg_params.average_data = val;
+ }
+
+ if (of_property_read_u32(np, "fifo_threshold", ) >= 0) {
+ if (val < 0 || val > 31) {
+ dev_err(dev, "fifo_threshold must be [0-31]\n");
+ return -EINVAL;
+ }
+ priv->cfg_params.fifo_threshold = val;
+ }
I think these are dveice specific and thus should have "brcm," prefix.
I'm confused as to why we need the brcm prefix? Other device tree
bindings we have for other drivers do not need such prefix. Is this
convention documented somewhere?
+
+ priv->ts_rotation = TS_ROTATION_0;
+ if (of_property_read_u32(np, "ts-rotation", ) >= 0) {
+ priv->ts_rotation = val;
+ dev_dbg(dev, "ts rotation [%d] degrees\n",
+ 90 * priv->ts_rotation);
+ }
This I am not quite sure about - if we want rotation or swap+invert. You
are CCed on another email (tsc2007) that talks about need of generic
touchscreen transforms in input core/of bindings.
Does such generic binding exist today? If not, I would like to go with
this implementation and update to the new binding if/when it exists?
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] staging: lustre: lnet: lnet: trailing statements should be on next line
This patch fixes the checkpatch.pl issue
Error: trailing statements should be on next line
Signed-off-by: Balavasu
---
drivers/staging/lustre/lnet/lnet/router.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lnet/lnet/router.c
b/drivers/staging/lustre/lnet/lnet/router.c
index cdeb246..0f569a0 100644
--- a/drivers/staging/lustre/lnet/lnet/router.c
+++ b/drivers/staging/lustre/lnet/lnet/router.c
@@ -1670,13 +1670,16 @@ lnet_get_tunables (void)
char *s;
s = getenv("LNET_ROUTER_PING_TIMEOUT");
- if (s != NULL) router_ping_timeout = atoi(s);
+ if (s != NULL)
+ router_ping_timeout = atoi(s);
s = getenv("LNET_LIVE_ROUTER_CHECK_INTERVAL");
- if (s != NULL) live_router_check_interval = atoi(s);
+ if (s != NULL)
+ live_router_check_interval = atoi(s);
s = getenv("LNET_DEAD_ROUTER_CHECK_INTERVAL");
- if (s != NULL) dead_router_check_interval = atoi(s);
+ if (s != NULL)
+ dead_router_check_interval = atoi(s);
/* This replaces old lnd_notify mechanism */
check_routers_before_use = 1;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] blk-mq: cleanup additional nr_hw_queues check
No need to check set->nr_hw_queues twice in blk_mq_alloc_tag_set(),
remove the latter one.
Signed-off-by: hujianyang
---
block/blk-mq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index a7d4a98..eddeccc 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2097,7 +2097,7 @@ int blk_mq_alloc_tag_set(struct blk_mq_tag_set *set)
if (set->queue_depth < set->reserved_tags + BLK_MQ_TAG_MIN)
return -EINVAL;
- if (!set->nr_hw_queues || !set->ops->queue_rq || !set->ops->map_queue)
+ if (!set->ops->queue_rq || !set->ops->map_queue)
return -EINVAL;
if (set->queue_depth > BLK_MQ_MAX_DEPTH) {
--
1.6.0.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 3.18 000/150] 3.18.3-stable review
On Wed, Jan 14, 2015 at 08:48:43PM -0800, Guenter Roeck wrote: > On 01/13/2015 11:21 PM, Greg Kroah-Hartman wrote: > >This is the start of the stable review cycle for the 3.18.3 release. > >There are 150 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 Fri Jan 16 07:20:24 UTC 2015. > >Anything received after that time might be too late. > > > > Update: Tests still pass after you dropped a patch. Great, thanks for testing all of these and letting me know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RESEND 2] Revert "AUDIT: Allow login in non-init namespaces"
On Friday 01/09 at 16:36 -0500, Paul Moore wrote: > On Friday, January 09, 2015 01:24:51 PM Calvin Owens wrote: > > On Friday 01/09 at 15:33 -0500, Paul Moore wrote: > > > While I haven't had reason to test this code lately, last I knew it was > > > working, what problems are you seeing Calvin? Also, with what > > > distribution? > > > > An SSH authentication setup in LXC containers on CentOS broke with the > > original patch. My revert made it work again. I can dig up more detail > > about the specific setup if you're interested. > > Yes, please. I believe it is the little details that are important for this > issue. Just drop this patch, I goofed up. Sorry for the noise. (543bc6a1a987 was mistakingly applied to a kernel build without the supporting patches mentioned in the commit message. It was stupid of me not to check for that before bothering you...) Thanks very much, Calvin > -- > paul moore > www.paul-moore.com > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] ARC: Dynamically determine BASE_BAUD from DeviceTree
On Thu, Jan 15, 2015 at 09:49:12AM +0530, Vineet Gupta wrote: > Hi Greg, > > On Saturday 10 January 2015 04:56 PM, Vineet Gupta wrote: > > 8250 earlycon is broken on multi-platform ARC because the UART clk > > value (BASE_BAUD) is fixed at build time. > > > > Instead, determine the appropriate UART clk at runtime; parse the > > devicetree early for platforms requiring alternate UART clk values > > (currently only the TB10X platform). > > > > Cc: Greg Kroah-Hartman > > Cc: Jiri Slaby > > Cc: linux-ser...@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > Cc: Rob Herring > > Cc: Arnd Bergmann > > Reviewed-by: Peter Hurley > > Signed-off-by: Vineet Gupta > > --- > > arch/arc/include/asm/serial.h | 23 +-- > > arch/arc/kernel/devtree.c | 24 > > This being all in arch code, do you want me to take this in via ARC tree ? Sure, that's fine with me: Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.18 000/150] 3.18.3-stable review
On 01/13/2015 11:21 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.3 release. There are 150 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 Fri Jan 16 07:20:24 UTC 2015. Anything received after that time might be too late. Update: Tests still pass after you dropped a patch. 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 04/10] PCI, frv: clip firmware assigned resource under parent bridge's
On Wed, Jan 14, 2015 at 8:31 PM, Yinghai Lu wrote:
> Some bios put range that is not fully coverred by root bus resources.
> Try to clip them and update them in pci bridge bars.
>
> We'd like to fix other arches instead of just x86.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
> Reported-by: Marek Kordik
> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
> 64-bit resources")
> Signed-off-by: Yinghai Lu
> Cc: David Howells
> Cc: Paul Gortmaker
> ---
> arch/frv/mb93090-mb00/pci-frv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/frv/mb93090-mb00/pci-frv.c b/arch/frv/mb93090-mb00/pci-frv.c
> index 67b1d16..9e49c3e 100644
> --- a/arch/frv/mb93090-mb00/pci-frv.c
> +++ b/arch/frv/mb93090-mb00/pci-frv.c
> @@ -94,7 +94,7 @@ static void __init pcibios_allocate_bus_resources(struct
> list_head *bus_list)
> r = >resource[idx];
> if (!r->start)
> continue;
> - pci_claim_resource(dev, idx);
> + pci_claim_bridge_resource(dev, idx)
miss ; here.
Please let me know if you can fix it manually.
Sorry about that.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/77] 3.14.29-stable review
On 01/13/2015 11:22 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.29 release. There are 77 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 Fri Jan 16 07:22:07 UTC 2015. Anything received after that time might be too late. Build results: total: 137 pass: 137 fail: 0 Qemu tests: total: 30 pass: 30 fail: 0 This is with the latest version, after dropping the patch causing the powerpc build and qemu failures. 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: [alsa-devel] unload Audio drivers while playback stream is active case kernel crash
Hi On 01/14/2015 10:43 PM, Fabio Estevam wrote: On Wed, Jan 14, 2015 at 10:57 AM, Lars-Peter Clausen wrote: My personal opinion on this is that disallowing module removal while a driver registered by the module when is in use, while there is no technical reason to do so, is a anti-feature. Whether in ALSA or elsewhere. But looking at the source it seems that this is a core feature of ALSA and at least for the card module itself it will do the ref-counting when a stream is started/stopped. And we even support setting the owner of a card in ASoC. It's just that pretty much no ASoC card driver bothers to set the owner field in the snd_soc_card struct. So this particular problem can be fixed by updating the imx-wm8962 driver to set the owner field. Thanks, Lars_Peter. This fixes the issue: root@freescale /$ modprobe -r snd_soc_imx_wm8962 modprobe: can't unload module snd_soc_imx_wm8962: Resource temporarily unavailable Will send a patch with your suggestion soon. I think by set owner field in imx_wm8962 machine driver can fix the crash I saw on sabreSD board, but as this is a generic issue which I suppose should exist on other boards with different machine drivers. Can we have a more generic fix to this issue? Or shall we set owner field for all machine drivers? Thanks, Jiada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 09/10] PCI, powerpc: clip firmware assigned resource under parent bridge's
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources")
Signed-off-by: Yinghai Lu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Gavin Shan
Cc: Anton Blanchard
Cc: Sebastian Ott
Cc: Wei Yang
Cc: Andrew Murray
Cc: linuxppc-...@lists.ozlabs.org
---
arch/powerpc/kernel/pci-common.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 37d512d..2a525c9 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1184,6 +1184,8 @@ static void pcibios_allocate_bus_resources(struct pci_bus
*bus)
pr, (pr && pr->name) ? pr->name : "nil");
if (pr && !(pr->flags & IORESOURCE_UNSET)) {
+ struct pci_dev *dev = bus->self;
+
if (request_resource(pr, res) == 0)
continue;
/*
@@ -1193,6 +1195,11 @@ static void pcibios_allocate_bus_resources(struct
pci_bus *bus)
*/
if (reparent_resources(pr, res) == 0)
continue;
+
+ if (dev && i < PCI_BRIDGE_RESOURCE_NUM &&
+ pci_claim_bridge_resource(dev,
+ i + PCI_BRIDGE_RESOURCES) == 0)
+ continue;
}
pr_warning("PCI: Cannot allocate resource region "
"%d of PCI bridge %d, will remap\n", i, bus->number);
@@ -1401,7 +1408,10 @@ void pcibios_claim_one_bus(struct pci_bus *bus)
(unsigned long long)r->end,
(unsigned int)r->flags);
- pci_claim_resource(dev, i);
+ if (pci_claim_resource(dev, i) == 0)
+ continue;
+
+ pci_claim_bridge_resource(dev, i);
}
}
--
1.8.4.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 05/10] PCI, ia64: clip firmware assigned resource under parent bridge's
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources")
Signed-off-by: Yinghai Lu
Cc: Tony Luck
Cc: Fenghua Yu
Cc: "Rafael J. Wysocki"
Cc: linux-i...@vger.kernel.org
---
arch/ia64/pci/pci.c | 48 +---
1 file changed, 21 insertions(+), 27 deletions(-)
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 291a582..900cc93 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -487,45 +487,39 @@ int pcibios_root_bridge_prepare(struct pci_host_bridge
*bridge)
return 0;
}
-static int is_valid_resource(struct pci_dev *dev, int idx)
+void pcibios_fixup_device_resources(struct pci_dev *dev)
{
- unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
- struct resource *devr = >resource[idx], *busr;
+ int idx;
if (!dev->bus)
- return 0;
-
- pci_bus_for_each_resource(dev->bus, busr, i) {
- if (!busr || ((busr->flags ^ devr->flags) & type_mask))
- continue;
- if ((devr->start) && (devr->start >= busr->start) &&
- (devr->end <= busr->end))
- return 1;
- }
- return 0;
-}
+ return;
-static void pcibios_fixup_resources(struct pci_dev *dev, int start, int limit)
-{
- int i;
+ for (idx = 0; idx < PCI_BRIDGE_RESOURCES; idx++) {
+ struct resource *r = >resource[idx];
- for (i = start; i < limit; i++) {
- if (!dev->resource[i].flags)
+ if (!r->flags || r->parent || !r->start)
continue;
- if ((is_valid_resource(dev, i)))
- pci_claim_resource(dev, i);
- }
-}
-void pcibios_fixup_device_resources(struct pci_dev *dev)
-{
- pcibios_fixup_resources(dev, 0, PCI_BRIDGE_RESOURCES);
+ pci_claim_resource(dev, idx);
+ }
}
EXPORT_SYMBOL_GPL(pcibios_fixup_device_resources);
static void pcibios_fixup_bridge_resources(struct pci_dev *dev)
{
- pcibios_fixup_resources(dev, PCI_BRIDGE_RESOURCES, PCI_NUM_RESOURCES);
+ int idx;
+
+ if (!dev->bus)
+ return;
+
+ for (idx = PCI_BRIDGE_RESOURCES; idx < PCI_NUM_RESOURCES; idx++) {
+ struct resource *r = >resource[idx];
+
+ if (!r->flags || r->parent || !r->start)
+ continue;
+
+ pci_claim_bridge_resource(dev, idx);
+ }
}
/*
--
1.8.4.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 03/10] PCI, alpha: clip firmware assigned resource under parent bridge's
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources")
Signed-off-by: Yinghai Lu
Cc: Richard Henderson
Cc: Ivan Kokshaysky
Cc: Matt Turner
Cc: linux-al...@vger.kernel.org
---
arch/alpha/kernel/pci.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 076c35c..98a1525 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -285,8 +285,12 @@ pcibios_claim_one_bus(struct pci_bus *b)
if (r->parent || !r->start || !r->flags)
continue;
if (pci_has_flag(PCI_PROBE_ONLY) ||
- (r->flags & IORESOURCE_PCI_FIXED))
- pci_claim_resource(dev, i);
+ (r->flags & IORESOURCE_PCI_FIXED)) {
+ if (pci_claim_resource(dev, i) == 0)
+ continue;
+
+ pci_claim_bridge_resource(dev, i);
+ }
}
}
--
1.8.4.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 02/10] PCI, x86: clip firmware assigned resource under parent bridge's
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Tested-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources")
Signed-off-by: Yinghai Lu
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
---
arch/x86/pci/i386.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index 9b18ef3..349c0d3 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -216,7 +216,7 @@ static void pcibios_allocate_bridge_resources(struct
pci_dev *dev)
continue;
if (r->parent) /* Already allocated */
continue;
- if (!r->start || pci_claim_resource(dev, idx) < 0) {
+ if (!r->start || pci_claim_bridge_resource(dev, idx) < 0) {
/*
* Something is wrong with the region.
* Invalidate the resource to prevent
--
1.8.4.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 10/10] PCI, sparc: clip firmware assigned resource under parent bridge's
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources")
Signed-off-by: Yinghai Lu
Cc: "David S. Miller"
Cc: Paul Gortmaker
Cc: Yijing Wang
Cc: Sam Ravnborg
Cc: sparcli...@vger.kernel.org
---
arch/sparc/kernel/pci.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index b36365f..9ce5afe 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -639,7 +639,10 @@ static void pci_claim_bus_resources(struct pci_bus *bus)
(unsigned long long)r->end,
(unsigned int)r->flags);
- pci_claim_resource(dev, i);
+ if (pci_claim_resource(dev, i) == 0)
+ continue;
+
+ pci_claim_bridge_resource(dev, i);
}
}
--
1.8.4.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 08/10] PCI, parisc: clip firmware assigned resource under parent bridge's
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources")
Signed-off-by: Yinghai Lu
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: linux-par...@vger.kernel.org
---
drivers/parisc/lba_pci.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/parisc/lba_pci.c b/drivers/parisc/lba_pci.c
index 37e71ff..dceb9dd 100644
--- a/drivers/parisc/lba_pci.c
+++ b/drivers/parisc/lba_pci.c
@@ -694,9 +694,8 @@ lba_fixup_bus(struct pci_bus *bus)
int i;
/* PCI-PCI Bridge */
pci_read_bridge_bases(bus);
- for (i = PCI_BRIDGE_RESOURCES; i < PCI_NUM_RESOURCES; i++) {
- pci_claim_resource(bus->self, i);
- }
+ for (i = PCI_BRIDGE_RESOURCES; i < PCI_NUM_RESOURCES; i++)
+ pci_claim_bridge_resource(bus->self, i);
} else {
/* Host-PCI Bridge */
int err;
--
1.8.4.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 06/10] PCI, microblaze: clip firmware assigned resource under parent bridge's
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources")
Signed-off-by: Yinghai Lu
Cc: Michal Simek
Cc: Benjamin Herrenschmidt
Cc: Sebastian Ott
---
arch/microblaze/pci/pci-common.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index b30e41c..48528fb 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -1026,6 +1026,8 @@ static void pcibios_allocate_bus_resources(struct pci_bus
*bus)
pr, (pr && pr->name) ? pr->name : "nil");
if (pr && !(pr->flags & IORESOURCE_UNSET)) {
+ struct pci_dev *dev = bus->self;
+
if (request_resource(pr, res) == 0)
continue;
/*
@@ -1035,6 +1037,12 @@ static void pcibios_allocate_bus_resources(struct
pci_bus *bus)
*/
if (reparent_resources(pr, res) == 0)
continue;
+
+ if (dev && i < PCI_BRIDGE_RESOURCE_NUM &&
+ pci_claim_bridge_resource(dev,
+i + PCI_BRIDGE_RESOURCES) == 0)
+ continue;
+
}
pr_warn("PCI: Cannot allocate resource region ");
pr_cont("%d of PCI bridge %d, will remap\n", i, bus->number);
@@ -1227,7 +1235,10 @@ void pcibios_claim_one_bus(struct pci_bus *bus)
(unsigned long long)r->end,
(unsigned int)r->flags);
- pci_claim_resource(dev, i);
+ if (pci_claim_resource(dev, i) == 0)
+ continue;
+
+ pci_claim_bridge_resource(dev, i);
}
}
--
1.8.4.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 07/10] PCI, mn10300: clip firmware assigned resource under parent bridge's
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources")
Signed-off-by: Yinghai Lu
Cc: David Howells
Cc: Koichi Yasutake
Cc: linux-am33-l...@redhat.com
---
arch/mn10300/unit-asb2305/pci-asb2305.c | 2 +-
arch/mn10300/unit-asb2305/pci.c | 47 +++--
2 files changed, 22 insertions(+), 27 deletions(-)
diff --git a/arch/mn10300/unit-asb2305/pci-asb2305.c
b/arch/mn10300/unit-asb2305/pci-asb2305.c
index febb9cd..b5b036f 100644
--- a/arch/mn10300/unit-asb2305/pci-asb2305.c
+++ b/arch/mn10300/unit-asb2305/pci-asb2305.c
@@ -106,7 +106,7 @@ static void __init pcibios_allocate_bus_resources(struct
list_head *bus_list)
if (!r->flags)
continue;
if (!r->start ||
- pci_claim_resource(dev, idx) < 0) {
+ pci_claim_bridge_resource(dev, idx) < 0) {
printk(KERN_ERR "PCI:"
" Cannot allocate resource"
" region %d of bridge %s\n",
diff --git a/arch/mn10300/unit-asb2305/pci.c b/arch/mn10300/unit-asb2305/pci.c
index 6b4339f..471ff39 100644
--- a/arch/mn10300/unit-asb2305/pci.c
+++ b/arch/mn10300/unit-asb2305/pci.c
@@ -281,42 +281,37 @@ static int __init pci_check_direct(void)
return -ENODEV;
}
-static int is_valid_resource(struct pci_dev *dev, int idx)
+static void pcibios_fixup_device_resources(struct pci_dev *dev)
{
- unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
- struct resource *devr = >resource[idx], *busr;
-
- if (dev->bus) {
- pci_bus_for_each_resource(dev->bus, busr, i) {
- if (!busr || (busr->flags ^ devr->flags) & type_mask)
- continue;
-
- if (devr->start &&
- devr->start >= busr->start &&
- devr->end <= busr->end)
- return 1;
- }
- }
+ int idx;
- return 0;
+ if (!dev->bus)
+ return;
+
+ for (idx = 0; idx < PCI_BRIDGE_RESOURCES; idx++) {
+ struct resource *r = >resource[idx];
+
+ if (!r->flags || r->parent || !r->start)
+ continue;
+
+ pci_claim_resource(dev, idx);
+ }
}
-static void pcibios_fixup_device_resources(struct pci_dev *dev)
+static void pcibios_fixup_bridge_resources(struct pci_dev *dev)
{
- int limit, i;
+ int idx;
- if (dev->bus->number != 0)
+ if (!dev->bus)
return;
- limit = (dev->hdr_type == PCI_HEADER_TYPE_NORMAL) ?
- PCI_BRIDGE_RESOURCES : PCI_NUM_RESOURCES;
+ for (idx = PCI_BRIDGE_RESOURCES; idx < PCI_NUM_RESOURCES; idx++) {
+ struct resource *r = >resource[idx];
- for (i = 0; i < limit; i++) {
- if (!dev->resource[i].flags)
+ if (!r->flags || r->parent || !r->start)
continue;
- if (is_valid_resource(dev, i))
- pci_claim_resource(dev, i);
+ pci_claim_bridge_resource(dev, idx);
}
}
@@ -330,7 +325,7 @@ void pcibios_fixup_bus(struct pci_bus *bus)
if (bus->self) {
pci_read_bridge_bases(bus);
- pcibios_fixup_device_resources(bus->self);
+ pcibios_fixup_bridge_resources(bus->self);
}
list_for_each_entry(dev, >devices, bus_list)
--
1.8.4.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 04/10] PCI, frv: clip firmware assigned resource under parent bridge's
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources")
Signed-off-by: Yinghai Lu
Cc: David Howells
Cc: Paul Gortmaker
---
arch/frv/mb93090-mb00/pci-frv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/frv/mb93090-mb00/pci-frv.c b/arch/frv/mb93090-mb00/pci-frv.c
index 67b1d16..9e49c3e 100644
--- a/arch/frv/mb93090-mb00/pci-frv.c
+++ b/arch/frv/mb93090-mb00/pci-frv.c
@@ -94,7 +94,7 @@ static void __init pcibios_allocate_bus_resources(struct
list_head *bus_list)
r = >resource[idx];
if (!r->start)
continue;
- pci_claim_resource(dev, idx);
+ pci_claim_bridge_resource(dev, idx)
}
}
pcibios_allocate_bus_resources(>children);
--
1.8.4.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 00/10] PCI: clip firmware assigned resources
During the fix https://bugzilla.kernel.org/show_bug.cgi?id=85491, Bjorn suggest that we should clip the resources instead of just reject them. We should only need first two for x86. others for related arches to keep them consistent. -v2: only handle bridge resource, and add pci_claim_bridge_resource in pci core code. Thanks Yinghai Yinghai Lu (10): PCI: clip firmware assigned resource under parent bridge's PCI, x86: clip firmware assigned resource under parent bridge's PCI, alpha: clip firmware assigned resource under parent bridge's PCI, frv: clip firmware assigned resource under parent bridge's PCI, ia64: clip firmware assigned resource under parent bridge's PCI, microblaze: clip firmware assigned resource under parent bridge's PCI, mn10300: clip firmware assigned resource under parent bridge's PCI, parisc: clip firmware assigned resource under parent bridge's PCI, powerpc: clip firmware assigned resource under parent bridge's PCI, sparc: clip firmware assigned resource under parent bridge's arch/alpha/kernel/pci.c | 8 +++-- arch/frv/mb93090-mb00/pci-frv.c | 2 +- arch/ia64/pci/pci.c | 48 +--- arch/microblaze/pci/pci-common.c| 13 +++- arch/mn10300/unit-asb2305/pci-asb2305.c | 2 +- arch/mn10300/unit-asb2305/pci.c | 47 +-- arch/powerpc/kernel/pci-common.c| 12 ++- arch/sparc/kernel/pci.c | 5 ++- arch/x86/pci/i386.c | 2 +- drivers/parisc/lba_pci.c| 5 ++- drivers/pci/bus.c | 39 +++ drivers/pci/pci.h | 1 + drivers/pci/setup-bus.c | 56 ++--- include/linux/pci.h | 1 + 14 files changed, 165 insertions(+), 76 deletions(-) -- 1.8.4.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 01/10] PCI: clip firmware assigned resource under parent bridge's
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
This one is core part, arch changes will be in following patches.
-v2: add pci_claim_bridge_resource to core according to Bjorn.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources")
Signed-off-by: Yinghai Lu
---
drivers/pci/bus.c | 39 ++
drivers/pci/pci.h | 1 +
drivers/pci/setup-bus.c | 56 ++---
include/linux/pci.h | 1 +
4 files changed, 85 insertions(+), 12 deletions(-)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 73aef51..a1943c3 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -228,6 +228,45 @@ int pci_bus_alloc_resource(struct pci_bus *bus, struct
resource *res,
}
EXPORT_SYMBOL(pci_bus_alloc_resource);
+bool pci_bus_clip_resource(struct pci_dev *dev, int idx)
+{
+ struct pci_bus *bus = dev->bus;
+ struct resource *res = >resource[idx];
+ struct resource orig_res = *res;
+ struct resource *r;
+ int i;
+
+ pci_bus_for_each_resource(bus, r, i) {
+ resource_size_t start, end;
+
+ if (!r)
+ continue;
+
+ if (resource_type(res) != resource_type(r))
+ continue;
+
+ start = max(r->start, res->start);
+ end = min(r->end, res->end);
+
+ /* no overlap ? */
+ if (start > end)
+ continue;
+
+ if (res->start == start && res->end == end)
+ return false;
+
+ /* changed */
+ res->start = start;
+ res->end = end;
+ dev_printk(KERN_DEBUG, >dev, "%pR ==> %pR\n",
+_res, res);
+
+ return true;
+ }
+
+ return false;
+}
+
void __weak pcibios_resource_survey_bus(struct pci_bus *bus) { }
/**
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 8aff29a..d54632a 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -208,6 +208,7 @@ void __pci_bus_size_bridges(struct pci_bus *bus,
void __pci_bus_assign_resources(const struct pci_bus *bus,
struct list_head *realloc_head,
struct list_head *fail_head);
+bool pci_bus_clip_resource(struct pci_dev *dev, int idx);
/**
* pci_ari_enabled - query ARI forwarding status
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 0482235..0b1b9ea 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -530,9 +530,8 @@ EXPORT_SYMBOL(pci_setup_cardbus);
config space writes, so it's quite possible that an I/O window of
the bridge will have some undesirable address (e.g. 0) after the
first write. Ditto 64-bit prefetchable MMIO. */
-static void pci_setup_bridge_io(struct pci_bus *bus)
+static void pci_setup_bridge_io(struct pci_dev *bridge)
{
- struct pci_dev *bridge = bus->self;
struct resource *res;
struct pci_bus_region region;
unsigned long io_mask;
@@ -545,7 +544,7 @@ static void pci_setup_bridge_io(struct pci_bus *bus)
io_mask = PCI_IO_1K_RANGE_MASK;
/* Set up the top and bottom of the PCI I/O segment for this bus. */
- res = bus->resource[0];
+ res = >resource[PCI_BRIDGE_RESOURCES];
pcibios_resource_to_bus(bridge->bus, , res);
if (res->flags & IORESOURCE_IO) {
pci_read_config_word(bridge, PCI_IO_BASE, );
@@ -568,15 +567,14 @@ static void pci_setup_bridge_io(struct pci_bus *bus)
pci_write_config_dword(bridge, PCI_IO_BASE_UPPER16, io_upper16);
}
-static void pci_setup_bridge_mmio(struct pci_bus *bus)
+static void pci_setup_bridge_mmio(struct pci_dev *bridge)
{
- struct pci_dev *bridge = bus->self;
struct resource *res;
struct pci_bus_region region;
u32 l;
/* Set up the top and bottom of the PCI Memory segment for this bus. */
- res = bus->resource[1];
+ res = >resource[PCI_BRIDGE_RESOURCES + 1];
pcibios_resource_to_bus(bridge->bus, , res);
if (res->flags & IORESOURCE_MEM) {
l = (region.start >> 16) & 0xfff0;
@@ -588,9 +586,8 @@ static void pci_setup_bridge_mmio(struct pci_bus *bus)
pci_write_config_dword(bridge, PCI_MEMORY_BASE, l);
}
-static void pci_setup_bridge_mmio_pref(struct pci_bus *bus)
+static void pci_setup_bridge_mmio_pref(struct pci_dev *bridge)
{
- struct pci_dev *bridge = bus->self;
struct resource *res;
struct pci_bus_region region;
u32 l, bu, lu;
@@ -602,7 +599,7 @@ static void pci_setup_bridge_mmio_pref(struct pci_bus *bus)
/* Set up PREF base/limit. */
bu = lu = 0;
- res =
Re: [PATCH] pseries/le: Fix endiannes issue in RTAS call from xmon
On Mon, 2014-11-24 at 15:07 +0100, Laurent Dufour wrote:
> On pseries system (LPAR) xmon failed to enter when running in LE mode, system
> is hunging. Inititating xmon will lead to such an output on the console:
>
> SysRq : Entering xmon
> cpu 0x15: Vector: 0 at [c003f39ffb10]
> pc: c007ed7c: sysrq_handle_xmon+0x5c/0x70
> lr: c007ed7c: sysrq_handle_xmon+0x5c/0x70
> sp: c003f39ffc70
>msr: 80009033
> current = 0xc003fafa7180
> paca= 0xc7d75e80 softe: 0irq_happened: 0x01
> pid = 14617, comm = bash
> Bad kernel stack pointer fafb4b0 at eca7cc4
> cpu 0x15: Vector: 300 (Data Access) at [c7f07d40]
> pc: 0eca7cc4
> lr: 0eca7c44
> sp: fafb4b0
>msr: 80001000
>dar: 1000
> dsisr: 4200
> current = 0xc003fafa7180
> paca= 0xc7d75e80 softe: 0irq_happened: 0x01
> pid = 14617, comm = bash
> cpu 0x15: Exception 300 (Data Access) in xmon, returning to main loop
> xmon: WARNING: bad recursive fault on cpu 0x15
>
> The root cause is that xmon is calling RTAS to turn off the surveillance
> when entering xmon, and RTAS is requiring big endian parameters.
>
> This patch is byte swapping the RTAS arguments when running in LE mode.
>
> Signed-off-by: Laurent Dufour
> ---
> arch/powerpc/xmon/xmon.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index b988b5addf86..c8efbb37d6e0 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -293,10 +293,10 @@ static inline void disable_surveillance(void)
> args.token = rtas_token("set-indicator");
> if (args.token == RTAS_UNKNOWN_SERVICE)
> return;
I just noticed we're not handling the token correctly here. It is be32 also.
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARC: Dynamically determine BASE_BAUD from DeviceTree
Hi Greg, On Saturday 10 January 2015 04:56 PM, Vineet Gupta wrote: > 8250 earlycon is broken on multi-platform ARC because the UART clk > value (BASE_BAUD) is fixed at build time. > > Instead, determine the appropriate UART clk at runtime; parse the > devicetree early for platforms requiring alternate UART clk values > (currently only the TB10X platform). > > Cc: Greg Kroah-Hartman > Cc: Jiri Slaby > Cc: linux-ser...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: Rob Herring > Cc: Arnd Bergmann > Reviewed-by: Peter Hurley > Signed-off-by: Vineet Gupta > --- > arch/arc/include/asm/serial.h | 23 +-- > arch/arc/kernel/devtree.c | 24 This being all in arch code, do you want me to take this in via ARC tree ? Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 2/2] ftrace/jprobes/x86: Have function being probed be graph traced
From: "Steven Rostedt (Red Hat)"
Because jprobes replaces the stack frame to call the jprobe handler with
the function arguments, if kprobes/jprobes uses ftrace (fentry)
infrastructure for its implementation, it messes with the tracing of
the function graph tracer.
The jprobe gets set up from the ftrace fentry trampoline and it
changes the regs->ip from the called function to call the jprobe
handler. The function graph tracing happens after the function
tracing and the function graph will see the jprobe ip address
instead of the function that was called. If the functions were
filtered, the jprobe ip address would not match what it expected
to see, and the graph tracer will not trace the function.
Add a new trampoline called ftrace_trace_addr that jprobes always
calls if the jprobe itself was not traced, and kprobes uses the
ftrace (fentry) infrastructure. The ftrace_trace_addr will reset
the ip address with the function that was probed and recall the
ftrace_graph_caller.
In case the jprobe itself was traced, the fixup_jprobe will call
ftrace_graph_caller.
Cc: Masami Hiramatsu
Signed-off-by: Steven Rostedt
---
arch/x86/include/asm/ftrace.h| 1 +
arch/x86/kernel/kprobes/core.c | 33 -
arch/x86/kernel/kprobes/ftrace.c | 4 +++-
arch/x86/kernel/mcount_64.S | 14 +-
4 files changed, 37 insertions(+), 15 deletions(-)
diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index bfabbb44797f..d725c816ea05 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -37,6 +37,7 @@ int ftrace_int3_handler(struct pt_regs *regs);
/* Used to keep jprobes from messing with function graph tracing */
void fixup_jprobe(void);
+void ftrace_trace_addr(void);
#define FTRACE_GRAPH_TRAMP_ADDR FTRACE_GRAPH_ADDR
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 971c3803f283..fd6d91a85e3b 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -1098,6 +1098,22 @@ int longjmp_break_handler(struct kprobe *p, struct
pt_regs *regs)
*/
#ifdef ALLOW_JPROBE_GRAPH_TRACER
/*
+* Since we are not returning back to the function
+* that was probed, the fixup_jprobe and ftrace_trace_addr
+* needs a way to know what to jump back to. Store that in the
+* r10 register, which callee functions are allowed
+* to clobber. Since r10 can be clobbered by the callee,
+* the caller must save it if necessary. As the callee
+* (probed function) has not been executed yet, the
+* value for r10 currently is not important.
+*
+* Note, as this only happens with fentry which is
+* not supported (yet) by i386, we can use the r10
+* field directly here.
+*/
+ kcb->jprobe_saved_regs.r10 = (unsigned long)p->addr;
+
+ /*
* If function graph tracing traced the function that the
* jprobe attached to, then the function graph tracing
* would have changed the stack return address to point to
@@ -1117,21 +1133,12 @@ int longjmp_break_handler(struct kprobe *p, struct
pt_regs *regs)
* handler.
*/
kcb->jprobe_saved_regs.ip = (unsigned long)fixup_jprobe;
+ } else {
/*
-* Since we are not returning back to the function
-* that was probed, the fixup_jprobe needs a way
-* to know what to jump back to. Store that in the
-* r10 register which callee functions are allowed
-* to clobber. Since r10 can be clobbered by the callee,
-* the caller must save it if necessary. As the callee
-* (probed function) has not been executed yet, the
-* value for r10 currently is not important.
-*
-* Note, as this only happens with fentry which is
-* not supported (yet) by i386, we can use the r10
-* field directly here.
+* See if function graph tracing is enabled and
+* trace this function if necessary.
*/
- kcb->jprobe_saved_regs.r10 = (unsigned long)p->addr;
+ kcb->jprobe_saved_regs.ip = ftrace_trace_addr;
}
#else
/* It's OK to start function graph tracing again */
diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
index 0fd23d19ed66..317377f1df26 100644
--- a/arch/x86/kernel/kprobes/ftrace.c
+++ b/arch/x86/kernel/kprobes/ftrace.c
@@ -37,7 +37,9 @@ int
[RFC][PATCH 0/2] ftrace/jprobes/x86: Graph trace jprobes if fentry is used
This is built on top of the patches that disable function graph tracer for jprobes: https://lkml.org/lkml/2015/1/14/631 This is actually the first solution I had to deal with jprobes and function graph tracing, but as I thought the problem only happened when kprobes used the ftrace infrastructure (fentry), I had a bit more control of what was happening. But testing showed that the issue also happens when kprobes does not use fentry, but uses the breakpoint at the start of the function. Dealing with breakpoints and simulating commands the breakpoint is on and trying to get all that to work with function graph tracing was a bit too much, so I punted (sorry for the American Football reference). I just made a patch set that disabled function graph tracing on jprobes all together and I'm pushing that to mainline and stable. That said, in most cases today, people use x86_64 over i386 and have newer gcc's that support fentry. That means for the majority of use cases jprobes can still be traced and we do not need to limit function graph tracing against them. I took my first solution and placed it on top of the final solution where if fentry is supported, we do not disable function graph tracing on jprobes but instead use the added trampoline tricks to cover it. The first patch allows for tracing of jprobes and the second patch lets function graph tracing still trace the function that is being probed. Steven Rostedt (Red Hat) (2): ftrace/jprobes/x86: Allow jprobes to be graph traced if using fentry ftrace/jprobes/x86: Have function being probed be graph traced arch/x86/include/asm/ftrace.h| 4 +++ arch/x86/include/asm/kprobes.h | 9 + arch/x86/kernel/kprobes/core.c | 72 +++- arch/x86/kernel/kprobes/ftrace.c | 14 arch/x86/kernel/mcount_64.S | 36 +++- 5 files changed, 133 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 1/2] ftrace/jprobes/x86: Allow jprobes to be graph traced if using fentry
From: "Steven Rostedt (Red Hat)"
Currently when a jprobe handler is called it disables function graph
tracing until the jprobe handler is complete. This means that jprobe
handlers can not be traced, nor can the functions they probe be traced
if fentry is used (the disabling happens around the time the function
graph code is called on the probed function).
If fentry is enabled, then kprobes is used on top of the ftrace
infrastructure when a probe is attached to the beginning of a function
(like jprobes are). In this special case, ftrace has more control of
what happens with the jprobe, and the jprobe can detect that it was
traced.
If the jprobe detects that it was traced by the function graph tracer
(it sees that the return address on th stack was changed to return to
"return_to_handler"), it can return to a fixup function in ftrace that
would allow it to fix the skipped return that it did by calling
jprobe_return().
The solution is two fold. One is to simply add notrace to the
jprobe_return(), as there's no reason to trace it as it is only
a hack for jprobes. The other is to have jprobes detect this in
the breakpoint handler itself. If it sees that the return address
was replaced by the function graph tracer's return_to_handler
hook, it will then call an ftrace helper function that updates
the ftrace return stack data, and will have the regs->ip return
to a fixup_jprobe() handler. When it returns, the handler
will perform the final fixes and return back to the function call.
Note, the function attached to the jprobe may still not be traced
if it is filtered by the function graph tracer, as the regs->ip
is still modified by the jprobe code before it reaches the function
graph code, and it may not match the graph filtered functions.
Cc: Masami Hiramatsu
Signed-off-by: Steven Rostedt
---
arch/x86/include/asm/ftrace.h| 3 ++
arch/x86/include/asm/kprobes.h | 9 ++
arch/x86/kernel/kprobes/core.c | 65 +++-
arch/x86/kernel/kprobes/ftrace.c | 12
arch/x86/kernel/mcount_64.S | 24 ++-
5 files changed, 111 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index f45acad3c4b6..bfabbb44797f 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -35,6 +35,9 @@ struct dyn_arch_ftrace {
int ftrace_int3_handler(struct pt_regs *regs);
+/* Used to keep jprobes from messing with function graph tracing */
+void fixup_jprobe(void);
+
#define FTRACE_GRAPH_TRAMP_ADDR FTRACE_GRAPH_ADDR
#endif /* CONFIG_DYNAMIC_FTRACE */
diff --git a/arch/x86/include/asm/kprobes.h b/arch/x86/include/asm/kprobes.h
index 4421b5da409d..d4e3d221b896 100644
--- a/arch/x86/include/asm/kprobes.h
+++ b/arch/x86/include/asm/kprobes.h
@@ -117,4 +117,13 @@ extern int kprobe_exceptions_notify(struct notifier_block
*self,
unsigned long val, void *data);
extern int kprobe_int3_handler(struct pt_regs *regs);
extern int kprobe_debug_handler(struct pt_regs *regs);
+
+/*
+ * If fentry is being used, then it's OK to function graph trace
+ * jprobes, as it is implented on top of the ftrace infrastructure.
+ */
+#if defined(CC_USING_FENTRY) && defined(CONFIG_FUNCTION_GRAPH_TRACER)
+# define ALLOW_JPROBE_GRAPH_TRACER
+#endif
+
#endif /* _ASM_X86_KPROBES_H */
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 98f654d466e5..971c3803f283 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -1021,19 +1021,22 @@ int setjmp_pre_handler(struct kprobe *p, struct pt_regs
*regs)
trace_hardirqs_off();
regs->ip = (unsigned long)(jp->entry);
+#ifndef ALLOW_JPROBE_GRAPH_TRACER
/*
* jprobes use jprobe_return() which skips the normal return
* path of the function, and this messes up the accounting of the
* function graph tracer to get messed up.
*
* Pause function graph tracing while performing the jprobe function.
+* Unless we allow for jprobes to be traced.
*/
pause_graph_tracing();
+#endif
return 1;
}
NOKPROBE_SYMBOL(setjmp_pre_handler);
-void jprobe_return(void)
+void notrace jprobe_return(void)
{
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
@@ -1072,8 +1075,68 @@ int longjmp_break_handler(struct kprobe *p, struct
pt_regs *regs)
show_regs(regs);
BUG();
}
+/*
+ * When using fentry (which is not yet used by i386), the jprobe handlers
+ * may use the ftrace infrastructure to implement the calling of the kprobe
+ * (and jprobe) handlers. The jprobe pre handler copies the stack frame and
+ * changes the ip address to call the jprobe callback. The callback calls
+ * jprobe_return() which does an int3 breakpoint to call the jprobe breakpiont
+ * handler which will put back the stack frame and set the regs->ip back to the
+ *
[PATCH 1/2] tracing: Remove extra call to init_ftrace_syscalls()
From: "Steven Rostedt (Red Hat)" trace_init() calls init_ftrace_syscalls() and then calls trace_event_init() which also calls init_ftrace_syscalls(). It makes more sense to only call it from trace_event_init(). Calling it twice wastes memory, as it allocates the syscall events twice, and loses the first copy of it. Link: http://lkml.kernel.org/r/54af53bd.5070...@huawei.com Reported-by: Wang Nan Signed-off-by: Steven Rostedt --- kernel/trace/trace.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 2e767972e99c..4a9079b9f082 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -6918,7 +6918,6 @@ void __init trace_init(void) tracepoint_printk = 0; } tracer_alloc_buffers(); - init_ftrace_syscalls(); trace_event_init(); } -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] tracing: A couple of fixes
Some bugs have been reported and this fixes them. I'll be testing them a bit more before pushing them to Linus. Steven Rostedt (Red Hat) (2): tracing: Remove extra call to init_ftrace_syscalls() tracing: Fix enabling of syscall events on the command line kernel/trace/trace.c| 1 - kernel/trace/trace_events.c | 69 - 2 files changed, 55 insertions(+), 15 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] tracing: Fix enabling of syscall events on the command line
From: "Steven Rostedt (Red Hat)"
Commit 5f893b2639b2 "tracing: Move enabling tracepoints to just after
rcu_init()" broke the enabling of system call events from the command
line. The reason was that the enabling of command line trace events
was moved before PID 1 started, and the syscall tracepoints require
that all tasks have the TIF_SYSCALL_TRACEPOINT flag set. But the
swapper task (pid 0) is not part of that. Since the swapper task is the
only task that is running at this early in boot, no task gets the
flag set, and the tracepoint never gets reached.
Instead of setting the swapper task flag (there should be no reason to
do that), re-enabled trace events again after the init thread (PID 1)
has been started. It requires disabling all command line events and
re-enabling them, as just enabling them again will not reset the logic
to set the TIF_SYSCALL_TRACEPOINT flag, as the syscall tracepoint will
be fooled into thinking that it was already set, and wont try setting
it again. For this reason, we must first disable it and re-enable it.
Link:
http://lkml.kernel.org/r/1421188517-18312-1-git-send-email-...@ellerman.id.au
Reported-by: Michael Ellerman
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_events.c | 69 -
1 file changed, 55 insertions(+), 14 deletions(-)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 366a78a3e61e..b03a0ea77b99 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -2429,12 +2429,39 @@ static __init int event_trace_memsetup(void)
return 0;
}
+static __init void
+early_enable_events(struct trace_array *tr, bool disable_first)
+{
+ char *buf = bootup_event_buf;
+ char *token;
+ int ret;
+
+ while (true) {
+ token = strsep(, ",");
+
+ if (!token)
+ break;
+ if (!*token)
+ continue;
+
+ /* Restarting syscalls requires that we stop them first */
+ if (disable_first)
+ ftrace_set_clr_event(tr, token, 0);
+
+ ret = ftrace_set_clr_event(tr, token, 1);
+ if (ret)
+ pr_warn("Failed to enable trace event: %s\n", token);
+
+ /* Put back the comma to allow this to be called again */
+ if (buf)
+ *(buf - 1) = ',';
+ }
+}
+
static __init int event_trace_enable(void)
{
struct trace_array *tr = top_trace_array();
struct ftrace_event_call **iter, *call;
- char *buf = bootup_event_buf;
- char *token;
int ret;
if (!tr)
@@ -2456,18 +2483,7 @@ static __init int event_trace_enable(void)
*/
__trace_early_add_events(tr);
- while (true) {
- token = strsep(, ",");
-
- if (!token)
- break;
- if (!*token)
- continue;
-
- ret = ftrace_set_clr_event(tr, token, 1);
- if (ret)
- pr_warn("Failed to enable trace event: %s\n", token);
- }
+ early_enable_events(tr, false);
trace_printk_start_comm();
@@ -2478,6 +2494,31 @@ static __init int event_trace_enable(void)
return 0;
}
+/*
+ * event_trace_enable() is called from trace_event_init() first to
+ * initialize events and perhaps start any events that are on the
+ * command line. Unfortunately, there are some events that will not
+ * start this early, like the system call tracepoints that need
+ * to set the TIF_SYSCALL_TRACEPOINT flag of pid 1. But event_trace_enable()
+ * is called before pid 1 starts, and this flag is never set, making
+ * the syscall tracepoint never get reached, but the event is enabled
+ * regardless (and not doing anything).
+ */
+static __init int event_trace_enable_again(void)
+{
+ struct trace_array *tr;
+
+ tr = top_trace_array();
+ if (!tr)
+ return -ENODEV;
+
+ early_enable_events(tr, true);
+
+ return 0;
+}
+
+early_initcall(event_trace_enable_again);
+
static __init int event_trace_init(void)
{
struct trace_array *tr;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: Fix typo in `struct usb_host_interface' comment
The descriptor member `bNumEndpoints' is plural.
Signed-off-by: Chris Rorvick
---
include/linux/usb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/usb.h b/include/linux/usb.h
index f89c24a..4add566 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -82,7 +82,7 @@ struct usb_host_interface {
int extralen;
unsigned char *extra; /* Extra descriptors */
- /* array of desc.bNumEndpoint endpoints associated with this
+ /* array of desc.bNumEndpoints endpoints associated with this
* interface setting. these will be in no particular order.
*/
struct usb_host_endpoint *endpoint;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2 v2] ftrace: don't allow IPMODIFY without proper compiler support
(2015/01/14 17:47), Jiri Kosina wrote:
> Using IPMODIFY needs to be allowed only with compilers which are
> guaranteed to generate function prologues compatible with function
> redirection through changing instruction pointer in saved regs.
>
> For example changing regs->ip on x86_64 in cases when gcc is using mcount
> (and not fentry) is not allowed, because at the time mcount call is
> issued, the original function's prologue has already been executed, which
> leads to all kinds of inconsistent havoc.
>
> There is currently no way to express dependency on gcc features in
> Kconfig, (CC_USING_FENTRY is defined only during build, so it's not
> possible for Kconfig symbol to depend on it) so this needs to be checked
> in runtime.
>
> Mark x86_64 with fentry supported for now. Other archs can be added
> gradually.
>
> Signed-off-by: Jiri Kosina
> ---
>
> v1 -> v2: turn macro function into a plain macro
>
> arch/x86/include/asm/ftrace.h | 2 ++
> include/linux/ftrace.h| 5 +
> kernel/trace/ftrace.c | 5 +
> 3 files changed, 12 insertions(+)
>
> diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> index f45acad..f84eaaf 100644
> --- a/arch/x86/include/asm/ftrace.h
> +++ b/arch/x86/include/asm/ftrace.h
> @@ -4,8 +4,10 @@
> #ifdef CONFIG_FUNCTION_TRACER
> #ifdef CC_USING_FENTRY
> # define MCOUNT_ADDR ((long)(__fentry__))
> +# define ftrace_ipmodify_supported 1
> #else
> # define MCOUNT_ADDR ((long)(mcount))
> +# define ftrace_ipmodify_supported 0
> #endif
> #define MCOUNT_INSN_SIZE 5 /* sizeof mcount call */
>
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index 1da6029..837153a 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -244,6 +244,11 @@ static inline int ftrace_function_local_disabled(struct
> ftrace_ops *ops)
> extern void ftrace_stub(unsigned long a0, unsigned long a1,
> struct ftrace_ops *op, struct pt_regs *regs);
>
> +#ifndef ftrace_ipmodify_supported
> +/* let's not make any implicit assumptions about profiling call placement */
> +# define ftrace_ipmodify_supported 0
> +
> +#endif
> #else /* !CONFIG_FUNCTION_TRACER */
> /*
> * (un)register_ftrace_function must be a macro since the ops parameter
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 929a733..05af4cd 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -1809,6 +1809,11 @@ static int __ftrace_hash_update_ipmodify(struct
> ftrace_ops *ops,
> if (!(ops->flags & FTRACE_OPS_FL_IPMODIFY))
> return 0;
>
> + if (!ftrace_ipmodify_supported) {
> + WARN(1, "Your compiler doesn't support features necessary for
> IPMODIFY");
> + return 0;
> + }
> +
Hmm, if this binary doesn't support IPMODIFY, it should return -ENOTSUPP.
And also, IMHO, we'd better reject registering ftrace_ops with IPMODIFY
in this situation before updating hash table.
Thank you,
> /*
>* Since the IPMODIFY is a very address sensitive action, we do not
>* allow ftrace_ops to set all functions to new hash.
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 06/10] iommu/vt-d: datatypes and functions used for kdump
On 01/12/15 at 03:06pm, Li, Zhen-Hua wrote:
> +/*
> + * Interface to the "copy translation tables" set of functions
> + * from mainline code.
> + */
> +static int intel_iommu_load_translation_tables(struct dmar_drhd_unit *drhd,
> + int g_num_of_iommus)
The argument g_num_of_iommus is the same as the global variable, it's better
to rename it as num_of_iommus. And even it can be removed since you can
just use the global variable g_num_of_iommus in this function.
Argument drhd can be intel_iommu because no other member variable in
drhd is needed.
> +{
> + struct intel_iommu *iommu; /* Virt(iommu hardware registers) */
> + unsigned long long q; /* quadword scratch */
> + int ret = 0;/* Integer return code */
> + int i = 0; /* Loop index */
> + unsigned long flags;
> +
> + /* Structure so copy_page_addr() can accumulate things
> + * over multiple calls and returns
> + */
> + struct copy_page_addr_parms ppa_parms = copy_page_addr_parms_init;
> + struct copy_page_addr_parms *ppap = _parms;
> +
> +
> + iommu = drhd->iommu;
> + q = dmar_readq(iommu->reg + DMAR_RTADDR_REG);
> + if (!q)
> + return -1;
> +
> + /* If (list needs initializing) do it here */
This initializing should not be here, because it's not only for this
drhd. It should be done in init_dmars().
> + if (!domain_values_list) {
> + domain_values_list =
> + kcalloc(g_num_of_iommus, sizeof(struct list_head),
> + GFP_KERNEL);
> +
> + if (!domain_values_list) {
> + pr_err("Allocation failed for domain_values_list
> array\n");
> + return -ENOMEM;
> + }
> + for (i = 0; i < g_num_of_iommus; i++)
> + INIT_LIST_HEAD(_values_list[i]);
> + }
> +
> + spin_lock_irqsave(>lock, flags);
> +
> + /* Load the root-entry table from the old kernel
> + * foreach context_entry_table in root_entry
> + *foreach context_entry in context_entry_table
> + * foreach level-1 page_table_entry in context_entry
> + * foreach level-2 page_table_entry in level 1 page_table_entry
> + * Above pattern continues up to 6 levels of page tables
> + *Sanity-check the entry
> + *Process the bus, devfn, page_address, page_size
> + */
> + if (!iommu->root_entry) {
> + iommu->root_entry =
> + (struct root_entry *)alloc_pgtable_page(iommu->node);
> + if (!iommu->root_entry) {
> + spin_unlock_irqrestore(>lock, flags);
> + return -ENOMEM;
> + }
> + }
> +
> + iommu->root_entry_old_phys = q & VTD_PAGE_MASK;
> + if (!iommu->root_entry_old_phys) {
> + pr_err("Could not read old root entry address.");
> + return -1;
> + }
> +
> + iommu->root_entry_old_virt = ioremap_cache(iommu->root_entry_old_phys,
> + VTD_PAGE_SIZE);
> + if (!iommu->root_entry_old_virt) {
> + pr_err("Could not map the old root entry.");
> + return -ENOMEM;
> + }
> +
> + __iommu_load_old_root_entry(iommu);
> + ret = copy_root_entry_table(iommu, ppap);
> + __iommu_flush_cache(iommu, iommu->root_entry, PAGE_SIZE);
> + __iommu_update_old_root_entry(iommu, -1);
> +
> + spin_unlock_irqrestore(>lock, flags);
> +
> + __iommu_free_mapped_mem();
> +
> + if (ret)
> + return ret;
> +
> + ppa_parms.last = 1;
> + copy_page_addr(0, 0, 0, 0, 0, NULL, ppap);
> +
> + return 0;
> +}
> +
> #endif /* CONFIG_CRASH_DUMP */
> --
> 2.0.0-rc0
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPICA: rsdump: Remove some unused functions
Hi, Rickard
I've done some corrections in the following commit for this report:
https://github.com/zetalog/acpica/commit/f86ad0858eacfe890cbeae43846da2638c389c1c
All other utilities related corrections are done in:
https://github.com/zetalog/acpica/commit/06fb69ea0e4c47edc91544a90a69b983fd161963
And the patches are now part of the 201501 release materials pending for review:
https://github.com/acpica/acpica/pull/61
I think I should also let you know my opinions against this kind of no usage
functions.
IMO, what you've done is useless and make source tree maintenance more
difficult than anyone expects.
Kernel compilation contains "strip" step which can automatically remove symbols
without any references on them.
So we don't need to maintain this in the source level.
And there is a defect in maintaining it in the source level.
A module could have native variables and functions accessing these native
variables should be bounded to the same source file.
So if there are 2 functions using one native variables in a source file like
the following example:
a.c
static int a;
int get_a(void)
{
return a;
}
void set_a(int a)
{
a = v;
}
If get_a is only used by a module enabled with CONFIG_DEVICE_X and set_a is
only used by a module enabled with CONFIG_DEVICE_Y.
Should we do such modifications?
static int a;
#ifdef CONFIG_DEVICE_X
int get_a(void)
{
return a;
}
#endif
#ifdef CONFIG_DEVICE_Y
void set_a(int a)
{
a = v;
}
#endif
I think no one will do this in the kernel.
We simply will prepare another config itme for a.c, for example CONFIG_MODULE_A
Then we will have dependencies in Kconfig:
config DEVICE_X
bool
depends MODULE_A
config DEVICE_Y
bool
depends MODULE_A
And let the no user function automatically be deleted by "strip".
Because if the references changes, the developers will need to check plenty of
such "#ifdef" to correct compilation warnings...
If you do want to do this in the upstream kernel, you'll find millions of
functions need to be wrapped by such useless "#ifdef".
A source file should only contain the self contained logics in it without
considering the users.
Thanks and best regards
-Lv
> -Original Message-
> From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
> Sent: Wednesday, January 14, 2015 2:44 AM
> To: Moore, Robert; Zheng, Lv
> Cc: Rickard Strandqvist; Wysocki, Rafael J; Len Brown;
> linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] ACPICA: rsdump: Remove some unused functions
>
> Removes some functions that are not used anywhere:
> acpi_rs_dump_irq_list() acpi_rs_dump_resource_list()
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/acpi/acpica/acresrc.h |7 ---
> drivers/acpi/acpica/rsdump.c | 110
> -
> 2 files changed, 117 deletions(-)
>
> diff --git a/drivers/acpi/acpica/acresrc.h b/drivers/acpi/acpica/acresrc.h
> index 4b008e8..4a4f8af 100644
> --- a/drivers/acpi/acpica/acresrc.h
> +++ b/drivers/acpi/acpica/acresrc.h
> @@ -299,13 +299,6 @@ acpi_rs_set_resource_length(acpi_rsdesc_size
> total_length,
> union aml_resource *aml);
>
> /*
> - * rsdump
> - */
> -void acpi_rs_dump_resource_list(struct acpi_resource *resource);
> -
> -void acpi_rs_dump_irq_list(u8 * route_table);
> -
> -/*
> * Resource conversion tables
> */
> extern struct acpi_rsconvert_info acpi_rs_convert_dma[];
> diff --git a/drivers/acpi/acpica/rsdump.c b/drivers/acpi/acpica/rsdump.c
> index c3c56b5..8bd41ec 100644
> --- a/drivers/acpi/acpica/rsdump.c
> +++ b/drivers/acpi/acpica/rsdump.c
> @@ -357,116 +357,6 @@ static void acpi_rs_dump_address_common(union
> acpi_resource_data *resource)
>
>
> /***
> *
> - * FUNCTION:acpi_rs_dump_resource_list
> - *
> - * PARAMETERS: resource_list - Pointer to a resource descriptor list
> - *
> - * RETURN: None
> - *
> - * DESCRIPTION: Dispatches the structure to the correct dump routine.
> - *
> -
> **/
> -
> -void acpi_rs_dump_resource_list(struct acpi_resource *resource_list)
> -{
> - u32 count = 0;
> - u32 type;
> -
> - ACPI_FUNCTION_ENTRY();
> -
> - /* Check if debug output enabled */
> -
> - if (!ACPI_IS_DEBUG_ENABLED(ACPI_LV_RESOURCES, _COMPONENT)) {
> - return;
> - }
> -
> - /* Walk list and dump all resource descriptors (END_TAG terminates) */
> -
> - do {
> - acpi_os_printf("\n[%02X] ", count);
> - count++;
> -
> - /* Validate Type before dispatch */
> -
> - type = resource_list->type;
> - if (type > ACPI_RESOURCE_TYPE_MAX) {
> - acpi_os_printf
>
RE: [PATCH mtd] mtd:devices: Add Altera EPCQ Driver
Hi Brian,
For Altera EPCQ flashes, almost operations are performed underline hardware.
Software only able to perform the following through registers:
- read status register
- read id
- write status registers bit SR_BP0,SR_BP1, SR_BP2,SR_BP3, SR_TB
(http://www.altera.com.my/literature/hb/cfg/cfg_cf52012.pdf)
For read/write data: all the operations like QUAD_READ/WRITE, FAST_READ/WRITE
are handled by hardware as well. From software point of view, there is no
difference between these 2 modes.
That is why if rewrite the drivers to follow spi-nor structure, it will require
extra decoding works for the only few used opcodes.
Thanks,
Viet Nga
-Original Message-
From: Brian Norris [mailto:computersforpe...@gmail.com]
Sent: Tuesday, January 13, 2015 11:33 AM
To: Viet Nga Dao
Cc: dw...@infradead.org; linux-...@lists.infradead.org;
linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; ngach...@gmail.com
Subject: Re: [PATCH mtd] mtd:devices: Add Altera EPCQ Driver
On Thu, Dec 18, 2014 at 12:23:16AM -0800, vn...@altera.com wrote:
> From: Viet Nga Dao
>
> Altera EPCQ Controller is a soft IP which enables access to Altera
> EPCQ and EPCS flash chips. This patch adds driver for these devices.
>
> Signed-off-by: Viet Nga Dao
This drivers seems awfully similar to (and so I infer it is likely
copy-and-pasted from) m25p80.c / spi-nor.c. Do you think it can be rewritten as
a SPI NOR driver, under drivers/mtd/spi-nor/ ? It looks like these flash share
most (all?) the same basic opcodes.
> ---
> .../devicetree/bindings/mtd/altera_epcq.txt| 45 ++
> drivers/mtd/devices/Kconfig| 12 +
> drivers/mtd/devices/Makefile |2 +-
> drivers/mtd/devices/altera_epcq.c | 804
>
> drivers/mtd/devices/altera_epcq.h | 130
> 5 files changed, 992 insertions(+), 1 deletions(-) create mode
> 100644 Documentation/devicetree/bindings/mtd/altera_epcq.txt
> create mode 100644 drivers/mtd/devices/altera_epcq.c create mode
> 100644 drivers/mtd/devices/altera_epcq.h
>
> diff --git a/Documentation/devicetree/bindings/mtd/altera_epcq.txt
> b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
> new file mode 100644
> index 000..d14f50e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
> @@ -0,0 +1,45 @@
> +* MTD Altera EPCQ driver
> +
> +Required properties:
> +- compatible: Should be "altr,epcq-1.0"
> +- reg: Address and length of the register set for the device. It
> +contains
> + the information of registers in the same order as described by
> +reg-names
> +- reg-names: Should contain the reg names
> + "csr_base": Should contain the register configuration base address
> + "data_base": Should contain the data base address
> +- is-epcs: boolean type.
> + If present, the device contains EPCS flashes.
> + Otherwise, it contains EPCQ flashes.
> +- #address-cells: Must be <1>.
> +- #size-cells: Must be <0>.
> +- flash device tree subnode, there must be a node with the following fields:
These subnodes definitely require a 'compatible' string. Perhaps they should be
used to differentiate EPCS vs. EPCQ. Does "is-epcs" really need to be in the
top-level controller node?
> + - reg: Should contain the flash id
Should, or must? (This question is relevant, because you seem to make it
optional in your code.) And what does the "flash ID" mean? It seems like you're
using as a chip-select or bank index.
> + - #address-cells: please refer to /mtd/partition.txt
> + - #size-cells: please refer to /mtd/partition.txt
> + For partitions inside each flash, please refer to /mtd/partition.txt
> +
> +Example:
> +
> + epcq_controller_0: epcq@0x0 {
> + compatible = "altr,epcq-1.0";
> + reg = <0x0001 0x 0x0020>,
> + <0x 0x 0x0200>;
> + reg-names = "csr_base", "data_base";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + flash0: epcq256@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + /* 16 MB for raw data. */
> + label = "EPCQ Flash 0 raw data";
> + reg = <0x0 0x100>;
> + };
> + partition@100 {
> + /* 16 MB for jffs2 data. */
> + label = "EPCQ Flash 0 JFFS 2";
> +
Re: [PATCH 2/2] kprobes: compile out IPMODIFY support if ftrace doesn't support it
(2015/01/14 17:48), Jiri Kosina wrote:
> If ftrace doesn't claim to support IPMODIFY support, there is no need to
> compile IPMODIFY support in kprobes either.
>
This looks good to me :)
Acked-by: Masami Hiramatsu
Thanks!
> Signed-off-by: Jiri Kosina
> ---
> kernel/kprobes.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 06f5830..49a69d7 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -912,7 +912,7 @@ static struct kprobe *alloc_aggr_kprobe(struct kprobe *p)
> }
> #endif /* CONFIG_OPTPROBES */
>
> -#ifdef CONFIG_KPROBES_ON_FTRACE
> +#if defined(CONFIG_KPROBES_ON_FTRACE) && (ftrace_ipmodify_supported == 1)
> static struct ftrace_ops kprobe_ftrace_ops __read_mostly = {
> .func = kprobe_ftrace_handler,
> .flags = FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_IPMODIFY,
> @@ -957,7 +957,7 @@ static void disarm_kprobe_ftrace(struct kprobe *p)
> (unsigned long)p->addr, 1, 0);
> WARN(ret < 0, "Failed to disarm kprobe-ftrace at %p (%d)\n", p->addr,
> ret);
> }
> -#else/* !CONFIG_KPROBES_ON_FTRACE */
> +#else/* !CONFIG_KPROBES_ON_FTRACE || ftrace_ipmodify_supported == 0
> */
> #define prepare_kprobe(p)arch_prepare_kprobe(p)
> #define arm_kprobe_ftrace(p) do {} while (0)
> #define disarm_kprobe_ftrace(p) do {} while (0)
> @@ -1416,12 +1416,12 @@ int __weak arch_check_ftrace_location(struct kprobe
> *p)
>
> ftrace_addr = ftrace_location((unsigned long)p->addr);
> if (ftrace_addr) {
> -#ifdef CONFIG_KPROBES_ON_FTRACE
> +#if defined(CONFIG_KPROBES_ON_FTRACE) && (ftrace_ipmodify_supported == 1)
> /* Given address is not on the instruction boundary */
> if ((unsigned long)p->addr != ftrace_addr)
> return -EILSEQ;
> p->flags |= KPROBE_FLAG_FTRACE;
> -#else/* !CONFIG_KPROBES_ON_FTRACE */
> +#else/* !CONFIG_KPROBES_ON_FTRACE || ftrace_ipmodify_supported == 0
> */
> return -EINVAL;
> #endif
> }
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] perf symbols: Ignore mapping symbols on aarch64
On 14 January 2015 at 16:03, Russell King - ARM Linux
wrote:
> On Wed, Jan 14, 2015 at 10:38:38AM -0800, Victor Kamensky wrote:
>> >From fed6caab410ddcaf487ff23a3908eca129e50b89 Mon Sep 17 00:00:00 2001
>> From: Victor Kamensky
>> Date: Wed, 14 Jan 2015 07:42:41 -0800
>> Subject: [PATCH 3/3] perf symbols: improve abi compliance in arm mapping
>> symbols handling
>>
>> Both Arm and Aarch64 ELF ABI allow mapping symbols be in from
>> either "$d" or "$d.". But current code that handles mapping
>> symbols only deals with the first, dollar character and a single
>> letter, case.
>>
>> The patch adds handling of the second case with period
>> followed by any characters.
>>
>> Suggested-by: Will Deacon
>> Signed-off-by: Victor Kamensky
>
> I wonder if it would make more sense to re-use the "is_arm_mapping_symbol"
> thing which we have in kernel/module.c and scripts/kallsyms.c - it
> seems silly to re-invent code which we already have to detect these
> symbols.
Thanks for pointing this out. I did not know about
"is_arm_mapping_symbol" function.
Do you suggest we copy one of those functions into tools/perf?
Since tools/perf is separate user-land utility I don't see easy way
how can we reuse those directly.
Also those functions check for mapping symbols
seems to be more efficient that one I come with, for example
one from scripts/kallsyms.c
static inline int is_arm_mapping_symbol(const char *str)
{
return str[0] == '$' && strchr("axtd", str[1])
&& (str[2] == '\0' || str[2] == '.');
}
But it seems that they are somewhat accurate: because they bundle
EM_ARM and EM_AARCH64 into one case. According to ABIs
for EM_ARM we have $a, $t, $d, $a., $t., $d.;
and for EM_AARCH64 we have $x, $d, $x., $d..
How about the following two variants of the patch. It follows the same
mapping handling logic as in other 3 copies of is_arm_mapping_symbol
function in kernel, but it still separate copy in tools/perf code. Personally I
prefer variant 1, but I am fine with variant 2 too, because practically it
will be OK.
Variant 1 (as addition to this patch, as above):
>From e08d348bd72d406d8939993d266729d805577c4b Mon Sep 17 00:00:00 2001
From: Victor Kamensky
Date: Wed, 14 Jan 2015 07:42:41 -0800
Subject: [PATCH 3/3] perf symbols: improve abi compliance in arm mapping
symbols handling
Both Arm and Aarch64 ELF ABI allow mapping symbols be in from
either "$d" or "$d.". But current code that handles mapping
symbols only deals with the first, dollar character and a single
letter, case.
The patch adds handling of the second case with period
followed by any characters.
Suggested-by: Russell King
Suggested-by: Will Deacon
Signed-off-by: Victor Kamensky
---
tools/perf/util/symbol-elf.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 1e188dd..a038c98 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -857,17 +857,16 @@ int dso__load_sym(struct dso *dso, struct map *map,
* don't identify functions, so will confuse the profile
* output: */
if (ehdr.e_machine == EM_ARM) {
-if (!strcmp(elf_name, "$a") ||
-!strcmp(elf_name, "$d") ||
-!strcmp(elf_name, "$t"))
+if (elf_name[0] == '$' && strchr("adt", elf_name[1])
+&& (elf_name[2] == '\0' || elf_name[2] == '.'))
continue;
}
/* Reject Aarch64 ELF "mapping symbols": these aren't unique and
* don't identify functions, so will confuse the profile
* output: */
if (ehdr.e_machine == EM_AARCH64) {
-if (!strcmp(elf_name, "$x") ||
-!strcmp(elf_name, "$d"))
+if (elf_name[0] == '$' && strchr("dx", elf_name[1])
+&& (elf_name[2] == '\0' || elf_name[2] == '.'))
continue;
}
--
1.9.3
Variant 2 instead of patch posted with current subject:
From c8d08ebddc61203daf21b17c891c26c1d08e14f1 Mon Sep 17 00:00:00 2001
From: Victor Kamensky
Date: Mon, 12 Jan 2015 14:13:36 -0800
Subject: [PATCH 1/2] perf symbols: Ignore mapping symbols on aarch64
Aarch64 ELF files use mapping symbols with special names $x, $d
to identify regions of Aarch64 code (see Aarch64 ELF ABI - "ARM
IHI 0056B", section "4.5.4 Mapping symbols").
The patch filters out these symbols at load time, similar to
"696b97a perf symbols: Ignore mapping symbols on ARM" changes
done for ARM before V8.
Also added handling of mapping symbols that has format
"$d." and similar for both cases.
Note we are not making difference between EM_ARM and
EM_AARCH64 mapping symbols instead code handles superset
of both.
Signed-off-by: Victor Kamensky
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Avi Kivity
Cc: Masami Hiramatsu
Cc: Anton
Re: [RFC PATCH 06/11] x86,fpu: lazily skip fpu restore with eager fpu mode, too
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/14/2015 01:36 PM, Oleg Nesterov wrote:
> On 01/11, r...@redhat.com wrote:
>>
>> If the next task still has its FPU state present in the FPU
>> registers, there is no need to restore it from memory.
>
> Another patch I can't understand...
>
>> --- a/arch/x86/include/asm/fpu-internal.h +++
>> b/arch/x86/include/asm/fpu-internal.h @@ -435,13 +435,9 @@ static
>> inline void switch_fpu_prepare(struct task_struct *old, struct
>> task_struc old->thread.fpu.last_cpu = ~0; if (preload) {
>> new->thread.fpu_counter++; - if (!use_eager_fpu() &&
>> fpu_lazy_restore(new, cpu)) -/* XXX: is this
>> safe against
>> ptrace??? */ - __thread_fpu_begin(new); -
>> else { +
>> set_thread_flag(TIF_LOAD_FPU); + if
>> (!fpu_lazy_restore(new,
>> cpu)) prefetch(new->thread.fpu.state); -
>> set_thread_flag(TIF_LOAD_FPU); - }
>
> It is not clear to me why do we set TIF_LOAD_FPU if
> fpu_lazy_restore() succeeds. __thread_fpu_begin() is cheap.
>
> At the same time, if switch_fpu_finish() does fpu_lazy_restore()
> anyway, why this patch doesn't remove it from switch_fpu_prepare()
> ?
I have it removed now, because the prefetch does not make
much sense (as was pointed out by either you or Andy).
>> @@ -466,6 +462,10 @@ static inline void switch_fpu_finish(void)
>>
>> __thread_fpu_begin(tsk);
>>
>> +/* The FPU registers already have this task's FPU state. */ +
>> if (fpu_lazy_restore(tsk, raw_smp_processor_id())) + return; +
>
> Now that this is called before return to user-mode, I am not sure
> this is correct. Note that __kernel_fpu_begin() doesn't clear
> fpu_owner_task if use_eager_fpu().
However, __kernel_fpu_begin() does call __thread_clear_has_fpu(),
which clears the per-cpu fpu_owner variable, which is also
evaluated by fpu_lazy_restore(), so I think this is actually
correct.
- --
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUtyqgAAoJEM553pKExN6DFG0H+wfeZaKByANgrgUBHMYjrkEW
0C6f3lWaxyi8CPad7ghWN3GnSARpaA+OorukD3xwmubZjUc69vcNHMPW9A8hT95q
FNpRQHW/ehx6esXme+Jc7r1FCYr5Jm9hvfQ4xPm6jQQDs/Sok4vjsPgOnaa0DeHa
gqeE2cXt38kTtTgxsP7CKC/m3/B+KQ2c7ieB4XtXfWfwBNiFUiFgfRB22ip0hZCr
7D2UuatSat+zyaH8G5bHPQciEzGWARYB/SrzhmoUXrX7fGdY7fMvKUDyLH+p2SK0
0k3V4yBETi2GtMK2+z3KNlQ8TVp4/LvkpuCKbu54hHQh1sDYkDCXDpMfcwuJ4H4=
=Hah8
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/xen-netfront.c between commit 900e183301b5 ("xen-netfront:
use different locks for Rx and Tx stats") from the net tree and commit
a55e8bb8fb89 ("xen-netfront: refactor making Tx requests") from the
net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/xen-netfront.c
index d8c10764f130,01a4350eb313..
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@@ -562,18 -518,15 +517,15 @@@ static u16 xennet_select_queue(struct n
static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
- unsigned short id;
struct netfront_info *np = netdev_priv(dev);
- struct netfront_stats *stats = this_cpu_ptr(np->stats);
+ struct netfront_stats *tx_stats = this_cpu_ptr(np->tx_stats);
- struct xen_netif_tx_request *tx;
- char *data = skb->data;
- RING_IDX i;
- grant_ref_t ref;
- unsigned long mfn;
+ struct xen_netif_tx_request *tx, *first_tx;
+ unsigned int i;
int notify;
int slots;
- unsigned int offset = offset_in_page(data);
- unsigned int len = skb_headlen(skb);
+ struct page *page;
+ unsigned int offset;
+ unsigned int len;
unsigned long flags;
struct netfront_queue *queue = NULL;
unsigned int num_queues = dev->real_num_tx_queues;
pgp02rJEo7C1o.pgp
Description: OpenPGP digital signature
[PATCH] usb: phy: make GPIOs optional for the generic phy
>From 47bd18e210fecf701d493c27884e13c69bc449ea Mon Sep 17 00:00:00 2001
From: Paul Zimmerman
Date: Wed, 14 Jan 2015 18:15:58 -0800
Subject: [PATCH] usb: phy: make GPIOs optional for the generic phy
The use of GPIOs should be optional for the generic phy, otherwise
the Altera SOCFPGA platform at least is broken.
Fixes breakage caused by a combination of e9f2cefb0cd "usb: phy:
generic: migrate to gpio_desc" and 135b3c4304d "usb: dwc2: platform:
add generic PHY framework support".
Signed-off-by: Paul Zimmerman
---
Based on top of testing/next.
drivers/usb/phy/phy-generic.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index dd05254..9a826ff 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -218,10 +218,10 @@ int usb_phy_gen_create_phy(struct device *dev, struct
usb_phy_generic *nop,
clk_rate = 0;
needs_vcc = of_property_read_bool(node, "vcc-supply");
- nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios");
+ nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset-gpios");
err = PTR_ERR(nop->gpiod_reset);
if (!err) {
- nop->gpiod_vbus = devm_gpiod_get(dev,
+ nop->gpiod_vbus = devm_gpiod_get_optional(dev,
"vbus-detect-gpio");
err = PTR_ERR(nop->gpiod_vbus);
}
--
1.7.6.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: fs: locks: WARNING: CPU: 16 PID: 4296 at fs/locks.c:236 locks_free_lock_context+0x10d/0x240()
On Wed, 14 Jan 2015 18:44:41 -0500 Sasha Levin wrote: > On 01/14/2015 09:27 AM, Jeff Layton wrote: > > On Tue, 13 Jan 2015 17:50:45 -0500 > > Sasha Levin wrote: > > > >> On 01/13/2015 04:44 PM, Jeff Layton wrote: > >>> On Tue, 13 Jan 2015 00:11:37 -0500 > >>> Sasha Levin wrote: > >>> > Hey Jeff, > > While fuzzing with trinity inside a KVM tools guest running the latest > -next > kernel, I've stumbled on the following spew: > > [ 887.078606] WARNING: CPU: 16 PID: 4296 at fs/locks.c:236 > locks_free_lock_context+0x10d/0x240() > [ 887.079703] Modules linked in: > [ 887.080288] CPU: 16 PID: 4296 Comm: trinity-c273 Not tainted > 3.19.0-rc4-next-20150112-sasha-00053-g23c147e02e-dirty #1710 > [ 887.082229] > 8804c9f4f8e8 > [ 887.083773] 9154e0a6 8804cad98000 > 8804c9f4f938 > [ 887.085280] 8140a4d0 0001 81bf0d2d > 8804c9f4f988 > [ 887.086792] Call Trace: > [ 887.087320] dump_stack (lib/dump_stack.c:52) > [ 887.088247] warn_slowpath_common (kernel/panic.c:447) > [ 887.089342] ? locks_free_lock_context (fs/locks.c:236 (discriminator > 3)) > [ 887.090514] warn_slowpath_null (kernel/panic.c:481) > [ 887.091629] locks_free_lock_context (fs/locks.c:236 (discriminator 3)) > [ 887.092782] __destroy_inode (fs/inode.c:243) > [ 887.093817] destroy_inode (fs/inode.c:268) > [ 887.094833] evict (fs/inode.c:574) > [ 887.095808] iput (fs/inode.c:1503) > [ 887.096687] __dentry_kill (fs/dcache.c:323 fs/dcache.c:508) > [ 887.097683] ? _raw_spin_trylock (kernel/locking/spinlock.c:136) > [ 887.098733] ? dput (fs/dcache.c:545 fs/dcache.c:648) > [ 887.099672] dput (fs/dcache.c:649) > [ 887.100552] __fput (fs/file_table.c:227) > >>> > >>> So, looking at this a bit more... > >>> > >>> It's clear that we're at the dput in __fput at this point. Much earlier > >>> in __fput, we call locks_remove_file to remove all of the locks that > >>> are associated with the file description. > >>> > >>> Evidently though, something didn't go right there. The two most likely > >>> scenarios to my mind are: > >>> > >>> A) a lock raced onto the list somehow after that point. That seems > >>> unlikely since presumably the fcheck should have failed at that point. > >>> > >>> ...or... > >>> > >>> B) the CPU that called locks_remove_file mistakenly thought that > >>> inode->i_flctx was NULL when it really wasn't (stale cache, perhaps?). > >>> That would make it skip trying to remove any flock locks. > >>> > >>> B seems more likely to me, and if it's the case then that would seem to > >>> imply that we need some memory barriers (or maybe some ACCESS_ONCE > >>> calls) in these codepaths. I'll have to sit down and work through it to > >>> see what makes the most sense. > >>> > >>> If your debugging seems to jive with this, then one thing that might be > >>> interesting would be to comment out these two lines in > >>> locks_remove_flock: > >>> > >>> if (!file_inode(filp)->i_flctx) > >>> return; > >>> > >>> ...and see if it's still reproducible. That's obviously not a real fix > >>> for this problem, but it might help prove whether the above suspicion > >>> is correct. > >> > >> Removing those two lines makes the issue go away. > >> > >> I'm guessing that figuring out which filesystem we were abusing isn't > >> interesting anymore... > >> > > > > Sigh. I've been trying to reproduce this today. I've set up two > > different KVM guests on two different hosts, and run trinity on both, > > and I can't seem to get this warning to pop. > > > > Could you share what trinity command-line options you're using? Any > > other special setup I should be considering to reproduce it? > > > > I was hoping to get it to reproduce so I could test out potential > > memory barrier fixes... > > I don't think there's anything special about my setup here that can > trigger that, specially if it's not dependant on a filesystem in use. > > I'm running trinity with: ./trinity -xsched_setattr -xsetpriority > -xunshare -xreboot -xshutdown -xnfsservctl -xclock_nanosleep -xuselib > -xperf_event_open -m --quiet --dangerous -C 400 -l off > > If that doesn't end up helping, I'd be happy to test out fixes here, > it usually reproduces quickly. > > Great, I'll try those options tomorrow. I did push out a newer version of the series to linux-next, which does a smp_rmb at the beginning of locks_remove_file. I'm not sure if that's sufficient to fix this, but it's probably a reasonable start. If you update the kernel you're testing to the next linux-next tree, then it'd be interesting to know if it's still reproducible. Thanks again! -- Jeff Layton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
Re: [linux-nics] [PATCHv4 net] i40e: Implement ndo_gso_check()
On Fri, Dec 26, 2014 at 3:58 PM, Jesse Gross wrote:
> On Fri, Dec 5, 2014 at 2:12 PM, Jeff Kirsher
> wrote:
>> On Fri, 2014-12-05 at 10:41 -0800, Joe Stringer wrote:
>>> ndo_gso_check() was recently introduced to allow NICs to report the
>>> offloading support that they have on a per-skb basis. Add an
>>> implementation for this driver which checks for IPIP, GRE, UDP
>>> tunnels.
>>>
>>> Signed-off-by: Joe Stringer
>>> ---
>>> v4: Simplify the check to just do tunnel header length.
>>> Fix #define style issue.
>>> v3: Drop IPIP and GRE (no driver support even though hw supports it).
>>> Check for UDP outer protocol for UDP tunnels.
>>> v2: Expand to include IP in IP and IPv4/IPv6 inside GRE/UDP tunnels.
>>> Add MAX_INNER_LENGTH (as 80).
>>> ---
>>> drivers/net/ethernet/intel/i40e/i40e_main.c | 12
>>> 1 file changed, 12 insertions(+)
>>
>> Thanks Joe, I will update the patch in my queue with your latest
>> version.
>
> Jeff, as a heads-up, this patch and the corresponding one for fm10k
> will no longer apply now that the ndo has changed. This was changed by
> 5f35227e ("net: Generalize ndo_gso_check to ndo_features_check"). The
> update needed is trivial and is just due to the change in the function
> signature but I'm not sure where you are in the testing process with
> this.
Jeff - just wanted to check if you had seen this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpufreq: add cpufreq driver for Mediatek MT8173 SoC
Hi Joe,
Thanks for reviewing.
On 14 January 2015 at 15:43, Yingjoe Chen wrote:
>
> Hi,
>
> On Fri, 2015-01-09 at 17:54 +0800, pi-cheng.chen wrote:
>> When doing DVFS on MT8173 SoC, 2 rules should be followed to make sure the
>> SoC works properly:
>> 1. When doing frequency scaling of CPUs, the clock source should be switched
>>to another PLL, then switched back to the orignal until it's stable.
>> 2. When doing voltage scaling of CA57 cluster, Vproc and Vsram need to be
>>controlled concurrently and 2 limitations should be followed:
>>a. Vsram > Vproc
>>b. Vsram - Vproc < 200 mV
>
> It seems to me this is not much different then other mtk big little
> SoCs. Is it possible to aim to support both mt8173 & mt8135 with this
> driver?
>
Yes. I will try to make it more flexibile so that the driver can support both
mt8173 and mt8135.
>> To address these needs, we reuse cpufreq-dt but do voltage scaling in the
>> cpufreq notifier.
>>
>> Signed-off-by: pi-cheng.chen
>> ---
>> drivers/cpufreq/Kconfig.arm | 6 +
>> drivers/cpufreq/Makefile | 1 +
>> drivers/cpufreq/mt8173-cpufreq.c | 459
>> +++
>> 3 files changed, 466 insertions(+)
>> create mode 100644 drivers/cpufreq/mt8173-cpufreq.c
>>
>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> index 0f9a2c3..97ed7dd 100644
>> --- a/drivers/cpufreq/Kconfig.arm
>> +++ b/drivers/cpufreq/Kconfig.arm
>> @@ -255,3 +255,9 @@ config ARM_PXA2xx_CPUFREQ
>> This add the CPUFreq driver support for Intel PXA2xx SOCs.
>>
>> If in doubt, say N.
>> +
>> +config ARM_MT8173_CPUFREQ
>> + bool "Mediatek MT8173 CPUFreq support"
>> + depends on ARCH_MEDIATEK && CPUFREQ_DT && REGULATOR
>> + help
>> + This adds the CPUFreq driver support for Mediatek MT8173 SoC.
>> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> index b3ca7b0..67b7f17 100644
>> --- a/drivers/cpufreq/Makefile
>> +++ b/drivers/cpufreq/Makefile
>> @@ -76,6 +76,7 @@ obj-$(CONFIG_ARM_SA1110_CPUFREQ)+= sa1110-cpufreq.o
>> obj-$(CONFIG_ARM_SPEAR_CPUFREQ) += spear-cpufreq.o
>> obj-$(CONFIG_ARM_TEGRA_CPUFREQ) += tegra-cpufreq.o
>> obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
>> +obj-$(CONFIG_ARM_MT8173_CPUFREQ) += mt8173-cpufreq.o
>>
>>
>> ##
>> # PowerPC platform drivers
>> diff --git a/drivers/cpufreq/mt8173-cpufreq.c
>> b/drivers/cpufreq/mt8173-cpufreq.c
>> new file mode 100644
>> index 000..b578c10
>> --- /dev/null
>> +++ b/drivers/cpufreq/mt8173-cpufreq.c
>> @@ -0,0 +1,459 @@
>> +/*
>> +* Copyright (c) 2015 Linaro.
>> +* Author: Pi-Cheng Chen
>> +*
>> +* This program is free software; you can redistribute it and/or modify
>> +* it under the terms of the GNU General Public License version 2 as
>> +* published by the Free Software Foundation.
>> +*
>> +* This program is distributed in the hope that it will be useful,
>> +* but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> +* GNU General Public License for more details.
>> +*/
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define CPUCLK_MUX_ARMPLL0x1
>> +#define CPUCLK_MUX_MAINPLL 0x2
>> +#define VOLT_SHIFT_LIMIT 15
>> +
>> +enum {
>> + LITTLE_CLUSTER = 0,
>> + BIG_CLUSTER,
>> + NR_CLUSTERS
>> +};
>> +
>> +static struct cluster_dvfs_info {
>> + int cpu;
>> + struct cpumask cpus;
>> + struct device *cpu_dev;
>> + struct regulator *proc_reg;
>> + struct regulator *sram_reg;
>> + int inter_volt;
>> + u32 volt_tol;
>> +} *dvfs_info;
>> +
>> +static unsigned long mainpll_freq;
>> +static void __iomem *clk_mux_regs;
>> +static spinlock_t lock;
>> +
>> +static void cpuclk_mux_set(int cluster, u32 sel)
>> +{
>> + u32 val;
>> + u32 mask = 0x3;
>> +
>> + if (cluster == BIG_CLUSTER) {
>> + mask <<= 2;
>> + sel <<= 2;
>> + }
>> +
>> + spin_lock();
>> +
>> + val = readl(clk_mux_regs);
>> + val = (val & ~mask) | sel;
>> + writel(val, clk_mux_regs);
>> +
>> + spin_unlock();
>> +}
>> +
>> +static int mt8173_cpufreq_voltage_step(struct cluster_dvfs_info *dvfs,
>> +unsigned long old_vproc,
>> +unsigned long new_vproc)
>> +{
>> + int cur_vsram, cur_vproc, target_volt, tol;
>> +
>> + if (old_vproc > new_vproc) {
>> + while (1) {
>> + cur_vsram = regulator_get_voltage(dvfs->sram_reg);
>> + if (cur_vsram - new_vproc < VOLT_SHIFT_LIMIT &&
>> + cur_vsram > new_vproc) {
>> + tol =
[PATCH RESEND V2 1/2] power: gpio-charger: balance enable/disable_irq_wake calls
enable_irq_wakeup returns 0 in case it correctly enabled the IRQ to generate the wakeup event (and thus resume should call disable_irq_wake). Currently gpio-charger driver has this logic inverted. Correct that thus correcting enable/disable_irq_wake() calls balance. Cc: sta...@vger.kernel.org Signed-off-by: Dmitry Eremin-Solenikov --- drivers/power/gpio-charger.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/power/gpio-charger.c b/drivers/power/gpio-charger.c index 7536933..e5deb11 100644 --- a/drivers/power/gpio-charger.c +++ b/drivers/power/gpio-charger.c @@ -168,7 +168,7 @@ static int gpio_charger_suspend(struct device *dev) if (device_may_wakeup(dev)) gpio_charger->wakeup_enabled = - enable_irq_wake(gpio_charger->irq); + !enable_irq_wake(gpio_charger->irq); return 0; } @@ -178,7 +178,7 @@ static int gpio_charger_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct gpio_charger *gpio_charger = platform_get_drvdata(pdev); - if (gpio_charger->wakeup_enabled) + if (device_may_wakeup(dev) && gpio_charger->wakeup_enabled) disable_irq_wake(gpio_charger->irq); power_supply_changed(_charger->charger); -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] acpica: utpredef: Remove some unused functions
Hi,
> From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
> Sent: Thursday, January 15, 2015 6:50 AM
>
> 2015-01-14 9:55 GMT+01:00 Zheng, Lv :
> > Hi, Rickard
> >
> > The functions below seem already marked by "ACPI_ASL_COMPILER ||
> > ACPI_HELP_APP".
> > How did you detect them as used functions?
Do you mean something like this?
Can Cppcheck automatically remove code blocks depending on the define settings
during preprocessor stage?
Thanks and best regards
-Lv
> >
> > Thanks
> > -Lv
> >
> >
> >> -Original Message-
> >> From: Rickard Strandqvist [mailto:rickard_strandqv...@spectrumdigital.se]
> >> Sent: Sunday, January 04, 2015 11:23 PM
> >> To: Moore, Robert; Zheng, Lv
> >> Cc: Rickard Strandqvist; Wysocki, Rafael J; Len Brown;
> >> linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
> >> Subject: [PATCH] acpica: utpredef: Remove some unused functions
> >>
> >> Removes some functions that are not used anywhere:
> >> acpi_ut_get_resource_bit_width() acpi_ut_display_predefined_method()
> >> acpi_ut_match_resource_name()
> >>
> >> This was partially found by using a static code analysis program called
> >> cppcheck.
> >>
> >> Signed-off-by: Rickard Strandqvist
> >> ---
> >> drivers/acpi/acpica/acutils.h |9 ---
> >> drivers/acpi/acpica/utpredef.c | 134
> >>
> >> 2 files changed, 143 deletions(-)
> >>
> >> diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h
> >> index 486d342..9b3fab1 100644
> >> --- a/drivers/acpi/acpica/acutils.h
> >> +++ b/drivers/acpi/acpica/acutils.h
> >> @@ -502,17 +502,8 @@ const union acpi_predefined_info
> >> *acpi_ut_get_next_predefined_method(const union
> >>
> >> const union acpi_predefined_info *acpi_ut_match_predefined_method(char
> >> *name);
> >>
> >> -const union acpi_predefined_info *acpi_ut_match_resource_name(char *name);
> >> -
> >> -void
> >> -acpi_ut_display_predefined_method(char *buffer,
> >> - const union acpi_predefined_info
> >> *this_name,
> >> - u8 multi_line);
> >> -
> >> void acpi_ut_get_expected_return_types(char *buffer, u32 expected_btypes);
> >>
> >> -u32 acpi_ut_get_resource_bit_width(char *buffer, u16 types);
> >> -
> >> /*
> >> * utstate - Generic state creation/cache routines
> >> */
> >> diff --git a/drivers/acpi/acpica/utpredef.c
> >> b/drivers/acpi/acpica/utpredef.c
> >> index db30caf..f1ff33c 100644
> >> --- a/drivers/acpi/acpica/utpredef.c
> >> +++ b/drivers/acpi/acpica/utpredef.c
> >> @@ -209,105 +209,6 @@ static const char *ut_resource_type_names[] = {
> >>
> >>
> >> /***
> >> *
> >> - * FUNCTION:acpi_ut_match_resource_name
> >> - *
> >> - * PARAMETERS: name- Name to find
> >> - *
> >> - * RETURN: Pointer to entry in the resource table. NULL indicates not
> >> - * found.
> >> - *
> >> - * DESCRIPTION: Check an object name against the predefined resource
> >> - * descriptor object list.
> >> - *
> >> -
> >> **/
> >> -
> >> -const union acpi_predefined_info *acpi_ut_match_resource_name(char *name)
> >> -{
> >> - const union acpi_predefined_info *this_name;
> >> -
> >> - /* Quick check for a predefined name, first character must be
> >> underscore */
> >> -
> >> - if (name[0] != '_') {
> >> - return (NULL);
> >> - }
> >> -
> >> - /* Search info table for a predefined method/object name */
> >> -
> >> - this_name = acpi_gbl_resource_names;
> >> - while (this_name->info.name[0]) {
> >> - if (ACPI_COMPARE_NAME(name, this_name->info.name)) {
> >> - return (this_name);
> >> - }
> >> -
> >> - this_name++;
> >> - }
> >> -
> >> - return (NULL); /* Not found */
> >> -}
> >> -
> >> -/***
> >> - *
> >> - * FUNCTION:acpi_ut_display_predefined_method
> >> - *
> >> - * PARAMETERS: buffer - Scratch buffer for this function
> >> - * this_name - Entry in the predefined method/name
> >> table
> >> - * multi_line - TRUE if output should be on >1 line
> >> - *
> >> - * RETURN: None
> >> - *
> >> - * DESCRIPTION: Display information about a predefined method. Number and
> >> - * type of the input arguments, and expected type(s) for the
> >> - * return value, if any.
> >> - *
> >> -
> >> **/
> >> -
> >> -void
> >> -acpi_ut_display_predefined_method(char *buffer,
> >> - const union acpi_predefined_info
> >> *this_name,
> >> - u8
[PATCH RESEND V2 2/2] power: collie_battery: support generating wakeup event
Teach collie_battery driver to communicate to the kernel that it can
generate wakeup events. Handle enabling/disabling wakeup on battery full
event in suspend/resume callbacks.
Signed-off-by: Dmitry Eremin-Solenikov
---
drivers/power/collie_battery.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/power/collie_battery.c b/drivers/power/collie_battery.c
index d02ae02..594e4db 100644
--- a/drivers/power/collie_battery.c
+++ b/drivers/power/collie_battery.c
@@ -26,6 +26,7 @@
static DEFINE_MUTEX(bat_lock); /* protects gpio pins */
static struct work_struct bat_work;
static struct ucb1x00 *ucb;
+static int wakeup_enabled;
struct collie_bat {
int status;
@@ -291,11 +292,21 @@ static int collie_bat_suspend(struct ucb1x00_dev *dev)
{
/* flush all pending status updates */
flush_work(_work);
+
+ if (device_may_wakeup(>ucb->dev) &&
+ collie_bat_main.status == POWER_SUPPLY_STATUS_CHARGING)
+ wakeup_enabled = !enable_irq_wake(gpio_to_irq(COLLIE_GPIO_CO));
+ else
+ wakeup_enabled = 0;
+
return 0;
}
static int collie_bat_resume(struct ucb1x00_dev *dev)
{
+ if (wakeup_enabled)
+ disable_irq_wake(gpio_to_irq(COLLIE_GPIO_CO));
+
/* things may have changed while we were away */
schedule_work(_work);
return 0;
@@ -334,10 +345,15 @@ static int collie_bat_probe(struct ucb1x00_dev *dev)
collie_bat_gpio_isr,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
"main full", _bat_main);
- if (!ret) {
- schedule_work(_work);
- return 0;
- }
+ if (ret)
+ goto err_irq;
+
+ device_init_wakeup(>dev, 1);
+ schedule_work(_work);
+
+ return 0;
+
+err_irq:
power_supply_unregister(_bat_bu.psy);
err_psy_reg_bu:
power_supply_unregister(_bat_main.psy);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] x86/entry changes for 3.20, round 1
Hi Ingo and Thomas, At Linus' suggestion, I'm trying out some maintainerish stuff for x86 entry code. Please consider pulling to an appropriate branch *after Paul sends his RCU pull request*, only if 734d16801349 is included in that pull request. If this goes well, maybe I'll submit a MAINTAINERS patch, too. IMPORTANT: This is based on an RCU change that you don't have yet. I think that Paul is planning on sending a pull request with that change fairly soon. The code in here would compile without that fix, but it would introduce a nasty regression, so, to avoid breaking bisection, I based this off of the relevant change in Paul's tree. (It's the very first change for 3.20 in his current queue.) If you want me to structure this differently, let me know. I may have one more entry pull request before the merge window if I can get my sysret stuff reviewed in time. Not sure yet. I may also be comfortable with some more of Denys' cleanups in time. The following changes since commit 734d16801349fbe951d2f780191d32c5b8a892d1: rcu: Make rcu_nmi_enter() handle nesting (2014-12-30 17:40:16 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git tags/pr-20150114-x86-entry for you to fetch changes up to f6f64681d9d87ded48a90b644b2991c6ee05da2d: x86: entry_64.S: fold SAVE_ARGS_IRQ macro into its sole user (2015-01-13 14:18:08 -0800) This is my accumulated x86 entry work, part 1, for 3.20. The meat of this is an IST rework. When an IST exception interrupts user space, we will handle it on the per-thread kernel stack instead of on the IST stack. This sounds messy, but it actually simplifies the IST entry/exit code, because it eliminates some ugly games we used to play in order to handle rescheduling, signal delivery, etc on the way out of an IST exception. The IST rework introduces proper context tracking to IST exception handlers. I haven't seen any bug reports, but the old code could have incorrectly treated an IST exception handler as an RCU extended quiescent state. The memory failure change (included in this pull request with Borislav and Tony's permission) eliminates a bunch of code that is no longer needed now that user memory failure handlers are called in process context. Finally, this includes a few on Denys' uncontroversial and Obviously Correct (tm) cleanups. The IST and memory failure changes have been in -next for a while. LKML references: IST rework: http://lkml.kernel.org/r/cover.1416604491.git.l...@amacapital.net Memory failure change: http://lkml.kernel.org/r/54ab2ffa301102c...@agluck-desk.sc.intel.com Denys' cleanups: http://lkml.kernel.org/r/1420927210-19738-1-git-send-email-dvlas...@redhat.com Andy Lutomirski (4): x86, entry: Switch stacks on a paranoid entry from userspace x86, traps: Track entry into and exit from IST context x86: Clean up current_stack_pointer x86, traps: Add ist_begin_non_atomic and ist_end_non_atomic Denys Vlasenko (3): x86: entry_64.S: delete unused code x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET x86: entry_64.S: fold SAVE_ARGS_IRQ macro into its sole user Tony Luck (1): x86, mce: Get rid of TIF_MCE_NOTIFY and associated mce tricks Documentation/x86/entry_64.txt | 18 ++- Documentation/x86/x86_64/kernel-stacks | 8 +- arch/x86/ia32/ia32entry.S | 4 +- arch/x86/include/asm/calling.h | 1 - arch/x86/include/asm/mce.h | 1 - arch/x86/include/asm/thread_info.h | 15 ++- arch/x86/include/asm/traps.h | 6 + arch/x86/kernel/cpu/mcheck/mce.c | 114 +- arch/x86/kernel/cpu/mcheck/p5.c| 6 + arch/x86/kernel/cpu/mcheck/winchip.c | 5 + arch/x86/kernel/entry_64.S | 208 ++--- arch/x86/kernel/irq_32.c | 13 +-- arch/x86/kernel/signal.c | 6 - arch/x86/kernel/traps.c| 108 + 14 files changed, 252 insertions(+), 261 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: entry-common: fix forgotten set of thread_info->syscall
On Thu, Jan 15, 2015 at 5:51 AM, Kees Cook wrote:
> On Tue, Jan 13, 2015 at 12:35 AM, Roman Peniaev wrote:
>> On Tue, Jan 13, 2015 at 3:39 AM, Will Deacon wrote:
>>> On Sun, Jan 11, 2015 at 02:32:30PM +, Roman Pen wrote:
thread_info->syscall is used only for ptrace, but syscall number
is also used by syscall_get_nr and returned to userspace by the
following proc file access:
$ cat /proc/self/syscall
0 0x3 0xbe928bd8 0x1000 0x0 0xac9e0 0x3 0xbe928bb4 0xb6f5dfbc
^
The first number is the syscall number, currently it is zero.
Patch fixes this:
$ cat /proc/self/syscall
3 0x3 0xbefc7bd8 0x1000 0x0 0xac9e0 0x3 0xbefc7bb4 0xb6e82fbc
^
Right, read syscall
>>>
>>> Yes, it seems that despite requiring CONFIG_HAVE_ARCH_TRACEHOOK,
>>> the /proc code requires syscall_get_nr to work regardless of
>>> TIF_SYSCALL_TRACE.
>>>
Signed-off-by: Roman Pen
Cc: Russell King
Cc: Marc Zyngier
Cc: Catalin Marinas
Cc: Christoffer Dall
Cc: Stefano Stabellini
Cc: Sekhar Nori
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
---
arch/arm/kernel/asm-offsets.c | 1 +
arch/arm/kernel/entry-common.S | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index 2d2d608..6911bad 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -70,6 +70,7 @@ int main(void)
DEFINE(TI_CPU, offsetof(struct thread_info, cpu));
DEFINE(TI_CPU_DOMAIN, offsetof(struct thread_info,
cpu_domain));
DEFINE(TI_CPU_SAVE,offsetof(struct thread_info,
cpu_context));
+ DEFINE(TI_SYSCALL, offsetof(struct thread_info, syscall));
DEFINE(TI_USED_CP, offsetof(struct thread_info, used_cp));
DEFINE(TI_TP_VALUE,offsetof(struct thread_info,
tp_value));
DEFINE(TI_FPSTATE, offsetof(struct thread_info, fpstate));
diff --git a/arch/arm/kernel/entry-common.S
b/arch/arm/kernel/entry-common.S
index f8ccc21..89452ff 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -189,6 +189,7 @@ ENTRY(vector_swi)
#endif
local_restart:
+ str scno, [tsk, #TI_SYSCALL]@ set syscall number
ldr r10, [tsk, #TI_FLAGS] @ check for syscall tracing
stmdb sp!, {r4, r5} @ push fifth and sixth args
>>>
>>> Do we definitely want to update scno on syscall restarting?
>>
>>
>> Good question.
>>
>> First thing to mention is __sys_trace will trace 'restart_syscall',
>> not the real syscall we are going to restart.
>>
>> E.g. in test application we do infinite poll and then send STOP and
>> CONT to this app:
>>
>> test-243 [002] ...1 1792.067726: sys_enter: NR 168 (0, 0,
>> , 0, 0, 0)
>> test-243 [002] ...1 1802.299073: sys_exit: NR 168 = -516
>> test-243 [004] ...1 1814.716264: sys_enter: NR 0 (0, 0,
>> , 0, 0, 0)
>> test-243 [004] ...1 2183.687225: sys_exit: NR 0 = -516
>>
>> the poll was restarted and trace shows that we are in restart_syscall.
>>
>> Is that expected?
>>
>> And the second thing is that my next patch did some tweaks in
>> 'syscall_trace_enter', where we take scno not from param we passed,
>> but from thread_info->syscall we previously set.
>>
>> So, regarding your question, if I set scno only once - I will break
>> previous behavior, and __sys_trace will trace the syscall we restarted.
>>
>> And I think this is what we need, because according to the
>> 'syscall_trace_enter' code we do 'secure_computing' and
>> 'audit_syscall_entry', which definitely expect original syscall, not
>> the 'restart_syscall'.
>
> Seccomp expects to see the __NR_restart_syscall syscall, since it
> interposes the syscall entry points.
Aha, thanks. So I should not break anything.
--
Roman
>
> -Kees
>
>>
>>
>> --
>> Roman
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> --
> Kees Cook
> Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] pxa_timer: fix session missmatch warning
Fix the following warning:
WARNING: drivers/clocksource/built-in.o(.text.unlikely+0x70): Section mismatch
in reference from the function pxa_timer_common_init() to the function
.init.text:clocksource_mmio_init()
The function pxa_timer_common_init() references
the function __init clocksource_mmio_init().
This is often because pxa_timer_common_init lacks a __init
annotation or the annotation of clocksource_mmio_init is wrong.
Signed-off-by: Dmitry Eremin-Solenikov
---
drivers/clocksource/pxa_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
index 941f3f3..d9438af 100644
--- a/drivers/clocksource/pxa_timer.c
+++ b/drivers/clocksource/pxa_timer.c
@@ -163,7 +163,7 @@ static struct irqaction pxa_ost0_irq = {
.dev_id = _pxa_osmr0,
};
-static void pxa_timer_common_init(int irq, unsigned long clock_tick_rate)
+static void __init pxa_timer_common_init(int irq, unsigned long
clock_tick_rate)
{
timer_writel(0, OIER);
timer_writel(OSSR_M0 | OSSR_M1 | OSSR_M2 | OSSR_M3, OSSR);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 5/9] ARM: dts: Add memory bus node for Exynos4x12
This patch adds the memory bus node for Exynos4x12 SoC. Exynos4x12 SoC has
two memory bus to translate data between DRAM and eMMC/sub-IPs.
Following list specifies the detailed relation between memory bus clock and DMC
IP in MIF (Memory Interface) block:
- DMC/ACP clock : DMC (Dynamic Memory Controller)
Following list specifies the detailed relation between memory bus clock and
sub-IPs in INT (Internal) block:
- ACLK100 clock : PERIL/PERIR/MFC(PCLK)
- ACLK160 clock : CAM/TV/LCD
- ACLK133 clock : FSYS
- GDL/GDR clock : leftbus/rightbus
- SCLK_MFC clock : MFC
Cc: Kukjin Kim
Cc: Myungjoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
Acked-by: Myungjoo Ham
---
arch/arm/boot/dts/exynos4x12.dtsi | 121 ++
1 file changed, 121 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 93b7040..44f6272 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -31,6 +31,127 @@
mshc0 = _0;
};
+ memory_bus_mif: memory_bus@0 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 40 110
+ 20 100
+ 16 95
+ 133000 95
+ 10 95>;
+ status = "disabled";
+
+ blocks {
+ dmc_block: memory_bus_block1 {
+ clocks = < CLK_DIV_DMC>;
+ clock-names = "memory-bus";
+ frequency = <
+ 40
+ 20
+ 16
+ 133000
+ 10>;
+ };
+
+ acp_block: memory_bus_block2 {
+ clocks = < CLK_DIV_ACP>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 133000
+ 133000
+ 10>;
+ };
+
+ c2c_block: memory_bus_block3 {
+ clocks = < CLK_DIV_C2C>;
+ clock-names = "memory-bus";
+ frequency = <
+ 40
+ 20
+ 16
+ 133000
+ 10>;
+ };
+ };
+ };
+
+ memory_bus_int: memory_bus@1 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 20 100
+ 16 95
+ 133000 925000
+ 10 90>;
+
+ status = "disabled";
+
+ blocks {
+ peri_block: memory_bus_block1 {
+ clocks = < CLK_ACLK100>;
+ clock-names = "memory-bus";
+ frequency = <
+ 10
+ 10
+ 10
+ 10>;
+ };
+
+ fsys_block: memory_bus_block2 {
+ clocks = < CLK_ACLK133>;
+ clock-names = "memory-bus";
+ frequency = <
+ 133000
+ 133000
+ 10
+ 10>;
+ };
+
+ display_block: memory_bus_block3 {
+ clocks = < CLK_ACLK160>;
+ clock-names = "memory-bus";
+ frequency = <
+ 16
+ 16
+ 133000
+ 10>;
+ };
+
+ leftbus_block: memory_bus_block4 {
+ clocks = < CLK_DIV_GDL>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 133000
+
[PATCH v4 4/9] clk: samsung: exynos4: Add divider clock id for memory bus frequency
This patch adds the divider clock id for Exynos4 memory bus frequency.
The clock id is used fo DVFS (Dynamic Voltage/Frequency Scaling)
feature of exynos memory bus frequency.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
---
drivers/clk/samsung/clk-exynos4.c | 10 +-
include/dt-bindings/clock/exynos4.h | 7 ++-
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 88e8c6b..51462e8 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -703,12 +703,12 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
__initdata = {
/* list of divider clocks supported in all exynos4 soc's */
static struct samsung_div_clock exynos4_div_clks[] __initdata = {
- DIV(0, "div_gdl", "mout_gdl", DIV_LEFTBUS, 0, 3),
+ DIV(CLK_DIV_GDL, "div_gdl", "mout_gdl", DIV_LEFTBUS, 0, 3),
DIV(0, "div_gpl", "div_gdl", DIV_LEFTBUS, 4, 3),
DIV(0, "div_clkout_leftbus", "mout_clkout_leftbus",
CLKOUT_CMU_LEFTBUS, 8, 6),
- DIV(0, "div_gdr", "mout_gdr", DIV_RIGHTBUS, 0, 3),
+ DIV(CLK_DIV_GDR, "div_gdr", "mout_gdr", DIV_RIGHTBUS, 0, 3),
DIV(0, "div_gpr", "div_gdr", DIV_RIGHTBUS, 4, 3),
DIV(0, "div_clkout_rightbus", "mout_clkout_rightbus",
CLKOUT_CMU_RIGHTBUS, 8, 6),
@@ -781,10 +781,10 @@ static struct samsung_div_clock exynos4_div_clks[]
__initdata = {
CLK_SET_RATE_PARENT, 0),
DIV(0, "div_clkout_top", "mout_clkout_top", CLKOUT_CMU_TOP, 8, 6),
- DIV(0, "div_acp", "mout_dmc_bus", DIV_DMC0, 0, 3),
+ DIV(CLK_DIV_ACP, "div_acp", "mout_dmc_bus", DIV_DMC0, 0, 3),
DIV(0, "div_acp_pclk", "div_acp", DIV_DMC0, 4, 3),
DIV(0, "div_dphy", "mout_dphy", DIV_DMC0, 8, 3),
- DIV(0, "div_dmc", "mout_dmc_bus", DIV_DMC0, 12, 3),
+ DIV(CLK_DIV_DMC, "div_dmc", "mout_dmc_bus", DIV_DMC0, 12, 3),
DIV(0, "div_dmcd", "div_dmc", DIV_DMC0, 16, 3),
DIV(0, "div_dmcp", "div_dmcd", DIV_DMC0, 20, 3),
DIV(0, "div_pwi", "mout_pwi", DIV_DMC1, 8, 4),
@@ -829,7 +829,7 @@ static struct samsung_div_clock exynos4x12_div_clks[]
__initdata = {
DIV_F(CLK_DIV_MCUISP1, "div_mcuisp1", "div_mcuisp0", E4X12_DIV_ISP1,
8, 3, CLK_GET_RATE_NOCACHE, 0),
DIV(CLK_SCLK_FIMG2D, "sclk_fimg2d", "mout_g2d", DIV_DMC1, 0, 4),
- DIV(0, "div_c2c", "mout_c2c", DIV_DMC1, 4, 3),
+ DIV(CLK_DIV_C2C, "div_c2c", "mout_c2c", DIV_DMC1, 4, 3),
DIV(0, "div_c2c_aclk", "div_c2c", DIV_DMC1, 12, 3),
};
diff --git a/include/dt-bindings/clock/exynos4.h
b/include/dt-bindings/clock/exynos4.h
index 34fe28c..c4b1676 100644
--- a/include/dt-bindings/clock/exynos4.h
+++ b/include/dt-bindings/clock/exynos4.h
@@ -262,8 +262,13 @@
#define CLK_DIV_MCUISP1453 /* Exynos4x12 only */
#define CLK_DIV_ACLK200454 /* Exynos4x12 only */
#define CLK_DIV_ACLK400_MCUISP 455 /* Exynos4x12 only */
+#define CLK_DIV_ACP456
+#define CLK_DIV_DMC457
+#define CLK_DIV_C2C458 /* Exynos4x12 only */
+#define CLK_DIV_GDL459
+#define CLK_DIV_GDR460
/* must be greater than maximal clock id */
-#define CLK_NR_CLKS456
+#define CLK_NR_CLKS461
#endif /* _DT_BINDINGS_CLOCK_EXYNOS_4_H */
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/9] devfreq: exynos: Add generic exynos memory bus frequency driver
This patch adds the generic exynos bus frequency driver for memory bus
with DEVFREQ framework. The Samsung Exynos SoCs have the common architecture
for memory bus between DRAM memory and MMC/sub IP in SoC. This driver can
support the memory bus frequency driver for Exynos SoCs.
Each memory bus block has a clock for memory bus speed and frequency
table which is changed according to the utilization of memory bus on runtime.
And then each memory bus group has the one more memory bus blocks and
OPP table (including frequency and voltage), regulator, devfreq-event
devices.
There are a little difference about the number of memory bus because each Exynos
SoC have the different sub-IP and different memory bus speed. In spite of this
difference among Exynos SoCs, we can support almost Exynos SoC by adding
unique data of memory bus to devicetree file.
Cc: Myungjoo Ham
Cc: Kyungmin Park
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/Kconfig | 15 +
drivers/devfreq/Makefile| 1 +
drivers/devfreq/exynos/Makefile | 1 +
drivers/devfreq/exynos/exynos-bus.c | 598
4 files changed, 615 insertions(+)
create mode 100644 drivers/devfreq/exynos/exynos-bus.c
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 21f8f17..cb66867 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -65,6 +65,21 @@ config DEVFREQ_GOV_USERSPACE
comment "DEVFREQ Drivers"
+config ARM_EXYNOS_BUS_DEVFREQ
+ bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
+ depends on ARCH_EXYNOS
+ select DEVFREQ_GOV_SIMPLE_ONDEMAND
+ select DEVFREQ_EVENT_EXYNOS_PPMU
+ select PM_DEVFREQ_EVENT
+ select PM_OPP
+ help
+ This adds the common DEVFREQ driver for Exynos Memory bus. Exynos
+ Memory bus has one more group of memory bus (e.g, MIF and INT block).
+ Each memory bus group could contain many memoby bus block. It reads
+ PPMU counters of memory controllers by using DEVFREQ-event device
+ and adjusts the operating frequencies and voltages with OPP support.
+ This does not yet operate with optimal voltages.
+
config ARM_EXYNOS4_BUS_DEVFREQ
bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) &&
!ARCH_MULTIPLATFORM
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index c449336..29a04c5 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o
obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o
# DEVFREQ Drivers
+obj-$(CONFIG_ARCH_EXYNOS) += exynos/
obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos/
obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos/
diff --git a/drivers/devfreq/exynos/Makefile b/drivers/devfreq/exynos/Makefile
index 49bc917..4ec06d3 100644
--- a/drivers/devfreq/exynos/Makefile
+++ b/drivers/devfreq/exynos/Makefile
@@ -1,3 +1,4 @@
# Exynos DEVFREQ Drivers
+obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos_ppmu.o exynos4_bus.o
obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos_ppmu.o exynos5_bus.o
diff --git a/drivers/devfreq/exynos/exynos-bus.c
b/drivers/devfreq/exynos/exynos-bus.c
new file mode 100644
index 000..b348956
--- /dev/null
+++ b/drivers/devfreq/exynos/exynos-bus.c
@@ -0,0 +1,598 @@
+/*
+ * Generic Exynos Memory Bus Frequency driver with DEVFREQ Framework
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author : Chanwoo Choi
+ *
+ * This driver is based on exynos4_bus.c, which was written
+ * by MyungJoo Ham , Samsung Electronics.
+ *
+ * This driver support Exynos Memory Bus frequency feature by using in DEVFREQ
+ * framework. This version supprots Exynos3250/Exynos4 series/Exynos5260 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEFAULT_SATURATION_RATIO 40
+#define SAFEVOLT 5
+
+struct exynos_memory_bus_opp {
+ unsigned long rate;
+ unsigned long volt;
+};
+
+struct exynos_memory_bus_block {
+ struct clk *clk;
+ struct exynos_memory_bus_opp *freq_table;
+};
+
+struct exynos_memory_bus {
+ /* devfreq device to monitor and control memory bus group */
+ struct device *dev;
+ struct devfreq *devfreq;
+
+ struct exynos_memory_bus_opp *freq_table;
+ unsigned int freq_count;
+ struct regulator *regulator;
+ struct mutex lock;
+ int ratio;
+
+ struct exynos_memory_bus_opp curr_opp;
+
+ struct exynos_memory_bus_block *block;
+
[PATCH v4 0/9] devfreq: Add generic exynos memory-bus frequency driver
This patch-set adds the generic exynos bus frequency driver for memory bus
with DEVFREQ framework. The Samsung Exynos SoCs have the common architecture
for memory bus between DRAM memory and MMC/sub IP in SoC. This driver can
support the memory bus frequency driver for Exynos SoCs.
Each memory bus block has a clock for memory bus speed and frequency
table which is changed according to the utilization of memory bus on runtime.
And then each memory bus group has the one more memory bus blocks and
OPP table (including frequency and voltage), regulator, devfreq-event
devices.
There are a little difference about the number of memory bus because each Exynos
SoC have the different sub-IP and different memory bus speed. In spite of this
difference among Exynos SoCs, we can support almost Exynos SoC by adding
unique data of memory bus to devicetree file.
Depend on:
- [PATCHv8 0/9] devfreq: Add devfreq-event class to provide raw data for
devfreq device
: https://lkml.org/lkml/2015/1/7/795
Changelog:
Changes from v3:
(https://lkml.org/lkml/2015/1/7/872)
- Change the driver name and path by comment
: drivers/devfreq/exynos-busfreq.c -> drivers/devfreq/exynos/exynos-bus.c
- Disable regulator when entering suspend state in exynos-bus.c
and enable it after wake-up from suspend state.
- Add 'exynos,saturation-ratio' property to calibrate the performance count
against cycle count.
- Add new patch to remove unused old driver
: drivers/devfreq/exynos/exynos4_bus.{c|h}
- Clean-up code for minor issue
- Add acked tag by Myungjoo Ham (DEVFREQ maintainer)
Changes from v2:
(https://lkml.org/lkml/2014/12/31/2)
- Support the memory bus frequency feature for Exynos3250-based Monk board
- Fix build warning about variable uninitialized
Changes from v1:
(https://lkml.org/lkml/2014/12/23/178)
- This patchset is rebased on v3.19-rc2.
- Fix bug after wake-up from suspend state. If devfreq device fail to get event,
exynos-busfreq retry to set the event for starting.
- Add memory bus group of Exynos4x12/Exynos4210
- Add divider clock id for Exynos4 memory bus frequency
- Support memory bus frequency driver on Exynos4412-based TRATS2 board
- This patch-set has the dependency on following patch-set[1]:
[1] [PATCHv6 0/9] devfreq: Add devfreq-event class to provide raw data for
devfreq device
: https://lkml.org/lkml/2014/12/28/139
Chanwoo Choi (9):
devfreq: exynos: Add generic exynos memory bus frequency driver
devfreq: exynos: Add documentation for generic exynos memory bus frequency
driver
ARM: dts: Add memory bus node for Exynos3250
clk: samsung: exynos4: Add divider clock id for memory bus frequency
ARM: dts: Add memory bus node for Exynos4x12
ARM: dts: Add memory bus node for Exynos4210
ARM: dts: Add the support for exynos busfreq on Exynos3250-based Rinato/Monk
board
ARM: dts: Add the support for exynos busfreq on Exynos4412-based TRATS2 board
devfreq: exynos: Remove unused exynos4 memory busfreq driver
.../devicetree/bindings/devfreq/exynos-bus.txt | 188
arch/arm/boot/dts/exynos3250-monk.dts | 12 +
arch/arm/boot/dts/exynos3250-rinato.dts| 12 +
arch/arm/boot/dts/exynos3250.dtsi | 125 +++
arch/arm/boot/dts/exynos4210.dtsi | 93 ++
arch/arm/boot/dts/exynos4412-trats2.dts| 12 +
arch/arm/boot/dts/exynos4x12.dtsi | 121 +++
drivers/clk/samsung/clk-exynos4.c | 10 +-
drivers/devfreq/Kconfig| 17 +-
drivers/devfreq/Makefile |1 +
drivers/devfreq/exynos/Makefile|2 +-
drivers/devfreq/exynos/exynos-bus.c| 598 +++
drivers/devfreq/exynos/exynos4_bus.c | 1055
drivers/devfreq/exynos/exynos4_bus.h | 110 --
include/dt-bindings/clock/exynos4.h|7 +-
15 files changed, 1184 insertions(+), 1179 deletions(-)
create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
create mode 100644 drivers/devfreq/exynos/exynos-bus.c
delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] MAINTAINERS: update brcmstb entries
On 14/01/15 16:13, Brian Norris wrote: > Since I found this in my inbox during garbage collection... > > On Tue, Nov 4, 2014 at 3:23 PM, Florian Fainelli wrote: >> On 11/04/2014 02:56 PM, Grant Likely wrote: >>> On Tue, Nov 4, 2014 at 10:48 PM, Florian Fainelli >>> wrote: On 11/04/2014 12:45 PM, Olof Johansson wrote: > On Tue, Oct 28, 2014 at 11:44:54AM -0700, Florian Fainelli wrote: >> Remove Marc Carino from the brcmstb maintainers list and add Gregory >> Fong and myself as new maintainers for the brcmstb platform. >> >> Signed-off-by: Florian Fainelli >> --- >> MAINTAINERS | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index dab92a78d1d5..33a8b31e03f0 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -2093,8 +2093,9 @@ F: arch/arm/mach-bcm/bcm63xx.c >> F: arch/arm/include/debug/bcm63xx.S >> >> BROADCOM BCM7XXX ARM ARCHITECTURE >> -M: Marc Carino >> M: Brian Norris >> +M: Gregory Fong >> +M: Florian Fainelli > > You're removing Marc here, but I don't see an ack from him, nor has > he been cc:d on the patch. It's common practice for people to agree to > being removed. Can you please make sure we get an ack from him on this, > maybe by reposting and cc:ing him? Marc is no longer with Broadcom, do you still want him to ack this? >>> >>> Yes, absolutely. Maintainership is entrusted to an individual, not >>> their employer. We've had many situations where someone has continued >>> to maintain a platform even after changing employment. So, yes, there >>> needs to be an ack from Marc. >> >> He is CC'd, now. Marc, please Ack this if you are okay with the change. > > Can we add a "Not-nacked-by" tag and proceed? Marc is obviously not > involved here any more. I figure removing expired maintainers should > be a little easier than removing SCOTUS judges. You'd think so right? How about this plan: unless Marc replies otherwise, I submit a MAINTAINERS update removing him for the v3.21 kernel release? -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 6/9] ARM: dts: Add memory bus node for Exynos4210
This patch adds the memory bus node for Exynos4210 SoC. Exynos4210 SoC has
one memory bus to translate data between DRAM and eMMC/sub-IPs because
Exynos4210 must need only one regulator for memory bus.
Following list specifies the detailed relation between memory bus clock and
sub-IPs:
- DMC/ACP clock : DMC (Dynamic Memory Controller)
- ACLK200 clock : LCD0
- ACLK100 clock : PERIL/PERIR/MFC(PCLK)
- ACLK160 clock : CAM/TV/LCD0/LCD1
- ACLK133 clock : FSYS/GPS
- GDL/GDR clock : leftbus/rightbus
- SCLK_MFC clock : MFC
Cc: Kukjin Kim
Cc: Myungjoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4210.dtsi | 93 +++
1 file changed, 93 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index b2598de..c039409 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -48,6 +48,99 @@
};
};
+ memory_bus: memory_bus@0 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 40 115
+ 267000 105
+ 133000 1025000>;
+ status = "disabled";
+
+ blocks {
+ dmc_block: memory_bus_block1 {
+ clocks = < CLK_DIV_DMC>;
+ clock-names = "memory-bus";
+ frequency = <
+ 40
+ 267000
+ 133000>;
+ };
+
+ acp_block: memory_bus_block2 {
+ clocks = < CLK_DIV_ACP>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 133000>;
+ };
+
+ peri_block: memory_bus_block3 {
+ clocks = < CLK_ACLK100>;
+ clock-names = "memory-bus";
+ frequency = <
+ 10
+ 10
+ 10>;
+ };
+
+ fsys_block: memory_bus_block4 {
+ clocks = < CLK_ACLK133>;
+ clock-names = "memory-bus";
+ frequency = <
+ 133000
+ 133000
+ 10>;
+ };
+
+ display_block: memory_bus_block5 {
+ clocks = < CLK_ACLK160>;
+ clock-names = "memory-bus";
+ frequency = <
+ 16
+ 133000
+ 10>;
+ };
+
+ lcd0_block: memory_bus_block6 {
+ clocks = < CLK_ACLK200>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 10>;
+ };
+
+ leftbus_block: memory_bus_block7 {
+ clocks = < CLK_DIV_GDL>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 10>;
+ };
+
+ rightbus_block: memory_bus_block8 {
+ clocks = < CLK_DIV_GDR>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 10>;
+ };
+
+ mfc_block: memory_bus_block9 {
+ clocks = < CLK_SCLK_MFC>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 10>;
+ };
+ };
+ };
+
pmu_system_controller: system-controller@1002 {
clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
[PATCH v4 3/9] ARM: dts: Add memory bus node for Exynos3250
This patch adds the memory bus node for Exynos3250 SoC. Exynos3250 has
following memory buses to translate data between DRAM and eMMC/sub-IPs.
Following list specifies the detailed relation between memory bus clock and DMC
IP in MIF (Memory Interface) block:
- DMC clock : DMC (Dynamic Memory Controller)
Following list specifies the detailed relation between memory bus clock and
sub-IPs in INT (Internal) block:
- ACLK100 clock : PERIL
- ACLK160 clock : LCD0
- ACLK200 clock : FSYS
- ACLK266 clock : ISP
- GDL/GDR clock : leftbus/rightbus
- SCLK_MFC clock : MFC
Cc: Kukjin Kim
Cc: Myungjoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
Acked-by: Myungjoo Ham
---
arch/arm/boot/dts/exynos3250.dtsi | 125 ++
1 file changed, 125 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 9ed1260..3eaed53 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -99,6 +99,131 @@
};
};
+ memory_bus_mif: memory_bus@0 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 40 875000
+ 20 80
+ 133000 80
+ 10 80
+ 5 80>;
+ status = "disabled";
+
+ blocks {
+ dmc_block: memory_bus_block1 {
+ clocks = <_dmc CLK_DIV_DMC>;
+ clock-names = "memory-bus";
+ frequency = <
+ 40
+ 20
+ 133000
+ 10
+ 5>;
+ };
+ };
+ };
+
+ memory_bus_int: memory_bus@1 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 40 95
+ 20 95
+ 133000 925000
+ 10 85
+ 8 85
+ 5 85>;
+
+ status = "disabled";
+
+ blocks {
+ peril_block: memory_bus_block1 {
+ clocks = < CLK_DIV_ACLK_100>;
+ clock-names = "memory-bus";
+ frequency = <
+ 10
+ 10
+ 10
+ 10
+ 5
+ 5>;
+ };
+
+ lcd0_block: memory_bus_block2 {
+ clocks = < CLK_DIV_ACLK_160>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 10
+ 8
+ 8
+ 5>;
+ };
+
+ fsys_block: memory_bus_block3 {
+ clocks = < CLK_DIV_ACLK_200>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 20
+ 10
+ 8
+ 5
+ 5>;
+ };
+
+ isp_block: memory_bus_block4 {
+ clocks = < CLK_DIV_ACLK_266>;
+ clock-names = "memory-bus";
+ frequency = <
+ 30
+ 20
+ 133000
+
[PATCH v4 7/9] ARM: dts: Add the support for exynos busfreq on Exynos3250-based Rinato/Monk board
This patch adds the Exynos3250 memory-bus node which includes the regulator
and devfreq-event phandle. The devfreq-event phandle is used for the
governor of devfreq device and provide the current usage state of
MIF (Memory Interface) / INT (Internal) memory bus group.
Cc: Kukjin Kim
Cc: Myungjoo Ham
Cc: Kyungmin Park
Cc: Youngjun Cho
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos3250-monk.dts | 12
arch/arm/boot/dts/exynos3250-rinato.dts | 12
2 files changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
index fcceb59..efadb16 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -460,6 +460,18 @@
};
};
+_bus_mif {
+ devfreq-events = <_dmc0_3>, <_dmc1_3>;
+ vdd-mem-supply = <_reg>;
+ status = "okay";
+};
+
+_bus_int {
+ devfreq-events = <_leftbus_3>, <_rightbus_3>;
+ vdd-mem-supply = <_reg>;
+ status = "okay";
+};
+
{
clock-frequency = <2400>;
};
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 9dd1ce1..cf800ed 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -635,6 +635,18 @@
};
};
+_bus_mif {
+ devfreq-events = <_dmc0_3>, <_dmc1_3>;
+ vdd-mem-supply = <_reg>;
+ status = "okay";
+};
+
+_bus_int {
+ devfreq-events = <_leftbus_3>, <_rightbus_3>;
+ vdd-mem-supply = <_reg>;
+ status = "okay";
+};
+
{
clock-frequency = <2400>;
};
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 9/9] devfreq: exynos: Remove unused exynos4 memory busfreq driver
This patch removes the unused exynos4 memory busfreq driver by adding generic
exynos memory bus frequency driver.
Cc: Myungjoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/Kconfig | 12 -
drivers/devfreq/exynos/Makefile |1 -
drivers/devfreq/exynos/exynos4_bus.c | 1055 --
drivers/devfreq/exynos/exynos4_bus.h | 110
4 files changed, 1178 deletions(-)
delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index cb66867..f7e5f5b 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -80,18 +80,6 @@ config ARM_EXYNOS_BUS_DEVFREQ
and adjusts the operating frequencies and voltages with OPP support.
This does not yet operate with optimal voltages.
-config ARM_EXYNOS4_BUS_DEVFREQ
- bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
- depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) &&
!ARCH_MULTIPLATFORM
- select DEVFREQ_GOV_SIMPLE_ONDEMAND
- select PM_OPP
- help
- This adds the DEVFREQ driver for Exynos4210 memory bus (vdd_int)
- and Exynos4212/4412 memory interface and bus (vdd_mif + vdd_int).
- It reads PPMU counters of memory controllers and adjusts
- the operating frequencies and voltages with OPP support.
- This does not yet operate with optimal voltages.
-
config ARM_EXYNOS5_BUS_DEVFREQ
tristate "ARM Exynos5250 Bus DEVFREQ Driver"
depends on SOC_EXYNOS5250
diff --git a/drivers/devfreq/exynos/Makefile b/drivers/devfreq/exynos/Makefile
index 4ec06d3..3f806c7 100644
--- a/drivers/devfreq/exynos/Makefile
+++ b/drivers/devfreq/exynos/Makefile
@@ -1,4 +1,3 @@
# Exynos DEVFREQ Drivers
obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
-obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos_ppmu.o exynos4_bus.o
obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos_ppmu.o exynos5_bus.o
diff --git a/drivers/devfreq/exynos/exynos4_bus.c
b/drivers/devfreq/exynos/exynos4_bus.c
deleted file mode 100644
index da95092..000
--- a/drivers/devfreq/exynos/exynos4_bus.c
+++ /dev/null
@@ -1,1055 +0,0 @@
-/* drivers/devfreq/exynos4210_memorybus.c
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com/
- * MyungJoo Ham
- *
- * EXYNOS4 - Memory/Bus clock frequency scaling support in DEVFREQ framework
- * This version supports EXYNOS4210 only. This changes bus frequencies
- * and vddint voltages. Exynos4412/4212 should be able to be supported
- * with minor modifications.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#include "exynos_ppmu.h"
-#include "exynos4_bus.h"
-
-#define MAX_SAFEVOLT 120 /* 1.2V */
-
-enum exynos4_busf_type {
- TYPE_BUSF_EXYNOS4210,
- TYPE_BUSF_EXYNOS4x12,
-};
-
-/* Assume that the bus is saturated if the utilization is 40% */
-#define BUS_SATURATION_RATIO 40
-
-enum busclk_level_idx {
- LV_0 = 0,
- LV_1,
- LV_2,
- LV_3,
- LV_4,
- _LV_END
-};
-
-enum exynos_ppmu_idx {
- PPMU_DMC0,
- PPMU_DMC1,
- PPMU_END,
-};
-
-#define EX4210_LV_MAX LV_2
-#define EX4x12_LV_MAX LV_4
-#define EX4210_LV_NUM (LV_2 + 1)
-#define EX4x12_LV_NUM (LV_4 + 1)
-
-/**
- * struct busfreq_opp_info - opp information for bus
- * @rate: Frequency in hertz
- * @volt: Voltage in microvolts corresponding to this OPP
- */
-struct busfreq_opp_info {
- unsigned long rate;
- unsigned long volt;
-};
-
-struct busfreq_data {
- enum exynos4_busf_type type;
- struct device *dev;
- struct devfreq *devfreq;
- bool disabled;
- struct regulator *vdd_int;
- struct regulator *vdd_mif; /* Exynos4412/4212 only */
- struct busfreq_opp_info curr_oppinfo;
- struct busfreq_ppmu_data ppmu_data;
-
- struct notifier_block pm_notifier;
- struct mutex lock;
-
- /* Dividers calculated at boot/probe-time */
- unsigned int dmc_divtable[_LV_END]; /* DMC0 */
- unsigned int top_divtable[_LV_END];
-};
-
-/* 4210 controls clock of mif and voltage of int */
-static struct bus_opp_table exynos4210_busclk_table[] = {
- {LV_0, 40, 115},
- {LV_1, 267000, 105},
- {LV_2, 133000, 1025000},
- {0, 0, 0},
-};
-
-/*
- * MIF is the main control knob clock for Exynos4x12 MIF/INT
- * clock and voltage of both mif/int are controlled.
- */
-static struct bus_opp_table exynos4x12_mifclk_table[] = {
- {LV_0, 40, 110},
- {LV_1, 267000, 100},
- {LV_2, 16, 95},
-
[PATCH v4 2/9] devfreq: exynos: Add documentation for generic exynos memory bus frequency driver
This patch adds the documentation for generic exynos memory bus frequency
driver.
Cc: MyungJoo Ham
Cc: Kyungmin Park
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: MyungJoo Ham
---
.../devicetree/bindings/devfreq/exynos-bus.txt | 188 +
1 file changed, 188 insertions(+)
create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
new file mode 100644
index 000..6323dcf
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -0,0 +1,188 @@
+
+* Generic Exynos Memory Bus device
+
+The Samsung Exynos SoCs have many memory buses for data transfer between DRAM
+memory and MMC/sub-IP in SoC. Almost Exynos SoCs have the common architecture
+for memory buses. Generally, Exynos SoC express the memory bus by using memory
+bus group and block. The memory bus group has one more memory bus blocks and
+OPP table (including frequency and voltage for DVFS), regulator, devfreq-event
+devices. Each memory bus block has a clock for own memory bus speen and
+frequency table for DVFS. There are a little different among Exynos SoCs
+because each Exynos SoC has the different sub-IP and differnt memory bus.
+So, this difference should be specified in devicetree file.
+
+Required properties for memory bus group:
+- compatible: Should be "samsung,exynos-memory-bus".
+- operating-points: the OPP table including frequency/voltage information to
+ support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+- devfreq-events: the devfreq-event device to monitor the curret state of
+ memory bus group.
+- vdd-mem-supply: the regulator to provide memory bus group with the voltage.
+
+Optional properties for memory bus group:
+- exynos,saturation-ratio: the percentage value which is used to calibrate
+ the memory performance count againt memory cycle count.
+
+Required properties for memory bus block:
+- clock-names : the name of clock used by the memory bus, "memory-bus".
+- clocks : phandles for clock specified in "clock-names" property.
+- #clock-cells: should be 1.
+- frequency: the frequency table to support DVFS feature.
+
+Example1 : Memory bus group/block in exynos3250.dtsi are listed below.
+ Exynos3250 has two memory bus group (MIF, INT group). MIF (Memory
+ Interface) memory bus group includes one memory bus block between
+ DRAM and eMMC. Also, INT (Internal) memory bus group includes eight
+ memory bus blocks which support each sub-IP between DRAM and sub-IP.
+
+ memory_bus_mif: memory_bus@0 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 40 875000
+ 20 80
+ 133000 80
+ 10 80
+ 5 80>;
+ status = "disabled";
+
+ blocks {
+ dmc_block: memory_bus_block1 {
+ clocks = <_dmc CLK_DIV_DMC>;
+ clock-names = "memory-bus";
+ frequency = <
+ 40
+ 20
+ 133000
+ 10
+ 5>;
+ };
+ };
+ };
+
+ memory_bus_int: memory_bus@1 {
+ compatible = "samsung,exynos-memory-bus";
+
+ operating-points = <
+ 40 95
+ 20 95
+ 133000 925000
+ 10 85
+ 8 85
+ 5 85>;
+
+ status = "disabled";
+
+ blocks {
+ peri_block: memory_bus_block1 {
+ clocks = < CLK_DIV_ACLK_100>;
+ clock-names = "memory-bus";
+ frequency = <
+ 10
+ 10
+ 10
+ 10
+ 5
+ 5>;
+ };
+
+ display_block: memory_bus_block2 {
+ clocks = < CLK_DIV_ACLK_160>;
+ clock-names = "memory-bus";
+ frequency = <
+ 20
+ 16
+ 10
+ 8
+
[PATCH v4 8/9] ARM: dts: Add the support for exynos busfreq on Exynos4412-based TRATS2 board
This patch adds the Exynos4412 memory-bus node which includes the regulator
and devfreq-event phandle. The devfreq-event phandle is used for the
governor of devfreq device and provide the current usage state of
MIF (Memory Interface) / INT (Internal) memory bus group.
Cc: Kukjin Kim
Cc: Myungjoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4412-trats2.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index bee0eed..21ba25e 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -917,6 +917,18 @@
};
};
+_bus_mif {
+ devfreq-events = <_dmc0_3>, <_dmc1_3>;
+ vdd-mem-supply = <_reg>;
+ status = "okay";
+};
+
+_bus_int {
+ devfreq-events = <_leftbus_3>, <_rightbus_3>;
+ vdd-mem-supply = <_reg>;
+ status = "okay";
+};
+
_0 {
pinctrl-names = "default";
pinctrl-0 = <>;
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
