* [PATCH 2/2] ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels
From: Sebastian Hesselbarth @ 2013-01-30 1:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359509201-11674-1-git-send-email-sebastian.hesselbarth@gmail.com>
The ethernet controller used on kirkwood looses its MAC address
register contents when the corresponding clock is gated. Until there
is proper DT support for the mv643xx_eth driver, we add a workaround
to always enable ge0/ge1 clocks on kirkwood. This workaround is also
already used on non-DT kirkwood kernels.
Reported-by: Simon Baatz <gmbnomis@gmail.com>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Simon Baatz <gmbnomis@gmail.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
arch/arm/mach-kirkwood/board-dt.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index de4fd2b..e714ead 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -41,16 +41,12 @@ static void __init kirkwood_legacy_clk_init(void)
struct device_node *np = of_find_compatible_node(
NULL, NULL, "marvell,kirkwood-gating-clock");
-
struct of_phandle_args clkspec;
+ struct clk *clk;
clkspec.np = np;
clkspec.args_count = 1;
- clkspec.args[0] = CGC_BIT_GE0;
- orion_clkdev_add(NULL, "mv643xx_eth_port.0",
- of_clk_get_from_provider(&clkspec));
-
clkspec.args[0] = CGC_BIT_PEX0;
orion_clkdev_add("0", "pcie",
of_clk_get_from_provider(&clkspec));
@@ -63,14 +59,24 @@ static void __init kirkwood_legacy_clk_init(void)
orion_clkdev_add("1", "pcie",
of_clk_get_from_provider(&clkspec));
- clkspec.args[0] = CGC_BIT_GE1;
- orion_clkdev_add(NULL, "mv643xx_eth_port.1",
- of_clk_get_from_provider(&clkspec));
-
clkspec.args[0] = CGC_BIT_SDIO;
orion_clkdev_add(NULL, "mvsdio",
of_clk_get_from_provider(&clkspec));
+ /*
+ * The ethernet interfaces forget the MAC address assigned by
+ * u-boot if the clocks are turned off. Until proper DT support
+ * is available we always enable them for now.
+ */
+ clkspec.args[0] = CGC_BIT_GE0;
+ clk = of_clk_get_from_provider(&clkspec);
+ orion_clkdev_add(NULL, "mv643xx_eth_port.0", clk);
+ clk_prepare_enable(clk);
+
+ clkspec.args[0] = CGC_BIT_GE1;
+ clk = of_clk_get_from_provider(&clkspec);
+ orion_clkdev_add(NULL, "mv643xx_eth_port.1", clk);
+ clk_prepare_enable(clk);
}
static void __init kirkwood_of_clk_init(void)
--
1.7.10.4
^ permalink raw reply related
* ixp4xx eth broken in 3.7.0/3.8-rc5?
From: Ben Hutchings @ 2013-01-30 1:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51086A17.1090707@gmail.com>
On Tue, 2013-01-29 at 19:32 -0500, Xi Wang wrote:
> On 1/29/13 7:11 PM, Mikael Pettersson wrote:
> > A git bisect identified the following as the culprit:
> >
> > > From 1a4901177574083c35fafc24c4d151c2a7c7647c Mon Sep 17 00:00:00 2001
> > > From: Xi Wang <xi.wang@gmail.com>
> > > Date: Sat, 17 Nov 2012 20:25:09 +0000
> > > Subject: [PATCH] ixp4xx_eth: avoid calling dma_pool_create() with NULL dev
> > >
> > > Use &port->netdev->dev instead of NULL since dma_pool_create() doesn't
> > > allow NULL dev.
> > >
> > > Signed-off-by: Xi Wang <xi.wang@gmail.com>
> > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > Signed-off-by: David S. Miller <davem@davemloft.net>
> > > ---
> > > drivers/net/ethernet/xscale/ixp4xx_eth.c | 8 +++++---
> > > 1 files changed, 5 insertions(+), 3 deletions(-)
> >
> > Reverting this unbreaks ixp4xx_eth on my ixp4xx machine with kernels
> > 3.7.0 and 3.8-rc5.
>
> Thanks. The problem was that in init_queues(), the dma_pool_create()
> call requires a non-null dev.
>
> dma_pool = dma_pool_create(DRV_NAME, ??, ...);
>
> What do you think would work here?
For DMA purposes I would expect the right device to be the parent bus
device, i.e. port->netdev->dev.parent. The driver might also need to
set its DMA masks.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH v4 1/1 net-next] net: fec: add napi support to improve proformance
From: Frank Li @ 2013-01-30 1:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129.141800.2181207237672109119.davem@davemloft.net>
2013/1/30 David Miller <davem@davemloft.net>:
> it is recommended to also to TX reclaim processing
> in the NAPI handler as well, in fact it's best to make the hardware
> interrupt handler do nothing other than trigger NAPI and then
> move everything that was in your hardware interrupt handler into
> NAPI poll instead.
Okay, I will work on this soon.
^ permalink raw reply
* [PATCH v3 0/3] ARM: enable dumping stacks for CONFIG_SMP
From: Colin Cross @ 2013-01-30 1:55 UTC (permalink / raw)
To: linux-arm-kernel
This topic has come up before, see
http://comments.gmane.org/gmane.linux.ports.arm.kernel/102458
for the previous discussion.
SMP is now the norm for new ARM systems, and the limitation that
CONFIG_STACKTRACE doesn't work for tasks besides 'current' causes
problems. The particular case I'm dealing with is automated
debugging information collected from /proc/<pid>/stack when
userspace detects a process is not responding.
Dumping stacktraces is currently disabled due to the worry that the
task may be running on another CPU and that the unwinder may be
unstable when presented with a stack that is being modified. I have
attempted to harden the frame pointer based unwinder and the unwind
table based unwinder against invalid stacks. I separated the two
into individual patches, as I expect the patch to the table unwinder
to be more controversial than the frame pointer unwinder.
Even without the hardening, unwinding a stack for a running process
is not completely untested. When CONFIG_ARM_UNWIND is enabled,
sysrq-t calls unwind_backtrace for all tasks including running ones.
In addition, any callers to unwind_frame with preemption enabled,
including proc_pid_stack, could see a modified stack even on a UP
system (pointed out by Rabin Vincent the last time this topic came
up).
v2 of the patchset adds additional checks to avoid starting the
stacktrace in an unmapped region or looping forever when unwinding
a bad stack.
v2:
add depth parameter to unwind_frame
verify that sp changes for non-leaf frames
verify that initial sp value is in mapped lowmem
verify that stack offsets are in the range
[sizeof(struct thread_info), THREAD_START_SP)
v3:
fix calling sp_addr_valid before page structs are set up
arch/arm/include/asm/stacktrace.h | 6 ++-
arch/arm/kernel/process.c | 2 +-
arch/arm/kernel/stacktrace.c | 122 +++++++++++++++++++++++++++++++------
arch/arm/kernel/time.c | 3 +-
arch/arm/kernel/unwind.c | 46 ++++++++++----
5 files changed, 145 insertions(+), 34 deletions(-)
^ permalink raw reply
* [PATCH v3 1/3] ARM: stacktrace: harden FP stacktraces against invalid stacks
From: Colin Cross @ 2013-01-30 1:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359510947-3950-1-git-send-email-ccross@android.com>
Dumping stacktraces is currently disabled in ARM SMP for all tasks
except the current task due to the worry that the task may be running
on another CPU and that the unwinder may be unstable when presented
with a stack that is being modified.
Unwinding with CONFIG_FRAME_POINTER is fairly simple compared to
when CONFIG_ARM_UNWIND is set. The next frame's FP and SP registers
are read from the stack and can be validated against the current
values to ensure that they do not leave the stack and make progress
towards the upper end of the stack. This guarantees that accesses
do not fault and that execution is bounded.
Add additional validations to the version of unwind_frame used when
CONFIG_FRAME_POINTER=y:
Verify that the stack is in a mapped region of kernel memory.
Fixes crashes seen in unwind_frame on real systems, although
stack corruption caused by memory instability is likely the cause
of the invalid sp and fp values.
Fix address comparison to catch fp >= 0xfffffffc correctly.
Fixes crash reported by Todd Poynor.
Ensure the stack pointer moves to a higher address between each
frame to make sure repeated calls to unwind_frame can't loop
forever.
Includes ideas from Dave Martin.
Signed-off-by: Colin Cross <ccross@android.com>
---
v2:
verify that initial sp value is in mapped lowmem
verify that stack offsets are in the range
[sizeof(struct thread_info), THREAD_START_SP)
export stack validation functions for use by unwind
v3:
avoid using page structs to convert vaddr to pfn
arch/arm/include/asm/stacktrace.h | 4 ++
arch/arm/kernel/stacktrace.c | 105 +++++++++++++++++++++++++++++++++++---
2 files changed, 103 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/stacktrace.h b/arch/arm/include/asm/stacktrace.h
index 4d0a164..6909056 100644
--- a/arch/arm/include/asm/stacktrace.h
+++ b/arch/arm/include/asm/stacktrace.h
@@ -12,4 +12,8 @@ struct stackframe {
extern void walk_stackframe(struct stackframe *frame,
int (*fn)(struct stackframe *, void *), void *data);
+bool sp_addr_valid(unsigned long sp);
+bool addr_in_stack(unsigned long orig_sp, unsigned long vsp);
+bool sp_in_stack(unsigned long orig_sp, unsigned long vsp);
+
#endif /* __ASM_STACKTRACE_H */
diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
index 00f79e5..aba76d5 100644
--- a/arch/arm/kernel/stacktrace.c
+++ b/arch/arm/kernel/stacktrace.c
@@ -1,9 +1,89 @@
#include <linux/export.h>
+#include <linux/mm.h>
#include <linux/sched.h>
#include <linux/stacktrace.h>
#include <asm/stacktrace.h>
+#define STACK_MAX(sp) (round_down(sp, THREAD_SIZE) + THREAD_START_SP)
+
+/**
+ * sp_addr_valid - verify a stack pointer
+ * @sp: current stack pointer
+ *
+ * Returns true if sp is a pointer inside a memory area that could be a stack.
+ * Does not verify that sp is inside an actual stack (i.e. does not check for
+ * STACK_MAGIC).
+ *
+ * If sp_addr_valid(sp) returns true, then the kernel will not fault if it
+ * accesses memory in the range
+ * [sp, round_down(sp, THREAD_SIZE) + THREAD_START_SP)
+ */
+bool sp_addr_valid(unsigned long sp)
+{
+ unsigned long high;
+ unsigned long offset;
+ unsigned int pfn;
+ unsigned int start_pfn;
+ unsigned int end_pfn;
+
+ if (!IS_ALIGNED(sp, 4))
+ return false;
+
+ offset = sp & (THREAD_SIZE - 1);
+
+ if (offset > THREAD_START_SP)
+ return false;
+
+ if (offset < sizeof(struct thread_info))
+ return false;
+
+ high = STACK_MAX(sp);
+
+ if (!virt_addr_valid(sp) || !virt_addr_valid(high))
+ return false;
+
+ start_pfn = __phys_to_pfn(__virt_to_phys(sp));
+ end_pfn = __phys_to_pfn(__virt_to_phys(high));
+ for (pfn = start_pfn; pfn <= end_pfn; pfn++)
+ if (!pfn_valid(pfn))
+ return false;
+
+ return true;
+}
+
+/**
+ * addr_in_stack - verify a pointer is inside a specified stack
+ * @orig_sp: stack pointer at the bottom of the stack
+ * @sp: address to be verified
+ *
+ * Returns true if sp is in the stack bounded@the bottom by orig_sp, in the
+ * range [orig_sp, round_down(orig_sp, THREAD_SIZE) + THREAD_START_SP)
+ *
+ * If orig_sp is valid (see sp_addr_valid), then the kernel will not fault if it
+ * accesses a pointer where ptr_in_stack returns true.
+ */
+bool addr_in_stack(unsigned long orig_sp, unsigned long sp)
+{
+ return (sp >= orig_sp && sp < STACK_MAX(orig_sp) && IS_ALIGNED(sp, 4));
+}
+
+/**
+ * sp_in_stack - verify a stack pointer is inside a specified stack
+ * @orig_sp: stack pointer at the bottom of the stack
+ * @sp: stack pointer to be verified
+ *
+ * Returns true if sp is in the stack bounded@the bottom by orig_sp, in the
+ * range [orig_sp, round_down(orig_sp, THREAD_SIZE) + THREAD_START_SP]
+ *
+ * If sp_in_stack returns true,
+ * addr_in_stack(vsp, x) == addr_in_stack(orig_sp, x)
+ */
+bool sp_in_stack(unsigned long orig_sp, unsigned long sp)
+{
+ return (sp >= orig_sp && sp <= STACK_MAX(orig_sp) && IS_ALIGNED(sp, 4));
+}
+
#if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND)
/*
* Unwind the current stack frame and store the new register values in the
@@ -23,15 +103,17 @@
*/
int notrace unwind_frame(struct stackframe *frame)
{
- unsigned long high, low;
unsigned long fp = frame->fp;
+ unsigned long sp = frame->sp;
+
+ if (!sp_addr_valid(sp))
+ return -EINVAL;
- /* only go to a higher address on the stack */
- low = frame->sp;
- high = ALIGN(low, THREAD_SIZE);
+ /* Check current frame pointer is within the stack bounds. */
+ if (!addr_in_stack(sp, fp))
+ return -EINVAL;
- /* check current frame pointer is within bounds */
- if (fp < (low + 12) || fp + 4 >= high)
+ if (fp < 12 || !addr_in_stack(sp, fp - 12))
return -EINVAL;
/* restore the registers from the stack frame */
@@ -39,6 +121,17 @@ int notrace unwind_frame(struct stackframe *frame)
frame->sp = *(unsigned long *)(fp - 8);
frame->pc = *(unsigned long *)(fp - 4);
+ /* Ensure the next stack pointer is in the same stack */
+ if (!sp_in_stack(sp, frame->sp))
+ return -EINVAL;
+
+ /*
+ * Ensure the next stack pointer is above this frame to guarantee
+ * bounded execution.
+ */
+ if (frame->sp < fp)
+ return -EINVAL;
+
return 0;
}
#endif
--
1.8.1
^ permalink raw reply related
* [PATCH v3 2/3] ARM: unwind: harden unwinding against invalid stacks
From: Colin Cross @ 2013-01-30 1:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359510947-3950-1-git-send-email-ccross@android.com>
Unwinding with CONFIG_ARM_UNWIND is much more complicated than
unwinding with CONFIG_FRAME_POINTER, but there are only a few points
that require validation in order to avoid faults or infinite loops.
Avoiding faults is easy by adding checks to verify that the stack
bounds are in lowmem, and that all accesses relative to the stack
pointer remain inside the stack.
When CONFIG_FRAME_POINTER is not set it is possible for a leaf frame
to have the same SP as its caller, but otherwise the SP of the caller
should always be higher than the SP of the callee. Add a depth
parameter to unwind_frame to allow it to distinguish leaf frames
from non-leaf frames, and return an error if a caller has the same
sp as a non-leaf frame callee.
Signed-off-by: Colin Cross <ccross@android.com>
---
v2:
add depth parameter to unwind_frame
verify that sp changes for non-leaf frames
verify that initial sp value is in mapped lowmem
verify that stack offsets are in the range
[sizeof(struct thread_info), THREAD_START_SP)
v3:
no changes
arch/arm/include/asm/stacktrace.h | 2 +-
arch/arm/kernel/process.c | 2 +-
arch/arm/kernel/stacktrace.c | 6 +++--
arch/arm/kernel/time.c | 3 ++-
arch/arm/kernel/unwind.c | 46 +++++++++++++++++++++++++++++----------
5 files changed, 42 insertions(+), 17 deletions(-)
diff --git a/arch/arm/include/asm/stacktrace.h b/arch/arm/include/asm/stacktrace.h
index 6909056..cc48971 100644
--- a/arch/arm/include/asm/stacktrace.h
+++ b/arch/arm/include/asm/stacktrace.h
@@ -8,7 +8,7 @@ struct stackframe {
unsigned long pc;
};
-extern int unwind_frame(struct stackframe *frame);
+extern int unwind_frame(struct stackframe *frame, int depth);
extern void walk_stackframe(struct stackframe *frame,
int (*fn)(struct stackframe *, void *), void *data);
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 41aad9e..10ea483 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -633,7 +633,7 @@ unsigned long get_wchan(struct task_struct *p)
frame.lr = 0; /* recovered from the stack */
frame.pc = thread_saved_pc(p);
do {
- int ret = unwind_frame(&frame);
+ int ret = unwind_frame(&frame, count);
if (ret < 0)
return 0;
if (!in_sched_functions(frame.pc))
diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
index aba76d5..d897f4c 100644
--- a/arch/arm/kernel/stacktrace.c
+++ b/arch/arm/kernel/stacktrace.c
@@ -101,7 +101,7 @@ bool sp_in_stack(unsigned long orig_sp, unsigned long sp)
* Note that with framepointer enabled, even the leaf functions have the same
* prologue and epilogue, therefore we can ignore the LR value in this case.
*/
-int notrace unwind_frame(struct stackframe *frame)
+int notrace unwind_frame(struct stackframe *frame, int depth)
{
unsigned long fp = frame->fp;
unsigned long sp = frame->sp;
@@ -139,12 +139,14 @@ int notrace unwind_frame(struct stackframe *frame)
void notrace walk_stackframe(struct stackframe *frame,
int (*fn)(struct stackframe *, void *), void *data)
{
+ int depth = 0;
+
while (1) {
int ret;
if (fn(frame, data))
break;
- ret = unwind_frame(frame);
+ ret = unwind_frame(frame, depth++);
if (ret < 0)
break;
}
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index fe31b22..5f0bf17 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -51,6 +51,7 @@
unsigned long profile_pc(struct pt_regs *regs)
{
struct stackframe frame;
+ int depth = 0;
if (!in_lock_functions(regs->ARM_pc))
return regs->ARM_pc;
@@ -60,7 +61,7 @@ unsigned long profile_pc(struct pt_regs *regs)
frame.lr = regs->ARM_lr;
frame.pc = regs->ARM_pc;
do {
- int ret = unwind_frame(&frame);
+ int ret = unwind_frame(&frame, depth++);
if (ret < 0)
return 0;
} while (in_lock_functions(frame.pc));
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 00df012..529c36f 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -40,6 +40,7 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/export.h>
+#include <linux/mm.h>
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
@@ -235,12 +236,18 @@ static unsigned long unwind_get_byte(struct unwind_ctrl_block *ctrl)
return ret;
}
+static bool ptr_in_stack(unsigned long orig_sp, void *vsp)
+{
+ return addr_in_stack(orig_sp, (unsigned long)vsp);
+}
+
/*
* Execute the current unwind instruction.
*/
static int unwind_exec_insn(struct unwind_ctrl_block *ctrl)
{
unsigned long insn = unwind_get_byte(ctrl);
+ unsigned long orig_sp = ctrl->vrs[SP];
pr_debug("%s: insn = %08lx\n", __func__, insn);
@@ -264,8 +271,11 @@ static int unwind_exec_insn(struct unwind_ctrl_block *ctrl)
/* pop R4-R15 according to mask */
load_sp = mask & (1 << (13 - 4));
while (mask) {
- if (mask & 1)
+ if (mask & 1) {
+ if (!ptr_in_stack(orig_sp, vsp))
+ return -URC_FAILURE;
ctrl->vrs[reg] = *vsp++;
+ }
mask >>= 1;
reg++;
}
@@ -279,10 +289,16 @@ static int unwind_exec_insn(struct unwind_ctrl_block *ctrl)
int reg;
/* pop R4-R[4+bbb] */
- for (reg = 4; reg <= 4 + (insn & 7); reg++)
+ for (reg = 4; reg <= 4 + (insn & 7); reg++) {
+ if (!ptr_in_stack(orig_sp, vsp))
+ return -URC_FAILURE;
ctrl->vrs[reg] = *vsp++;
- if (insn & 0x80)
+ }
+ if (insn & 0x80) {
+ if (!ptr_in_stack(orig_sp, vsp))
+ return -URC_FAILURE;
ctrl->vrs[14] = *vsp++;
+ }
ctrl->vrs[SP] = (unsigned long)vsp;
} else if (insn == 0xb0) {
if (ctrl->vrs[PC] == 0)
@@ -302,8 +318,11 @@ static int unwind_exec_insn(struct unwind_ctrl_block *ctrl)
/* pop R0-R3 according to mask */
while (mask) {
- if (mask & 1)
+ if (mask & 1) {
+ if (!ptr_in_stack(orig_sp, vsp))
+ return -URC_FAILURE;
ctrl->vrs[reg] = *vsp++;
+ }
mask >>= 1;
reg++;
}
@@ -327,19 +346,17 @@ static int unwind_exec_insn(struct unwind_ctrl_block *ctrl)
* Unwind a single frame starting with *sp for the symbol at *pc. It
* updates the *pc and *sp with the new values.
*/
-int unwind_frame(struct stackframe *frame)
+int unwind_frame(struct stackframe *frame, int depth)
{
- unsigned long high, low;
const struct unwind_idx *idx;
struct unwind_ctrl_block ctrl;
- /* only go to a higher address on the stack */
- low = frame->sp;
- high = ALIGN(low, THREAD_SIZE);
-
pr_debug("%s(pc = %08lx lr = %08lx sp = %08lx)\n", __func__,
frame->pc, frame->lr, frame->sp);
+ if (!sp_addr_valid(frame->sp))
+ return -URC_FAILURE;
+
if (!kernel_text_address(frame->pc))
return -URC_FAILURE;
@@ -386,7 +403,7 @@ int unwind_frame(struct stackframe *frame)
int urc = unwind_exec_insn(&ctrl);
if (urc < 0)
return urc;
- if (ctrl.vrs[SP] < low || ctrl.vrs[SP] >= high)
+ if (!sp_in_stack(frame->sp, ctrl.vrs[SP]))
return -URC_FAILURE;
}
@@ -397,6 +414,10 @@ int unwind_frame(struct stackframe *frame)
if (frame->pc == ctrl.vrs[PC])
return -URC_FAILURE;
+ /* only leaf functions can possibly not modify sp */
+ if (depth != 0 && frame->sp == ctrl.vrs[SP])
+ return -URC_FAILURE;
+
frame->fp = ctrl.vrs[FP];
frame->sp = ctrl.vrs[SP];
frame->lr = ctrl.vrs[LR];
@@ -409,6 +430,7 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
{
struct stackframe frame;
register unsigned long current_sp asm ("sp");
+ int depth = 0;
pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
@@ -443,7 +465,7 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
int urc;
unsigned long where = frame.pc;
- urc = unwind_frame(&frame);
+ urc = unwind_frame(&frame, depth++);
if (urc < 0)
break;
dump_backtrace_entry(where, frame.pc, frame.sp - 4);
--
1.8.1
^ permalink raw reply related
* [PATCH v3 3/3] ARM: stacktrace: enable save_stack_trace_tsk for CONFIG_SMP
From: Colin Cross @ 2013-01-30 1:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359510947-3950-1-git-send-email-ccross@android.com>
Now that unwind_frame has been hardened against invalid stacks
for CONFIG_ARM_UNWIND or CONFIG_FRAME_POINTER, enable dumping
the stack on non-current threads for CONFIG_SMP.
Signed-off-by: Colin Cross <ccross@android.com>
---
arch/arm/kernel/stacktrace.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
index d897f4c..c6e6477 100644
--- a/arch/arm/kernel/stacktrace.c
+++ b/arch/arm/kernel/stacktrace.c
@@ -187,22 +187,11 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
data.skip = trace->skip;
if (tsk != current) {
-#ifdef CONFIG_SMP
- /*
- * What guarantees do we have here that 'tsk' is not
- * running on another CPU? For now, ignore it as we
- * can't guarantee we won't explode.
- */
- if (trace->nr_entries < trace->max_entries)
- trace->entries[trace->nr_entries++] = ULONG_MAX;
- return;
-#else
data.no_sched_functions = 1;
frame.fp = thread_saved_fp(tsk);
frame.sp = thread_saved_sp(tsk);
frame.lr = 0; /* recovered from the stack */
frame.pc = thread_saved_pc(tsk);
-#endif
} else {
register unsigned long current_sp asm ("sp");
--
1.8.1
^ permalink raw reply related
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Viresh Kumar @ 2013-01-30 2:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301291621.59425.arnd@arndb.de>
On 29 January 2013 21:51, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 29 January 2013, Viresh Kumar wrote:
>> On 29 January 2013 19:01, Arnd Bergmann <arnd@arndb.de> wrote:
>> > Ah, good. So I guess the "dma-requests" property should actually
>> > be "16" then.
>>
>> yes, even i was checking on that separately :)
>
> Actually, I just discovered something odd in the
> arch/arm/mach-spear/spear13xx-dma.h file that gets removed
> in the last patch: there, we define request numbers up to
> 32, e.g.
>
> - SPEAR1310_DMA_REQ_UART2_RX = 14,
> - SPEAR1310_DMA_REQ_UART2_TX = 15,
> - SPEAR1310_DMA_REQ_UART5_RX = 16,
> - SPEAR1310_DMA_REQ_UART5_TX = 17,
>
> What is the meaning of this, if the maximum request number is 15?
I knew you will come to this :)
So, the hardware is like: there are 16 request line slots per master, a
platform can choose to connect same or separate devices to these.
So, these are really 16 per master.
> Ok. Would it be enough to have only one master and one request
> field in the DT dma descriptor then, and have the code figure
> whether to use it as source or destination, based on the
> configuration? Which one should come first? Since you have
> multiple masters per controller, and multiple requests per
> master, it sounds like the cleanest descriptor form would
> be
>
> <controller master request>;
>
> Or possibly
>
> <controller master request direction>;
>
> if the direction needs to be known at the time the channel
> is requested.
Its better to keep masters as is. So, that we can use appropriate
masters for peripheral and memory to make the transfer fast.
^ permalink raw reply
* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: Peter Chen @ 2013-01-30 2:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87pq0omcfb.fsf@ashishki-desk.ger.corp.intel.com>
On Tue, Jan 29, 2013 at 01:55:04PM +0200, Alexander Shishkin wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
>
> > From: Michael Grzeschik <m.grzeschik@pengutronix.de>
> >
> > This adds two little devicetree helper functions for determining the
> > dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
> > the devicetree.
> >
> > Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> > Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> > ---
> >
> > The properties and their values have been taken from the fsl-mph-dr driver.
> > This binding is also documented (though currently not used) for the tegra
> > ehci driver (Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt).
> > This is a first attempt to parse these bindings at a common place so that
> > others can make use of it.
> >
> > Basically I want to know whether this binding is recommended for new drivers
> > since normally the devicetree uses '-' instead of '_', and maybe there are
> > other problems with it.
> >
> > I need this binding for the chipidea driver. I suspect that the fsl-mph-dr
> > driver also really handles a chipidea core.
>
> As far as I know, it is a chipidea core. Adding Peter to Cc list, he can
> probably confirm.
The fsl-mph-dr can't be used for chipdiea as it handles three platform
drivers for three roles (peripheral , host, otg). But chipidea only has
two platform drivers, one is the chipidea core, the other is related
controller wrapper.
However, two common helpers are useful, dr_mode can override controller
capability, and using user defined controller operation mode.
phy_type can be used at controller initialization to set phy's type at
controller's register, eg, for chipidea code, there is a PTS
(Parallel Transceiver Select) domain at portsc to set phy's type.
>
> > Should we agree on this I would convert the fsl-mph-dr driver to use these
> > helpers.
> >
> > Sascha
> >
> > drivers/usb/core/Makefile | 1 +
> > drivers/usb/core/of.c | 76 +++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/usb/of.h | 22 +++++++++++++
> > include/linux/usb/phy.h | 9 ++++++
> > 4 files changed, 108 insertions(+)
> > create mode 100644 drivers/usb/core/of.c
> > create mode 100644 include/linux/usb/of.h
> >
> > diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> > index 26059b9..5378add 100644
> > --- a/drivers/usb/core/Makefile
> > +++ b/drivers/usb/core/Makefile
> > @@ -10,5 +10,6 @@ usbcore-y += devio.o notify.o generic.o quirks.o devices.o
> >
> > usbcore-$(CONFIG_PCI) += hcd-pci.o
> > usbcore-$(CONFIG_ACPI) += usb-acpi.o
> > +usbcore-$(CONFIG_OF) += of.o
> >
> > obj-$(CONFIG_USB) += usbcore.o
> > diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
> > new file mode 100644
> > index 0000000..d000d9f
> > --- /dev/null
> > +++ b/drivers/usb/core/of.c
> > @@ -0,0 +1,76 @@
> > +/*
> > + * OF helpers for usb devices.
> > + *
> > + * This file is released under the GPLv2
> > + *
> > + * Initially copied out of drivers/of/of_net.c
> > + */
> > +#include <linux/kernel.h>
> > +#include <linux/of.h>
> > +#include <linux/usb/of.h>
> > +#include <linux/usb/phy.h>
> > +#include <linux/export.h>
> > +
> > +static const char *usbphy_modes[] = {
> > + [USBPHY_INTERFACE_MODE_NA] = "",
> > + [USBPHY_INTERFACE_MODE_UTMI] = "utmi",
> > + [USBPHY_INTERFACE_MODE_UTMIW] = "utmi_wide",
> > + [USBPHY_INTERFACE_MODE_ULPI] = "ulpi",
> > + [USBPHY_INTERFACE_MODE_SERIAL] = "serial",
> > + [USBPHY_INTERFACE_MODE_HSIC] = "hsic",
> > +};
> > +
> > +/**
> > + * of_get_usbphy_mode - Get phy mode for given device_node
> > + * @np: Pointer to the given device_node
> > + *
> > + * The function gets phy interface string from property 'phy_type',
> > + * and returns the correspondig enum usb_phy_interface
> > + */
> > +enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np)
> > +{
> > + const char *phy_type;
> > + int err, i;
> > +
> > + err = of_property_read_string(np, "phy_type", &phy_type);
> > + if (err < 0)
> > + return USBPHY_INTERFACE_MODE_NA;
> > +
> > + for (i = 0; i < ARRAY_SIZE(usbphy_modes); i++)
> > + if (!strcasecmp(phy_type, usbphy_modes[i]))
> > + return i;
> > +
> > + return USBPHY_INTERFACE_MODE_NA;
> > +}
> > +EXPORT_SYMBOL_GPL(of_usb_get_phy_mode);
> > +
> > +static const char *usb_dr_modes[] = {
> > + [USB_DR_MODE_UNKNOWN] = "",
> > + [USB_DR_MODE_HOST] = "host",
> > + [USB_DR_MODE_PERIPHERAL] = "peripheral",
> > + [USB_DR_MODE_OTG] = "otg",
> > +};
> > +
> > +/**
> > + * of_usb_get_dr_mode - Get dual role mode for given device_node
> > + * @np: Pointer to the given device_node
> > + *
> > + * The function gets phy interface string from property 'dr_mode',
> > + * and returns the correspondig enum usb_phy_dr_mode
> > + */
> > +enum usb_phy_dr_mode of_usb_get_dr_mode(struct device_node *np)
> > +{
> > + const char *dr_mode;
> > + int err, i;
> > +
> > + err = of_property_read_string(np, "dr_mode", &dr_mode);
> > + if (err < 0)
> > + return USB_DR_MODE_UNKNOWN;
> > +
> > + for (i = 0; i < ARRAY_SIZE(usb_dr_modes); i++)
> > + if (!strcasecmp(dr_mode, usb_dr_modes[i]))
> > + return i;
> > +
> > + return USB_DR_MODE_UNKNOWN;
> > +}
> > +EXPORT_SYMBOL_GPL(of_usb_get_dr_mode);
> > diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
> > new file mode 100644
> > index 0000000..582ba96
> > --- /dev/null
> > +++ b/include/linux/usb/of.h
> > @@ -0,0 +1,22 @@
> > +/*
> > + * OF helpers for usb devices.
> > + *
> > + * This file is released under the GPLv2
> > + */
> > +
> > +#ifndef __LINUX_USB_OF_H
> > +#define __LINUX_USB_OF_H
> > +
> > +#include <linux/usb/phy.h>
> > +
> > +enum usb_phy_dr_mode {
> > + USB_DR_MODE_UNKNOWN,
> > + USB_DR_MODE_HOST,
> > + USB_DR_MODE_PERIPHERAL,
> > + USB_DR_MODE_OTG,
> > +};
> > +
> > +enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np);
> > +enum usb_phy_dr_mode of_usb_get_dr_mode(struct device_node *np);
> > +
> > +#endif /* __LINUX_USB_OF_H */
> > diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
> > index a29ae1e..c5154cf 100644
> > --- a/include/linux/usb/phy.h
> > +++ b/include/linux/usb/phy.h
> > @@ -12,6 +12,15 @@
> > #include <linux/notifier.h>
> > #include <linux/usb.h>
> >
> > +enum usb_phy_interface {
> > + USBPHY_INTERFACE_MODE_NA,
> > + USBPHY_INTERFACE_MODE_UTMI,
> > + USBPHY_INTERFACE_MODE_UTMIW,
> > + USBPHY_INTERFACE_MODE_ULPI,
> > + USBPHY_INTERFACE_MODE_SERIAL,
> > + USBPHY_INTERFACE_MODE_HSIC,
> > +};
> > +
> > enum usb_phy_events {
> > USB_EVENT_NONE, /* no events or cable disconnected */
> > USB_EVENT_VBUS, /* vbus valid event */
> > --
> > 1.7.10.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Best Regards,
Peter Chen
^ permalink raw reply
* [GIT PULL v2] arm-soc: Xilinx zynq timer changes for v3.9
From: Olof Johansson @ 2013-01-30 2:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHTX3d+V1tVTwds+dcOtac3sMq0JB6-GPXxUg=GCtc5Cy5nODg@mail.gmail.com>
On Mon, Jan 28, 2013 at 01:34:46PM +0100, Michal Simek wrote:
> Hi,
>
> 2013/1/28 Olof Johansson <olof@lixom.net>:
> > On Fri, Jan 25, 2013 at 04:48:43PM +0100, Michal Simek wrote:
> >> Hi Arnd and Olof,
> >>
> >> can you please look at this pull request?
> >
> > Hi,
> >
> > Sorry for the delay. I was out sick part of last week and dealing with
> > backlog when I got back on my feet. Doing a sweep of pull requests now.
>
> ah ok.
>
> > Two comments.
> >
> > 1. mach-pxa/time.c conflict resolution doesn't seem right -- you for some
> > reason deleted the suspend/resume struct members from the
> > clock_event_device.
>
> grrr. You are right,
>
>
> > 2. Below:
> >
> >> > Soren Brinkmann (7):
> >> > arm: zynq: timer: Replace PSS through PS
> >
> > This is pure churn. :( We can't keep renaming things in the kernel just
> > because some document writer decides to change a term, we tend to stick
> > to what's already there. As long as it's not completely misleading, at least.
> >
> >
> > I' shortly push a new "depends/cleanup" branch to arm-soc. It essentially
> > contains the next/cleanup contents that you merged together yourself,
> > but as a branch that you can just pull in. Since others might need to
> > do the same, providing the branch from us just makes sense.
> >
> > So, can you please rebase on top of that and send a fresh pull request? If
> > you really want the PSS->PS rename included I'll give you a first-time
> > pass for it but please keep it in mind for the future.
>
> I tend to keep this patch in the tree but I will keep this in my mind.
> I believe that only this mainline timer driver contains it and all new patches
> which come soon will just use PS instead of PSS.
>
> I will send updated pull request.
> There will be one more patch "arm: zynq: Add missing irqchip.h to common.c"
> because of compilation error introduced by the last merge around git changes.
>
> btw: I want to also add maintainer fragment and defconfig update(sent by Josh)
> Which branch should I use?
You can just cc us on your Acked-by, and we can apply them directly. I suspect
they might otherwise just be single-patch branches. :)
-Olof
^ permalink raw reply
* [GIT PULL v3] arm-soc: Xilinx zynq timer changes for v3.9
From: Olof Johansson @ 2013-01-30 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHTX3d+tDZF1-aKKfx+Zsb4FefrBbLaxe9qAz1Vsf3rDb-qHTw@mail.gmail.com>
On Mon, Jan 28, 2013 at 01:53:11PM +0100, Michal Simek wrote:
> Hi Olof,
>
> based on your previous email I am sending updated pull request which is based
> on arm-soc depends/cleanup branch.
> As I wrote in my email I tend to keep there Soren's patch around
> renaming PSS to PS
> and be more strict on this for future.
> I have also added one more patch which fix Rob's conversion to irqchip_init.
Ok, pulled. Sorry for the delay, I had forgotten this email halfway read on my
machine at home, so it fell of my list of branches to pull earlier today.
> btw: As I mentioned in the previous email I want to add 2 defconfig
> updates + maintainer
> fragment. I have created branch zynq/misc in the same repo. Is this
> name ok for you?
> If yes, I will send you separate pull request just for this branch.
Ah, do'h, I replied to the previous email. Nevermind that suggestion then, I'll
just pull the misc branch.
Thanks,
-Olof
^ permalink raw reply
* [GIT PULL v2] Renesas ARM-based SoC for v3.9
From: Simon Horman @ 2013-01-30 2:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129171138.GE16188@quad.lixom.net>
On Tue, Jan 29, 2013 at 09:11:38AM -0800, Olof Johansson wrote:
> On Fri, Jan 25, 2013 at 12:55:18PM +0900, Simon Horman wrote:
> > Hi Olof, Hi Arnd,
> >
> > please consider the following soc enhancements for 3.9.
> >
> > This series is based on a merge of the irqchip/gic-vic-move and
> > timer/cleanup branches in the arm-soc tree. There were a number of
> > conflicts in this merge, as indicated by the merge commit
> > 6265b0f325eed54558b35769aecb1d79423295c7. In each case I took care to
> > match the merge made in the arm-soc tree which is evident in the for-next
> > branch.
> >
> > ----------------------------------------------------------------
> > The following changes since commit 6265b0f325eed54558b35769aecb1d79423295c7:
> >
> > Merge remote-tracking branches 'arm-soc/irqchip/gic-vic-move' and 'arm-soc/timer/cleanup' into soc (2013-01-24 17:57:20 +0900)
> >
> > are available in the git repository at:
> >
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git soc
> >
>
> Merged, thanks. You had resolved the board_bcm conflict slightly differenlty
> (technically better), but to keep it common with what we have, I added back
> the extra line of whitespace.
>
> By the way, you should look into starting to use signed tags for your pull
> requests, since it gives you a place to give a short description of the branch
> (and that description makes it into the commit with 0 work on our behalf :)
Sure, will do.
Thanks for this and the other 3 merges.
^ permalink raw reply
* [PATCH] MAINTAINERS: Add ARM/Zynq architecture entry
From: Olof Johansson @ 2013-01-30 2:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358786701-28414-1-git-send-email-michal.simek@xilinx.com>
On Mon, Jan 21, 2013 at 8:45 AM, Michal Simek <michal.simek@xilinx.com> wrote:
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Applied (by cherry-pick from a branch pull request, but following up
here none the less. :)
-Olof
> ---
> MAINTAINERS | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4e2a1f6..61bf074 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1264,6 +1264,14 @@ S: Maintained
> F: arch/arm/mach-pxa/z2.c
> F: arch/arm/mach-pxa/include/mach/z2.h
>
> +ARM/ZYNQ ARCHITECTURE
> +M: Michal Simek <michal.simek@xilinx.com>
> +L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +W: http://wiki.xilinx.com
> +T: git git://git.xilinx.com/linux-xlnx.git
> +S: Supported
> +F: arch/arm/mach-zynq/
> +
> ARM64 PORT (AARCH64 ARCHITECTURE)
> M: Catalin Marinas <catalin.marinas@arm.com>
> M: Will Deacon <will.deacon@arm.com>
> --
> 1.7.0.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 1/2] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
From: Tivy, Robert @ 2013-01-30 2:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5103E907.8020206@mvista.com>
Hi Sergei,
> -----Original Message-----
> From: Sergei Shtylyov [mailto:sshtylyov at mvista.com]
> Sent: Saturday, January 26, 2013 6:33 AM
>
> Hello.
>
> On 26-01-2013 6:45, Robert Tivy wrote:
>
> > Adding a remoteproc driver implementation for OMAP-L138 DSP
>
> You forgot to sign off the patch.
Ugh, thanks for pointing that out, I will correct this in the next submission.
>
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index 96ce101..e923599 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> [...]
> > @@ -41,4 +41,28 @@ config STE_MODEM_RPROC
> > This can be either built-in or a loadable module.
> > If unsure say N.
> >
> > +config DA8XX_REMOTEPROC
> > + tristate "DaVinci DA850/OMAPL138 remoteproc support
> (EXPERIMENTAL)"
>
> Neither DA850 nor OMAP-L138 are true DaVinci processors. Please
> drop the
> "DaVinci" word.
Ok, although DaVinci is used extensively in other places that support DA830/DA850.
>
> > + depends on ARCH_DAVINCI_DA850
>
> It's also not clear why you limit the driver d\to DA850 while you
> call it
> da8xx_remoteproc.c. There's at least one more member to DA8xx familiy
> (at
> least supported in the community): DA830/OMAP-L137.
I'll change this to:
Depends on ARCH_DAVINCI_DA8XX
since that gets selected for either ARCH_DAVINCI_DA830 or ARCH_DAVINCI_DA850.
>
> > + select REMOTEPROC
> > + select RPMSG
> > + select CMA
> > + default n
> > + help
> > + Say y here to support DaVinci DA850/OMAPL138 remote processors
>
> Same here.
>
> > diff --git a/drivers/remoteproc/da8xx_remoteproc.c
> b/drivers/remoteproc/da8xx_remoteproc.c
> > new file mode 100644
> > index 0000000..c6eb6bf
> > --- /dev/null
> > +++ b/drivers/remoteproc/da8xx_remoteproc.c
> > @@ -0,0 +1,327 @@
> > +/*
> > + * Remote processor machine-specific module for DA8XX
> > + *
> > + * Copyright (C) 2013 Texas Instruments, Inc.
> > + *
> > + * 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 <linux/bitops.h>
> > +#include <linux/clk.h>
> > +#include <linux/err.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/io.h>
> > +#include <linux/irq.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/remoteproc.h>
> > +
> > +#include <mach/clock.h> /* for davinci_clk_reset_assert/deassert()
> */
> > +
> > +#include "remoteproc_internal.h"
> > +
> > +static char *da8xx_fw_name;
> > +module_param(da8xx_fw_name, charp, S_IRUGO);
> > +MODULE_PARM_DESC(da8xx_fw_name,
> > + "\n\t\tName of DSP firmware file in /lib/firmware");
> > +
> > +/*
> > + * OMAP-L138 Technical References:
> > + * http://www.ti.com/product/omap-l138
> > + */
> > +#define SYSCFG_CHIPSIG_OFFSET 0x174
> > +#define SYSCFG_CHIPSIG_CLR_OFFSET 0x178
>
> <mach/da8xx.h> has SYSCFG register #define's ending with '_REG',
> not
> '_OFFSET' -- I'd like this tradition to be kept. And perhaps we should
> #define
> these registers there instead of the driver?
#include'ing header files in 'mach' subdirectories is frowned upon due to such header files being machine-specific, so I'm trying to avoid that. But as you noted in your subsequent email, these register offsets aren't used so I'll delete them altogether.
>
> > +#define SYSCFG_CHIPINT0 BIT(0)
> > +#define SYSCFG_CHIPINT1 BIT(1)
> > +#define SYSCFG_CHIPINT2 BIT(2)
> > +#define SYSCFG_CHIPINT3 BIT(3)
>
> DA830/OMAP-l137 has the same registers. Only the datasheet calls
> the bits
> CHIPSIGn there. Bit 4 also exists and means DSP NMI.
Since the register bits are termed CHIPSIGn I will change them to that name (I believe the "lines" or signals are called CHIPINTn).
>
> > +static int da8xx_rproc_probe(struct platform_device *pdev)
> [...]
> > + chipsig = devm_request_and_ioremap(dev, chipsig_res);
> > + if (!chipsig) {
> > + dev_err(dev, "unable to map CHIPSIG register\n");
> > + return -EINVAL;
>
> Why -EINVAL? Comment to devm_request_and_ioremap() suggests
> returning
> -EADDRNOTAVAIL.
OK, sounds better, I will change it.
>
> > + }
> > +
> > + bootreg = devm_request_and_ioremap(dev, bootreg_res);
> > + if (!bootreg) {
> > + dev_err(dev, "unable to map boot register\n");
> > + return -EINVAL;
>
> Same here.
>
> > +static int __devexit da8xx_rproc_remove(struct platform_device
> *pdev)
> > +{
> > + struct rproc *rproc = platform_get_drvdata(pdev);
> > + struct da8xx_rproc *drproc = (struct da8xx_rproc *)rproc->priv;
> > + int ret;
> > +
> > + /*
> > + * The devm subsystem might end up releasing things before
> > + * freeing the irq, thus allowing an interrupt to sneak in while
> > + * the device is being removed. This should prevent that.
> > + */
> > + disable_irq(drproc->irq);
>
> Will the IRQ be enabled properly upon reloading the driver? You're
> effectively disabling it twice, once here and once in devm_free_irq(),
> aren't you?
I suppose I am. I recall reading somewhere (can't find it now) that when using devm_request_threaded_irq(), when you remove the driver the irq doesn't actually get auto-freed until after some driver resources have been freed, thus rendering the ISR unusable were it to fire, so it suggested disabling the irq in the driver "remove" function.
Regardless, the irq appears to get enabled properly on the next module insertion.
>
> > +static struct platform_driver da8xx_rproc_driver = {
> > + .probe = da8xx_rproc_probe,
> > + .remove = __devexit_p(da8xx_rproc_remove),
>
> Isn't _devexit_p() removed now? I thought __devinit and friends
> have all
> been removed in 3.8-rc1...
It appears that they're being deprecated for now, being #defined to empty. I will remove the macro usage and associated __dev* keywords.
>
> > diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> > index dd3bfaf..ac4449a 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> > @@ -1222,19 +1222,39 @@ struct rproc *rproc_alloc(struct device *dev,
> const char *name,
> > const char *firmware, int len)
> > {
> > struct rproc *rproc;
> > + char *template = "rproc-%s-fw";
> > + char *p;
> >
> > if (!dev || !name || !ops)
> > return NULL;
> >
> > + if (!firmware)
>
> It makes sense to use {} despite singkle-statement branch.
According to Documentation/CodingStyle:
Do not unnecessarily use braces where a single statement will do.
if (condition)
action();
>
> > + /*
>
> Indent with tabs please.
My bad, I will fix this (although I blame cut-and-paste, as well as it being a Friday night :)
>
> > + * Make room for default firmware name (minus %s plus
> '\0').
> > + * If the caller didn't pass in a firmware name then
> > + * construct a default name. We're already glomming 'len'
> > + * bytes onto the end of the struct rproc allocation, so do
> > + * a few more for the default firmware name (but only if
> > + * the caller doesn't pass one).
> > + */
> > + len += strlen(name) + strlen(template) - 2 + 1;
>
> Same here.
>
> > rproc = kzalloc(sizeof(struct rproc) + len, GFP_KERNEL);
> > if (!rproc) {
> > dev_err(dev, "%s: kzalloc failed\n", __func__);
> > return NULL;
> > }
> >
> > + if (!firmware) {
> > + p = (char *)rproc + sizeof(struct rproc) + len;
> > + sprintf(p, template, name);
> > + }
> > + else
> > + p = (char *)firmware;
> > +
> > + rproc->firmware = p;
>
> Same here.
This one does violate Documentation/CodingStyle, as it says:
if (condition) {
do_this();
do_that();
} else {
otherwise();
}
I will correct this.
>
> WBR, Sergei
>
^ permalink raw reply
* [GIT PULL v3] arm-soc: Xilinx zynq timer changes for v3.9
From: Olof Johansson @ 2013-01-30 2:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHTX3d+tDZF1-aKKfx+Zsb4FefrBbLaxe9qAz1Vsf3rDb-qHTw@mail.gmail.com>
On Mon, Jan 28, 2013 at 01:53:11PM +0100, Michal Simek wrote:
> btw: As I mentioned in the previous email I want to add 2 defconfig
> updates + maintainer
> fragment. I have created branch zynq/misc in the same repo. Is this
> name ok for you?
> If yes, I will send you separate pull request just for this branch.
Actually, since I alreayd had two of those patches, I just cherry-picked over
your MAINTAINERS entry and applied it directly.
-Olof
^ permalink raw reply
* [GIT PULL] CSR SiRFmarco SoC infrastructures for 3.9
From: Barry Song @ 2013-01-30 3:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgHpEaR4Hxjw1esMbqvvpRA5_rDE=ahKunwJ70FDJmNKQ@mail.gmail.com>
> -----Original Message-----
> From: Olof Johansson [mailto:olof at lixom.net]
> Sent: Wednesday, January 30, 2013 3:04 AM
> To: Barry Song
> Cc: Arnd Bergmann; linux-arm-kernel at lists.infradead.org;
> DL-SHA-WorkGroupLinux
> Subject: Re: [GIT PULL] CSR SiRFmarco SoC infrastructures for 3.9
>
> On Tue, Jan 29, 2013 at 8:51 AM, Olof Johansson <olof@lixom.net> wrote:
> > On Mon, Jan 28, 2013 at 06:08:27PM +0800, Barry Song wrote:
> >> 2013/1/28 Olof Johansson <olof@lixom.net>:
> >> > On Thu, Jan 24, 2013 at 11:21:02AM +0800, Barry Song wrote:
> >> >> Hi Olof, Arnd,
> >> >>
> >> >> pls pull the following changes for CSR SiRFmarco SoC. it has been
> >> >> rebased againest arm-soc timer/cleanup tree.
> >> >>
> >> >> since commit 90cf214d6a549bf482e3c5751ee256cc885b96ea:
> >> >>
> >> >> ARM: at91: fix board-rm9200-dt after sys_timer conversion
> >> >> (2013-01-14 10:14:04 -0800)
> >> >>
> >> >> are available in the git repository at:
> >> >> git://gitorious.org/sirfprima2-kernel/sirfprima2-kernel.git
> >> >> marco-timer-cleanup-rebase
> >> >
> >> > Pulled in as prima2/marco, included in next/soc. Thanks!
> >>
> >> Olof, thanks.
> >>
> >> >
> >> > I noticed that there is no defconfig for any mach-prima2 platforms. Feel
> >> > free to submit one so we get build coverage of the platform.
> >>
> >> there have been. arch/arm/configs/prima2_defconfig
> >
> > Ah, it enables ARCH_SIRF, I was searching for ARCH_PRIMA2 or
> ARCH_MARCO. Good.
>
> ..and it's broken due to interaction with the gic-vic move. :(
>
> Barry, can you please follow up with a patch to do the corresponding
> changes for prima?
Ok. I'll take care.
>
>
> Thanks,
>
> -Olof
>
-barry
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
^ permalink raw reply
* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: H. Peter Anvin @ 2013-01-30 3:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129101549.GP23505@n2100.arm.linux.org.uk>
On 01/29/2013 02:15 AM, Russell King - ARM Linux wrote:
> On Mon, Jan 28, 2013 at 02:25:10PM -0800, Andrew Morton wrote:
>> What's this "with enabled unaligned memory access" thing? You mean "if
>> the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS"? If so,
>> that's only x86, which isn't really in the target market for this
>> patch, yes?
>>
>> It's a lot of code for a 50ms boot-time improvement. Does anyone have
>> any opinions on whether or not the benefits are worth the cost?
>
> Well... when I saw this my immediate reaction was "oh no, yet another
> decompressor for the kernel". We have five of these things already.
> Do we really need a sixth?
>
> My feeling is that we should have:
> - one decompressor which is the fastest
> - one decompressor for the highest compression ratio
> - one popular decompressor (eg conventional gzip)
>
> And if we have a replacement one for one of these, then it should do
> exactly that: replace it. I realise that various architectures will
> behave differently, so we should really be looking at numbers across
> several arches.
>
> Otherwise, where do we stop adding new ones? After we have 6 of these
> (which is after this one). After 12? After the 20th?
>
The only concern I have with that is if someone paints themselves into a
corner and absolutely wants, say, LZO.
Otherwise, per your list it pretty much sounds like we should have lz4,
gzip, and xz.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* [PATCH 3/7] ARM: DT: tegra114: add APB DMA controller DT entry
From: Laxman Dewangan @ 2013-01-30 3:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510809FC.2080806@wwwdotorg.org>
On Tuesday 29 January 2013 11:12 PM, Stephen Warren wrote:
> On 01/29/2013 05:56 AM, Laxman Dewangan wrote:
>> NVIDIA's Tegra114 has 32 channels APB DMA controller. Add DT entry for
>> APB DMA controllers and make it compatible with "nvidia,tegra114-apbdma".
> The APB DMA controller node needs a clocks property. The same goes for
> I2C and KBC. I'd like to avoid merging those 3 patches until the
> Tegra114 clock patches are present, since the nodes won't be useful
> until then anyway. I expect the clock patches will be merged in 3.10.
>
I think clock patches can be posted on top of this as Peter is working.
Although, the driver will fail in clk_get() but still I think this can
be apply to populate the dts file with controller specific information.
^ permalink raw reply
* [PATCH] ARM: imx: fix imx31-dt.c time-related warning
From: Stephen Warren @ 2013-01-30 3:56 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Warren <swarren@nvidia.com>
Commit 6bb27d7 "ARM: delete struct sys_timer" caused the following:
arch/arm/mach-imx/imx31-dt.c:56:2: warning: initialization from incompatible pointer type [enabled by default]
arch/arm/mach-imx/imx31-dt.c:56:2: warning: (near initialization for ?__mach_desc_IMX31_DT.init_time?) [enabled by default]
This is because mx31_clocks_init_dt() returns int, whereas the .init_time
field prototype expects a function returning void. Implement a wrapper so
that the prototypes match.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
This patch is based on arm-soc's timer/cleanup branch, which contains
the commit mentioned above.
---
arch/arm/mach-imx/imx31-dt.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/imx31-dt.c b/arch/arm/mach-imx/imx31-dt.c
index f9a6909..b5c04ee 100644
--- a/arch/arm/mach-imx/imx31-dt.c
+++ b/arch/arm/mach-imx/imx31-dt.c
@@ -43,12 +43,17 @@ static const char *imx31_dt_board_compat[] __initdata = {
NULL
};
+static void __init imx31_dt_timer_init(void)
+{
+ mx31_clocks_init_dt();
+}
+
DT_MACHINE_START(IMX31_DT, "Freescale i.MX31 (Device Tree Support)")
.map_io = mx31_map_io,
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
.handle_irq = imx31_handle_irq,
- .init_time = mx31_clocks_init_dt,
+ .init_time = imx31_dt_timer_init,
.init_machine = imx31_dt_init,
.dt_compat = imx31_dt_board_compat,
.restart = mxc_restart,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/7] ARM: DT: tegra114: add APB DMA controller DT entry
From: Stephen Warren @ 2013-01-30 4:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5108998B.4040809@nvidia.com>
On 01/29/2013 08:54 PM, Laxman Dewangan wrote:
> On Tuesday 29 January 2013 11:12 PM, Stephen Warren wrote:
>> On 01/29/2013 05:56 AM, Laxman Dewangan wrote:
>>> NVIDIA's Tegra114 has 32 channels APB DMA controller. Add DT entry for
>>> APB DMA controllers and make it compatible with
>>> "nvidia,tegra114-apbdma".
>> The APB DMA controller node needs a clocks property. The same goes for
>> I2C and KBC. I'd like to avoid merging those 3 patches until the
>> Tegra114 clock patches are present, since the nodes won't be useful
>> until then anyway. I expect the clock patches will be merged in 3.10.
>
> I think clock patches can be posted on top of this as Peter is working.
> Although, the driver will fail in clk_get() but still I think this can
> be apply to populate the dts file with controller specific information.
While it would be physically possible for me to apply these patches now
and rely on Peter to add the clocks properties later, there's no point
in doing so, since as you say the drivers won't work with just these
patches. There will be less churn if we simply wait for the Tegra114
clock driver first, and then apply patches to add complete and working
DT nodes for all the devices.
^ permalink raw reply
* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: 이경식 @ 2013-01-30 4:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129225508.GC30535@twin.jikos.cz>
> -----Original Message-----
> From: David Sterba [mailto:dsterba at suse.cz]
> Sent: Wednesday, January 30, 2013 7:55 AM
> To: Kyungsik Lee
> Cc: Russell King; Thomas Gleixner; Ingo Molnar; H. Peter Anvin; Michal
> Marek; linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> linux-kbuild at vger.kernel.org; x86 at kernel.org; Nitin Gupta; Richard Purdie;
> Josh Triplett; Joe Millenbach; Andrew Morton; Albin Tonnerre;
> hyojun.im at lge.com; chan.jeong at lge.com; gunho.lee at lge.com;
> minchan.kim at lge.com; namhyung.kim at lge.com; raphael.andy.lee at gmail.com
> Subject: Re: [RFC PATCH 0/4] Add support for LZ4-compressed kernels
>
> On Sat, Jan 26, 2013 at 02:50:43PM +0900, Kyungsik Lee wrote:
> > This patchset is for supporting LZ4 compressed kernel and initial
> > ramdisk on the x86 and ARM architectures.
>
> Have you considered the 'high compression' mode of lz4?
> http://code.google.com/p/lz4/source/browse/trunk/lz4hc.c
>
Yes, The high compression mode of lz4 is set as default
in the submitted patch. The figure shows:
Uncompressed size: 13MB
lz4: Normal compression mode
output size: 8.1MB (62.7%)
decompression time: 232ms(148ms, with enabled unaligned memory access)
lz4: High compression mode
output size: 6.8MB (52.3%)
decompression time: 251ms(167ms)
The size of output in NC(Normal Compression) is bigger than HC(High Compression)
But decompression in NC is a bit faster than HC in ARM based board.
I assume that
> The compression format remains the same, the compressor tries harder (but
> is slower), resulting compression ratio is better.
>
> an examle compression for vmlinux.bin of x86_64 build:
>
> input size: 16509520 bytes
>
> lz4 (svn 88):
> output size: 6393684 (38.7%)
> compression time: 41.7 ms (395 MB/s)
> decompression time: 13.7 ms (1204 MB/s)
>
> lz4hc (svn 88):
> output size: 5319137 (32.2%)
> compression time: 683 ms (24 MB/s)
> decompression time: 13.1 ms (1259 MB/s)
>
> compressed file delta: 6393684 - 5319137 = 1074547 ~ 1MB
>
> tested on a Nehalem box; same test on my slow desktop gives
>
> lz4:
> compression time: 97 ms (169 MB/s)
> decompression time: 25.7 ms (643 MB/s)
>
> lz4hc:
> compression time: 1386 ms (11 MB/s)
> decompression time: 26 ms (619 MB/s)
>
> While the decompression time is almost the same, image size is smaller.
> The kernel image compression is run in userspace and the low speed is not
> much of concern for a one-time operation.
>
> For the reference, lzo (current kernel version) run on the destktop:
>
> output size: 6026256 (36.5%)
> decompression time: 79.6 ms (207 MB/s)
>
> > It seems that it?s worth trying LZ4 compressed kernel image or ramdisk
> > for making the kernel boot more faster.
>
> There's another potential user of lz4: btrfs. I've submitted a feature
> preview integrating lz4 compression
> http://thread.gmane.org/gmane.comp.file-systems.btrfs/15744
> and we have tried to integrate the HC mode as well
> http://thread.gmane.org/gmane.comp.file-systems.btrfs/18165
> .
> So far it's on a slow track, conceptually it works, but I the code needs
> some work so it could live under lib/* (we've used the svn sources with
> minor changes, no kernel coding style). It would be easier for me to
> enhance the existing lib/lz4/* codebase.
>
> Also zram could consider lz4, I'm not sure if there are other potential
> users.
>
>
> david
^ permalink raw reply
* [PATCH v2 08/27] pci: implement an emulated PCI-to-PCI bridge
From: Jason Gunthorpe @ 2013-01-30 4:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301292306.14012.arnd@arndb.de>
On Tue, Jan 29, 2013 at 11:06:13PM +0000, Arnd Bergmann wrote:
> On Tuesday 29 January 2013, Bjorn Helgaas wrote:
> > If you need this, it can be done in architecture code, can't it? It's
> > true that there's nothing architecture-specific in this patch (other
> > than the fact that ARM is the only arch that needs it), but I'm not
> > sure there's anything useful for sharing here.
>
> Since we're moving the host bridge code to drivers/pci/host now, I think
> this code should live in the same place. It's entirely possible that
> it will be shared between arch/arm and arch/arm64, although I would
> hope that we can do away with the emulated bridge code entirely.
This sounds right to me, this is part of the host bridge driver for
various Marvell SOCs, so these days it should live in the
drivers/pci/host or related, not arch/arm.
> > In fact, it seems like what you're after is not so much an emulated
> > bridge that has no corresponding hardware, as it is a wrapper that
> > presents a standard PCIe interface to hardware that exists but doesn't
> > conform to the PCIe spec. If you really do need to ultimately connect
> > this pci_sw_pci_bridge to a piece of hardware, that will certainly be
> > arch-specific.
>
> As Jason Gunthorpe suggested, we might not need this at all, if the
> Linux PCI code can be convinced not to need a configuration space
> for the devices that in case of the Marvell hardware don't provide
> one.
To be clear, that isn't what I was talking about.. Just to clarify a
few things in the last couple emails:
The PCI 'host bridge configuration space' software emulation code in
patch #7 is not necessary. Bjorn and Thierry both confirm this.
In several places when Bjorn/Arnd talked about a 'host bridge' this is
referring to (more or less) the PCI host *driver* and its attachment
to the kernel interfaces. Specifically a configuration access
mechanism and the resource ranges to allocate against. It has nothing
to do with the bus 0, device 0, function 0 host bridge config space.
Arnd's suggestion to use multiple domains would be broadly equivilent
to the first iteration of this driver - essentially the driver would
manage one link and there would be multiple instances. This gets us
back to where Thomas started - there is currently no code to do cross
domain resource allocation, and static allocation is not possible with
so many links on the chip.
Bjorn is quite right, the purpose of the PCI-PCI SW layer is to bind
the non-standard registers in the Marvell SOC to the standard PCI-E
config interface so the kernel can control it normally. This corrects
what is, IMHO, a defect in the Marvell hardware.
The alternative is to add some kind of cross-domain resource
allocation (or similar) to the PCI core code - however this would
*only* be required to support hardware broken in the same way as
Marvell, so I feel a bit leery about doing that kind of work before we
know if other chips require this. (early on in the discussion there
was some thought that Tegra might also be similary broken, but it
turned out to be pretty much fine, with a bit of driver work)
So, I still think using a SW layer to provide a compliant PCI-PCI
bridge configuration space for the Marvell hardware is the best way
forward..
Jason
^ permalink raw reply
* [PATCH] ARM:kernel checking failure after call vmalloc
From: Chen Gang @ 2013-01-30 4:13 UTC (permalink / raw)
To: linux-arm-kernel
need checking failure after call vmalloc.
if fail:
need return fail code (-ENOMEM, long will be signed cast to int)
also need call etb_lock(t) to lock again.
better to let vmalloc code above etb_writel(... ETBR_READADDR).
Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
arch/arm/kernel/etm.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
index 9b6de8c..fbe51a3 100644
--- a/arch/arm/kernel/etm.c
+++ b/arch/arm/kernel/etm.c
@@ -287,14 +287,20 @@ static ssize_t etb_read(struct file *file, char __user *data,
etb_unlock(t);
total = etb_getdatalen(t);
+ length = min(total * 4, (int)len);
+
+ buf = vmalloc(length);
+ if (!buf) {
+ etb_lock(t);
+ length = -ENOMEM;
+ goto out;
+ }
+
if (total == t->etb_bufsz)
first = etb_readl(t, ETBR_WRITEADDR);
etb_writel(t, first, ETBR_READADDR);
- length = min(total * 4, (int)len);
- buf = vmalloc(length);
-
dev_dbg(t->dev, "ETB buffer length: %d\n", total);
dev_dbg(t->dev, "ETB status reg: %x\n", etb_readl(t, ETBR_STATUS));
for (i = 0; i < length / 4; i++)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] drivers: net: cpsw: Add helper functions for VLAN ALE implementation
From: Mugunthan V N @ 2013-01-30 4:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51085D6C.4050102@ti.com>
On 1/30/2013 5:08 AM, Cyril Chemparathy wrote:
> On 01/28/2013 03:12 PM, Mugunthan V N wrote:
>> Add helper functions for VLAN ALE implementations for Add, Delete
>> Dump VLAN related ALE entries
>>
>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>> ---
>> drivers/net/ethernet/ti/cpsw_ale.c | 172
>> ++++++++++++++++++++++++++++++++++--
>> drivers/net/ethernet/ti/cpsw_ale.h | 11 +++
>> 2 files changed, 178 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ti/cpsw_ale.c
>> b/drivers/net/ethernet/ti/cpsw_ale.c
>> index 0e9ccc2..0d7a60a 100644
>> --- a/drivers/net/ethernet/ti/cpsw_ale.c
>> +++ b/drivers/net/ethernet/ti/cpsw_ale.c
>
> [...]
>
>> +int cpsw_ale_add_vlan(struct cpsw_ale *ale, u16 vid, int port, int
>> untag,
>> + int reg_mcast, int unreg_mcast)
>
> [...]
>
>> +int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int port)
>
> [...]
>
>> +int cpsw_ale_vlan_add_ucast(struct cpsw_ale *ale, u8 *addr, int port,
>> + int flags, u16 vid)
>
> [...]
>
>> +int cpsw_ale_vlan_del_ucast(struct cpsw_ale *ale, u8 *addr, int
>> port, u16 vid)
>
> [...]
>
>> +int cpsw_ale_vlan_add_mcast(struct cpsw_ale *ale, u8 *addr,
>> + int port_mask, u16 vid, int super, int mcast_state)
>
> [...]
>
>> +int cpsw_ale_vlan_del_mcast(struct cpsw_ale *ale, u8 *addr,
>> + int port_mask, u16 vid)
>
> Are the VLAN and non-VLAN variants different enough to justify
> separate implementations for all these functions? Could we collapse
> these by generalizing the original to take an optional vlan argument
> instead?
>
> Thanks
> -- Cyril.
Since vid is u16, any value to vid is valid, so only i have proposed new
api for vlan.
add vlan and delete vlan has to be seperate vlan since these are new
apis. Will merge
other api to existing api with additional vlan parameter.
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Jason Gunthorpe @ 2013-01-30 4:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301292254.01069.arnd@arndb.de>
On Tue, Jan 29, 2013 at 10:54:00PM +0000, Arnd Bergmann wrote:
> I'm actually fine with either of the two suggestions you mentioned above,
> whichever is easier to implement and/or more closely matches what the
> hardware actually implements is better IMHO.
>
> The part that I did not like about having emulated PCI-to-PCI bridges
> is that it seems to just work around a (percieved or real) limitation
> in the Linux kernel by adding a piece of infrastructure, rather than
> lifting that limitation by making the kernel deal with what the
> hardware provides. That reminded me of the original mach-vt8500
Well.. in this case there is a standard - PCI-E for what HW vendors
are supposed to do. The kernel core code follows it and works with
compliant hardware.
Marvell HW is not compliant.
So..
Should the kernel core PCI code support this particular non-compliance?
Should the driver work around the non-compliance and present a
compliant interface to the kernel and userspace?
My take is the kernel core PCI code is fine, and I hope
this will be an isolated issue with one family of Marvell IP. So
working around the HW problem in the driver seems best.
If we learn of many more instances like this then, yah, update the
core code and rip out this driver work around...
Jason
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox