Re: [PATCHv2 4/8] clocksource: sun4i: Fix the next event code
On Fri, Jun 28, 2013 at 11:27:25PM +0200, Thomas Gleixner wrote:
> On Fri, 28 Jun 2013, Maxime Ripard wrote:
> > On Fri, Jun 28, 2013 at 10:13:08PM +0200, Thomas Gleixner wrote:
> > > On Fri, 28 Jun 2013, Maxime Ripard wrote:
> > > > @@ -61,9 +62,14 @@ static void sun4i_clkevt_mode(enum clock_event_mode
> > > > mode,
> > > > static int sun4i_clkevt_next_event(unsigned long evt,
> > > >struct clock_event_device *unused)
> > > > {
> > > > - u32 u = readl(timer_base + TIMER_CTL_REG(0));
> > > > - writel(evt, timer_base + TIMER_CNTVAL_REG(0));
> > > > - writel(u | TIMER_CTL_ENABLE | TIMER_CTL_AUTORELOAD,
> > > > + u32 val = readl(timer_base + TIMER_CTL_REG(0));
> > > > + writel(val & ~TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(0));
> > > > + udelay(1);
> > >
> > > That udelay() is more than suspicious. Is there really no other way to
> > > deal with that hardware?
> > >
> > > If no, you really need to put a proper explanation for that into the code.
> >
> > The datasheet states that you have to wait for two ticks of the timer
> > clock source (in that case, 24MHz, which makes it around 80-85ns) before
> > you can actually enable it back.
> >
> > I didn't came up with a better solution.
>
> 80-85ns is definitely way less than 1us.
>
> Why not reading the counter register and wait for 2 or 3 cycles to
> elapse instead of wasting a full microsecond evertime ?
Yes, but then we fall back to the discussion we had in the v1 about the
latch needed to read the counter, which would already take more time
than what we have to wait for.
Maybe we can use the second timer that we use for the clocksource
though: it's always running, already set up, work at the same rate and
we will only read it, so we won't change its monotonic nature.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH v2] x86: Use asm-goto to implement mutex fast path on x86-64
On Fri, Jun 28, 2013 at 7:14 AM, H. Peter Anvin wrote: > > As Ingo said, looks very nice. However, it is really too late for Linux > 3.11, so I'm going to put it on a queue I already have for 3.12. That's fine, I'm not in a hurry. 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/
Re: [PATCH v2 03/11] tracing: add soft disable for syscall events
On 2013/6/29 13:08, Tom Zanussi wrote:
> Add support for SOFT_DISABLE to syscall events.
>
> The original SOFT_DISABLE patches didn't add support for soft disable
> of syscall events; this adds it and paves the way for future patches
> allowing triggers to be added to syscall events, since triggers are
> built on top of SOFT_DISABLE.
>
> The existing code grabs the trace_array from the ftrace_file passed to
> the event registration functions and passes that to the probe
> functions. Passing the file instead allows the probe functions to
> access not only the trace_array attached to the file but the flags as
> well.
>
> Signed-off-by: Tom Zanussi
> ---
> kernel/trace/trace_syscalls.c | 20 ++--
> 1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
> index 8f2ac73..1765088 100644
> --- a/kernel/trace/trace_syscalls.c
> +++ b/kernel/trace/trace_syscalls.c
> @@ -301,7 +301,8 @@ static int __init syscall_exit_define_fields(struct
> ftrace_event_call *call)
>
> static void ftrace_syscall_enter(void *data, struct pt_regs *regs, long id)
> {
> - struct trace_array *tr = data;
> + struct ftrace_event_file *ftrace_file = data;
> + struct trace_array *tr = ftrace_file->tr;
> struct syscall_trace_enter *entry;
> struct syscall_metadata *sys_data;
> struct ring_buffer_event *event;
> @@ -319,6 +320,9 @@ static void ftrace_syscall_enter(void *data, struct
> pt_regs *regs, long id)
> if (!sys_data)
> return;
>
> + if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, &ftrace_file->flags))
> + return;
> +
> size = sizeof(*entry) + sizeof(unsigned long) * sys_data->nb_args;
>
> buffer = tr->trace_buffer.buffer;
> @@ -338,7 +342,8 @@ static void ftrace_syscall_enter(void *data, struct
> pt_regs *regs, long id)
>
> static void ftrace_syscall_exit(void *data, struct pt_regs *regs, long ret)
> {
> - struct trace_array *tr = data;
> + struct ftrace_event_file *ftrace_file = data;
> + struct trace_array *tr = ftrace_file->tr;
> struct syscall_trace_exit *entry;
> struct syscall_metadata *sys_data;
> struct ring_buffer_event *event;
> @@ -355,6 +360,9 @@ static void ftrace_syscall_exit(void *data, struct
> pt_regs *regs, long ret)
> if (!sys_data)
> return;
>
> + if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, &ftrace_file->flags))
> + return;
> +
> buffer = tr->trace_buffer.buffer;
> event = trace_buffer_lock_reserve(buffer,
> sys_data->exit_event->event.type, sizeof(*entry), 0, 0);
> @@ -382,7 +390,7 @@ static int reg_event_syscall_enter(struct
> ftrace_event_file *file,
> return -ENOSYS;
> mutex_lock(&syscall_trace_lock);
> if (!tr->sys_refcount_enter)
> - ret = register_trace_sys_enter(ftrace_syscall_enter, tr);
> + ret = register_trace_sys_enter(ftrace_syscall_enter, file);
> if (!ret) {
> set_bit(num, tr->enabled_enter_syscalls);
> tr->sys_refcount_enter++;
Is this change can work correctly?
It seems that all syscalls in same tr will use same ftrace_event_file(first
registered)
in ftrace_syscall_enter/ftrace_syscall_exit, obviously this is wrong.
Basically I think we still need pass tr into register_trace_sys_enter/exit, for
performance reason. If you use ftrace_event_file as argument, then when your are
using command 'perf stat -e syscalls:* -a sleep 10',
it will looping NR_SYSCALLS tracepoints for every syscall enter and exit,
that's unacceptable.
Thanks.
> @@ -404,7 +412,7 @@ static void unreg_event_syscall_enter(struct
> ftrace_event_file *file,
> tr->sys_refcount_enter--;
> clear_bit(num, tr->enabled_enter_syscalls);
> if (!tr->sys_refcount_enter)
> - unregister_trace_sys_enter(ftrace_syscall_enter, tr);
> + unregister_trace_sys_enter(ftrace_syscall_enter, file);
> mutex_unlock(&syscall_trace_lock);
> }
>
> @@ -420,7 +428,7 @@ static int reg_event_syscall_exit(struct
> ftrace_event_file *file,
> return -ENOSYS;
> mutex_lock(&syscall_trace_lock);
> if (!tr->sys_refcount_exit)
> - ret = register_trace_sys_exit(ftrace_syscall_exit, tr);
> + ret = register_trace_sys_exit(ftrace_syscall_exit, file);
> if (!ret) {
> set_bit(num, tr->enabled_exit_syscalls);
> tr->sys_refcount_exit++;
> @@ -442,7 +450,7 @@ static void unreg_event_syscall_exit(struct
> ftrace_event_file *file,
> tr->sys_refcount_exit--;
> clear_bit(num, tr->enabled_exit_syscalls);
> if (!tr->sys_refcount_exit)
> - unregister_trace_sys_exit(ftrace_syscall_exit, tr);
> + unregister_trace_sys_exit(ftrace_syscall_exit, file);
> mutex_unlock(&syscall_trace_lock);
> }
>
>
--
To unsubscribe from this list:
[PATCH] mmc: omap_hsmmc: clear status flags before starting a new command
Commit 1f6b9fa40e76fffaaa0b3bd6a0bfdcf1cdc06efa consolidated writes to the STAT register in one location, moving them from omap_hsmmc_do_irq() to omap_hsmmc_irq(). This move has the unwanted side effect that the controller status flags are potentially cleared after a new command has been started as a consequence of reading the previous status flags. This means that if the new command changes the status flags before the IRQ routine returns, those flags may be cleared without handling the event which asserted them, and thus missing the event. Move the writing of the STAT register back in omap_hsmmc_do_irq(), before handling the status flags which generated the interrupt. Signed-off-by: Francesco Lavra --- drivers/mmc/host/omap_hsmmc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index eccedc7..301cb7e 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1041,6 +1041,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host *host, int status) } } + OMAP_HSMMC_WRITE(host->base, STAT, status); if (end_cmd || ((status & CC_EN) && host->cmd)) omap_hsmmc_cmd_done(host, host->cmd); if ((end_trans || (status & TC_EN)) && host->mrq) @@ -1060,7 +1061,6 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id) omap_hsmmc_do_irq(host, status); /* Flush posted write */ - OMAP_HSMMC_WRITE(host->base, STAT, status); status = OMAP_HSMMC_READ(host->base, STAT); } -- 1.7.5.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: [ 102/127] iommu/amd: Workaround for ERBT1312
Joerg Roedel wrote: > Alex, Andreas, > > On Fri, Jun 28, 2013 at 08:42:05PM +0200, Andreas Hartmann wrote: >> You're right, there is exactly one entry directly after loading of vfio. >> I can see this message, too, with linux 3.4.43. > > Can you please test this patch? It should reduce the noise > significantly, but a few of those error messages are still expected. Sorry, but it doesn't work for me at all :-(. Behaviour is unchanged. It is exactly as described in the other mail: at the moment of binding vfio to 14.0, the fire begins. echo "1002 4385" > /sys/bus/pci/drivers/vfio-pci/new_id echo :00:14.0 > /sys/bus/pci/devices/:00:14.0/driver/unbind echo :00:14.0 > /sys/bus/pci/drivers/vfio-pci/bind Regards, Andreas -- 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/6] net/trivial: replace numeric with standard PM state macros
From: Yijing Wang Date: Thu, 27 Jun 2013 20:53:42 +0800 > Use standard PM state macros PCI_Dx instead of numeric 0/1/2.. > > Signed-off-by: Yijing Wang Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] ssb/trivial: replace numeric with standard PM state macros
From: Yijing Wang Date: Thu, 27 Jun 2013 21:00:11 +0800 > Use standard PM state macros PCI_Dx instead of numeric 0/1/2.. > > Signed-off-by: Yijing Wang Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 09/11] tracing: add 'enable_event' and 'disable_event' event trigger commands
Add 'enable_event' and 'disable_event' event_command commands.
enable_event and disable_event event triggers are added by the user
via these commands in a similar way and using practically the same
syntax as the analagous 'enable_event' and 'disable_event' ftrace
function commands, but instead of writing to the set_ftrace_filter
file, the enable_event and disable_event triggers are written to the
per-event 'trigger' files:
echo 'enable_event:system:event' > .../othersys/otherevent/trigger
echo 'disable_event:system:event' > .../othersys/otherevent/trigger
The above commands will enable or disable the 'system:event' trace
events whenever the othersys:otherevent events are hit.
This also adds a 'count' version that limits the number of times the
command will be invoked:
echo 'enable_event:system:event:N' > .../othersys/otherevent/trigger
echo 'disable_event:system:event:N' > .../othersys/otherevent/trigger
Where N is the number of times the command will be invoked.
The above commands will will enable or disable the 'system:event'
trace events whenever the othersys:otherevent events are hit, but only
N times.
This also makes the find_event_file() helper function extern, since
it's useful to use from other places, such as the event triggers code,
so make it accessible.
Signed-off-by: Tom Zanussi
---
include/linux/ftrace_event.h| 1 +
kernel/trace/trace.h| 4 +
kernel/trace/trace_events.c | 2 +-
kernel/trace/trace_events_trigger.c | 365
4 files changed, 371 insertions(+), 1 deletion(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 51c141e..57ca386 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -319,6 +319,7 @@ enum trigger_mode {
TM_TRACE_ONOFF = (1 << 0),
TM_SNAPSHOT = (1 << 1),
TM_STACKTRACE = (1 << 2),
+ TM_EVENT_ENABLE = (1 << 3),
};
extern void destroy_preds(struct ftrace_event_call *call);
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index dd27b69..0dd2fc2 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1021,6 +1021,10 @@ extern void trace_event_enable_cmd_record(bool enable);
extern int event_trace_add_tracer(struct dentry *parent, struct trace_array
*tr);
extern int event_trace_del_tracer(struct trace_array *tr);
+extern struct ftrace_event_file *find_event_file(struct trace_array *tr,
+const char *system,
+const char *event);
+
extern struct mutex event_mutex;
extern struct list_head ftrace_events;
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 3153389f..616a89f 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1877,7 +1877,7 @@ struct event_probe_data {
boolenable;
};
-static struct ftrace_event_file *
+struct ftrace_event_file *
find_event_file(struct trace_array *tr, const char *system, const char *event)
{
struct ftrace_event_file *file;
diff --git a/kernel/trace/trace_events_trigger.c
b/kernel/trace/trace_events_trigger.c
index dd14e36..2300fc8 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -803,6 +803,359 @@ static __init void
unregister_trigger_traceon_traceoff_cmds(void)
&trigger_cmd_mutex);
}
+/* Avoid typos */
+#define ENABLE_EVENT_STR "enable_event"
+#define DISABLE_EVENT_STR "disable_event"
+
+static void
+event_enable_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ if (data->enable)
+ clear_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT,
&data->file->flags);
+ else
+ set_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, &data->file->flags);
+}
+
+static void
+event_enable_count_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ if (!data->count)
+ return;
+
+ /* Skip if the event is in a state we want to switch to */
+ if (data->enable == !(data->file->flags &
FTRACE_EVENT_FL_SOFT_DISABLED))
+ return;
+
+ if (data->count != -1)
+ (data->count)--;
+
+ event_enable_trigger(_data);
+}
+
+static int
+event_enable_trigger_print(struct seq_file *m, struct event_trigger_ops *ops,
+ void *_data)
+{
+ struct event_trigger_data *data = _data;
+
+ seq_printf(m, "%s:%s:%s",
+ data->enable ? ENABLE_EVENT_STR : DISABLE_EVENT_STR,
+ data->file->event_call->class->system,
+
[PATCH v2 11/11] tracing: add documentation for trace event triggers
Provide a basic overview of trace event triggers and document the
available trigger commands, along with a few simple examples.
Signed-off-by: Tom Zanussi
---
Documentation/trace/events.txt | 207 +
1 file changed, 207 insertions(+)
diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt
index bb24c2a..b39610f 100644
--- a/Documentation/trace/events.txt
+++ b/Documentation/trace/events.txt
@@ -278,3 +278,210 @@ their old filters):
prev_pid == 0
# cat sched_wakeup/filter
common_pid == 0
+
+6. Event triggers
+=
+
+Trace events can be made to conditionally invoke trigger 'commands'
+which can take various forms and are described in detail below;
+examples would be enabling or disabling other trace events or invoking
+a stack trace whenever the trace event is hit. Whenever a trace event
+with attached triggers is invoked, the set of trigger commands
+associated with that event is invoked. Any given trigger can
+additionally have an event filter of the same form as described in
+section 5 (Event filtering) associated with it - the command will only
+be invoked if the event being invoked passes the associated filter.
+If no filter is associated with the trigger, it always passes.
+
+Triggers are added to and removed from a particular event by writing
+trigger expressions to the 'trigger' file for the given event.
+
+A given event can have any number of triggers associated with it,
+subject to any restrictions that individual commands may have in that
+regard.
+
+Event triggers are implemented on top of "soft" mode, which means that
+whenever a trace event has one or more triggers associated with it,
+the event is activated even if it isn't actually enabled, but is
+disabled in a "soft" mode. That is, the tracepoint will be called,
+but just will not be traced, unless of course it's actually enabled.
+This scheme allows triggers to be invoked even for events that aren't
+enabled, and also allows the current event filter implementation to be
+used for conditionally invoking triggers.
+
+The syntax for event triggers is roughly based on the syntax for
+set_ftrace_filter 'ftrace filter commands' (see the 'Filter commands'
+section of Documentation/trace/ftrace.txt), but there are major
+differences and the implementation isn't currently tied to it in any
+way, so beware about making generalizations between the two.
+
+6.1 Expression syntax
+-
+
+Triggers are added by echoing the command to the 'trigger' file:
+
+ # echo 'command[:count] [if filter]' > trigger
+
+Triggers are removed by echoing the same command but starting with '!'
+to the 'trigger' file:
+
+ # echo '!command[:count] [if filter]' > trigger
+
+The [if filter] part isn't used in matching commands when removing, so
+leaving that off in a '!' command will accomplish the same thing as
+having it in.
+
+The filter syntax is the same as that described in the 'Event
+filtering' section above.
+
+For ease of use, writing to the trigger file using '>' currently just
+adds or removes a single trigger and there's no explicit '>>' support
+('>' actually behaves like '>>') or truncation support to remove all
+triggers (you have to use '!' for each one added.)
+
+6.2 Supported trigger commands
+--
+
+The following commands are supported:
+
+- enable_event/disable_event
+
+ These commands can enable or disable another trace event whenever
+ the triggering event is hit. When these commands are registered,
+ the other trace event is activated, but disabled in a "soft" mode.
+ That is, the tracepoint will be called, but just will not be traced.
+ The event tracepoint stays in this mode as long as there's a trigger
+ in effect that can trigger it.
+
+ For example, the following trigger causes kmalloc events to be
+ traced when a read system call is entered, and the :1 at the end
+ specifies that this enablement happens only once:
+
+ # echo 'enable_event:kmem:kmalloc:1' > \
+ /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger
+
+ The following trigger causes kmalloc events to stop being traced
+ when a read system call exits. This disablement happens on every
+ read system call exit:
+
+ # echo 'disable_event:kmem:kmalloc' > \
+ /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger
+
+ The format is:
+
+ enable_event::[:count]
+ disable_event::[:count]
+
+ To remove the above commands:
+
+ # echo '!enable_event:kmem:kmalloc:1' > \
+ /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger
+
+ # echo '!disable_event:kmem:kmalloc' > \
+ /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger
+
+ Note that there can be any number of enable/disable_event triggers
+ per triggering event, but there can only be one trigger per
+ triggered event. e.g. sys_enter_read can have triggers enabling both
+ kmem:kmalloc and sched:sched_switch, but can't have
[PATCH v2 04/11] tracing: fix disabling of soft disable
The comment on the soft disable 'disable' case of __ftrace_event_enable_disable() states that the soft disable bit should be cleared in that case, but currently only the soft mode bit is actually cleared. This essentially leaves the standard non-soft-enable enable/disable paths as the only way to clear the soft disable flag, but the soft disable bit should also be cleared when removing a trigger with '!'. Also, the SOFT_DISABLED bit should never be set if SOFT_MODE is cleared. This fixes the above discrepancies. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index ecb2609..51d4390 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -279,9 +279,11 @@ static int __ftrace_event_enable_disable(struct ftrace_event_file *file, } call->class->reg(call, TRACE_REG_UNREGISTER, file); } - /* If in SOFT_MODE, just set the SOFT_DISABLE_BIT */ + /* If in SOFT_MODE, just set the SOFT_DISABLE_BIT, else clear it */ if (file->flags & FTRACE_EVENT_FL_SOFT_MODE) set_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, &file->flags); + else + clear_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, &file->flags); break; case 1: /* -- 1.7.11.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 v2 02/11] tracing: add missing syscall_metadata comment
From: Tom Zanussi Add the missing syscall_metadata description for the enter_fields struct member. Signed-off-by: Tom Zanussi --- include/trace/syscall.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/trace/syscall.h b/include/trace/syscall.h index 84bc419..fed853f 100644 --- a/include/trace/syscall.h +++ b/include/trace/syscall.h @@ -16,6 +16,7 @@ * @nb_args: number of parameters it takes * @types: list of types as strings * @args: list of args as strings (args[i] matches types[i]) + * @enter_fields: list of fields for syscall_enter trace event * @enter_event: associated syscall_enter trace event * @exit_event: associated syscall_exit trace event */ -- 1.7.11.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 v2 01/11] tracing: simplify event_enable_read()
Rather than enumerating each permutation, build the enable state
string up from the combination of states. This also allows for the
simpler addition of more states.
Signed-off-by: Tom Zanussi
---
kernel/trace/trace_events.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 27963e2..ecb2609 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -624,17 +624,17 @@ event_enable_read(struct file *filp, char __user *ubuf,
size_t cnt,
loff_t *ppos)
{
struct ftrace_event_file *file = filp->private_data;
- char *buf;
+ char buf[4] = "0";
- if (file->flags & FTRACE_EVENT_FL_ENABLED) {
- if (file->flags & FTRACE_EVENT_FL_SOFT_DISABLED)
- buf = "0*\n";
- else if (file->flags & FTRACE_EVENT_FL_SOFT_MODE)
- buf = "1*\n";
- else
- buf = "1\n";
- } else
- buf = "0\n";
+ if (file->flags & FTRACE_EVENT_FL_ENABLED &&
+ !(file->flags & FTRACE_EVENT_FL_SOFT_DISABLED))
+ strcpy(buf, "1");
+
+ if (file->flags & FTRACE_EVENT_FL_SOFT_DISABLED ||
+ file->flags & FTRACE_EVENT_FL_SOFT_MODE)
+ strcat(buf, "*");
+
+ strcat(buf, "\n");
return simple_read_from_buffer(ubuf, cnt, ppos, buf, strlen(buf));
}
--
1.7.11.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 v2 06/11] tracing: add 'traceon' and 'traceoff' event trigger commands
Add 'traceon' and 'traceoff' ftrace_func_command commands. traceon
and traceoff event triggers are added by the user via these commands
in a similar way and using practically the same syntax as the
analagous 'traceon' and 'traceoff' ftrace function commands, but
instead of writing to the set_ftrace_filter file, the traceon and
traceoff triggers are written to the per-event 'trigger' files:
echo 'traceon' > .../tracing/events/somesys/someevent/trigger
echo 'traceoff' > .../tracing/events/somesys/someevent/trigger
The above command will turn tracing on or off whenever someevent is
hit.
This also adds a 'count' version that limits the number of times the
command will be invoked:
echo 'traceon:N' > .../tracing/events/somesys/someevent/trigger
echo 'traceoff:N' > .../tracing/events/somesys/someevent/trigger
Where N is the number of times the command will be invoked.
The above commands will will turn tracing on or off whenever someevent
is hit, but only N times.
The event_trigger_init() and event_trigger_free() are meant to be
common implementations of the event_trigger_ops init() and free() ops.
Most trigger_ops implementations will use these, but some will
override and possibly reuse them.
Signed-off-by: Tom Zanussi
---
include/linux/ftrace_event.h| 1 +
kernel/trace/trace_events_trigger.c | 313
2 files changed, 314 insertions(+)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 6cd5bbc..c794686 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -316,6 +316,7 @@ struct ftrace_event_file {
enum trigger_mode {
TM_NONE = (0),
+ TM_TRACE_ONOFF = (1 << 0),
};
extern void destroy_preds(struct ftrace_event_call *call);
diff --git a/kernel/trace/trace_events_trigger.c
b/kernel/trace/trace_events_trigger.c
index 1f0565c..f2b97b6 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -355,7 +355,320 @@ static void unregister_trigger(char *glob, struct
event_trigger_ops *ops,
data->ops->free(data->ops, (void **)&data);
}
+int
+event_trigger_print(const char *name, struct seq_file *m,
+ void *data, char *filter_str)
+{
+ long count = (long)data;
+
+ seq_printf(m, "%s", name);
+
+ if (count == -1)
+ seq_puts(m, ":unlimited");
+ else
+ seq_printf(m, ":count=%ld", count);
+
+ if (filter_str)
+ seq_printf(m, " if %s\n", filter_str);
+ else
+ seq_puts(m, "\n");
+
+ return 0;
+}
+
+static int
+event_trigger_init(struct event_trigger_ops *ops, void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ data->ref++;
+ return 0;
+}
+
+static void
+event_trigger_free(struct event_trigger_ops *ops, void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (WARN_ON_ONCE(data->ref <= 0))
+ return;
+
+ data->ref--;
+ if (!data->ref)
+ kfree(data);
+}
+
+static int
+event_trigger_callback(struct event_command *cmd_ops, void *cmd_data,
+ char *glob, char *cmd, char *param, int enabled)
+{
+ struct event_trigger_ops *trigger_ops;
+ struct event_trigger_data *trigger_data;
+ char *trigger = NULL;
+ char *number;
+ int ret;
+
+ if (!enabled)
+ return -EINVAL;
+
+ /* separate the trigger from the filter (t:n [if filter]) */
+ if (param && isdigit(param[0]))
+ trigger = strsep(¶m, " \t");
+
+ mutex_lock(&event_mutex);
+
+ trigger_ops = cmd_ops->get_trigger_ops(cmd, trigger);
+
+ ret = -ENOMEM;
+ trigger_data = kzalloc(sizeof(*trigger_data), GFP_KERNEL);
+ if (!trigger_data)
+ goto out;
+
+ trigger_data->count = -1;
+ trigger_data->ops = trigger_ops;
+ trigger_data->mode = cmd_ops->trigger_mode;
+ INIT_LIST_HEAD(&trigger_data->list);
+
+ if (glob[0] == '!') {
+ cmd_ops->unreg(glob+1, trigger_ops, trigger_data, cmd_data);
+ kfree(trigger_data);
+ ret = 0;
+ goto out;
+ }
+
+ if (trigger) {
+ number = strsep(&trigger, ":");
+
+ ret = -EINVAL;
+ if (!strlen(number))
+ goto out_free;
+
+ /*
+* We use the callback data field (which is a pointer)
+* as our counter.
+*/
+ ret = kstrtoul(number, 0, &trigger_data->count);
+ if (ret)
+ goto out_free;
+ }
+
+ if (!param) /* if param is non-empty, it's supposed to be a filter */
+ goto out_reg;
+
[PATCH v2 05/11] tracing: add basic event trigger framework
Add a 'trigger' file for each trace event, enabling 'trace event triggers' to be set for trace events. 'trace event triggers' are patterned after the existing 'ftrace function triggers' implementation except that triggers are written to per-event 'trigger' files instead of to a single file such as the 'set_ftrace_filter' used for ftrace function triggers. The implementation is meant to be entirely separate from ftrace function triggers, in order to keep the respective implementations relatively simple and to allow them to diverge. The event trigger functionality is built on top of SOFT_DISABLE functionality. It adds a TRIGGER_MODE bit to the ftrace_event_file flags which is checked when any trace event fires. Triggers set for a particular event need to be checked regardless of whether that event is actually enabled or not - getting an event to fire even if it's not enabled is what's already implemented by SOFT_DISABLE mode, so trigger mode directly reuses that. Event trigger essentially inherit the soft disable logic in __ftrace_event_enable_disable() while adding a bit of logic and trigger reference counting via tm_ref on top of that in a new trace_event_trigger_enable_disable() function. Because the base __ftrace_event_enable_disable() code now needs to be invoked from outside trace_events.c, a wrapper is also added for those usages. The triggers for an event are actually invoked via a new function, event_triggers_call(), and code is also added to invoke them for ftrace_raw_event calls as well as syscall events. The main part of the patch creates a new trace_events_trigger.c file to contain the trace event triggers implementation. The standard open, read, and release file operations are implemented here. The open() implementation sets up for the various open modes of the 'trigger' file. It creates and attaches the trigger iterator and sets up the command parser. If opened for reading set up the trigger seq_ops. The read() implementation parses the event trigger written to the 'trigger' file, looks up the trigger command, and passes it along to that event_command's func() implementation for command-specific processing. The release() implementation does whatever cleanup is needed to release the 'trigger' file, like releasing the parser and trigger iterator, etc. A couple of functions for event command registration and unregistration are added, along with a list to add them to and a mutex to protect them, as well as an (initially empty) registration function to add the set of commands that will be added by future commits, and call to it from the trace event initialization code. also added are a couple trigger-specific data structures needed for these implementations such as a trigger iterator and a struct for trigger-specific data. A couple structs consisting mostly of function meant to be implemented in command-specific ways, event_command and event_trigger_ops, are used by the generic event trigger command implementations. They're being put into trace.h alongside the other trace_event data structures and functions, in the expectation that they'll be needed in several trace_event-related files such as trace_events_trigger.c and trace_events.c. The event_command.func() function is meant to be called by the trigger parsing code in order to add a trigger instance to the corresponding event. It essentially coordinates adding a live trigger instance to the event, and arming the triggering the event. Every event_command func() implementation essentially does the same thing for any command: - choose ops - use the value of param to choose either a number or count version of event_trigger_ops specific to the command - do the register or unregister of those ops - associate a filter, if specified, with the triggering event The reg() and unreg() ops allow command-specific implementations for event_trigger_op registration and unregistration, and the get_trigger_ops() op allows command-specific event_trigger_ops selection to be parameterized. When a trigger instance is added, the reg() op essentially adds that trigger to the triggering event and arms it, while unreg() does the opposite. The set_filter() function is used to associate a filter with the trigger - if the command doesn't specify a set_filter() implementation, the command will ignore filters. Each command has an associated trigger_mode, which serves double duty, both as a unique identifier for the command as well as a value that can be used for setting a trigger mode bit during trigger invocation. The signature of func() adds a pointer to the event_command struct, used to invoke those functions, along with a command_data param that can be passed to the reg/unreg functions. This allows func() implementations to use command-specific blobs and supports code re-use. The event_trigger_ops.func() command corrsponds to the trigger 'probe' function that gets called when the triggering event is actually invoked. The other f
[PATCH v2 07/11] tracing: add 'snapshot' event trigger command
Add 'snapshot' ftrace_func_command. snapshot event triggers are added
by the user via this command in a similar way and using practically
the same syntax as the analogous 'snapshot' ftrace function command,
but instead of writing to the set_ftrace_filter file, the snapshot
event trigger is written to the per-event 'trigger' files:
echo 'snapshot' > .../somesys/someevent/trigger
The above command will turn on snapshots for someevent i.e. whenever
someevent is hit, a snapshot will be done.
This also adds a 'count' version that limits the number of times the
command will be invoked:
echo 'snapshot:N' > .../somesys/someevent/trigger
Where N is the number of times the command will be invoked.
The above command will snapshot N times for someevent i.e. whenever
someevent is hit N times, a snapshot will be done.
Also adds a new ftrace_alloc_snapshot() function - the ftrace snapshot
command defines code that allocates a snapshot, which would be nice to
be able to reuse, which this does.
Signed-off-by: Tom Zanussi
---
include/linux/ftrace_event.h| 1 +
kernel/trace/trace.c| 9
kernel/trace/trace.h| 1 +
kernel/trace/trace_events_trigger.c | 89 +
4 files changed, 100 insertions(+)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index c794686..a25daf3 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -317,6 +317,7 @@ struct ftrace_event_file {
enum trigger_mode {
TM_NONE = (0),
TM_TRACE_ONOFF = (1 << 0),
+ TM_SNAPSHOT = (1 << 1),
};
extern void destroy_preds(struct ftrace_event_call *call);
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index e71a8be..96f3cdc 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -5169,6 +5169,15 @@ static const struct file_operations
tracing_dyn_info_fops = {
};
#endif /* CONFIG_DYNAMIC_FTRACE */
+#if defined(CONFIG_TRACER_SNAPSHOT)
+int ftrace_alloc_snapshot(void)
+{
+ return alloc_snapshot(&global_trace);
+}
+#else
+int ftrace_alloc_snapshot(void) { return -ENOSYS; }
+#endif
+
#if defined(CONFIG_TRACER_SNAPSHOT) && defined(CONFIG_DYNAMIC_FTRACE)
static void
ftrace_snapshot(unsigned long ip, unsigned long parent_ip, void **data)
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 7dace36..dd27b69 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1060,6 +1060,7 @@ struct event_command {
extern int trace_event_enable_disable(struct ftrace_event_file *file,
int enable, int soft_disable);
+extern int ftrace_alloc_snapshot(void);
extern const char *__start___trace_bprintk_fmt[];
extern const char *__stop___trace_bprintk_fmt[];
diff --git a/kernel/trace/trace_events_trigger.c
b/kernel/trace/trace_events_trigger.c
index f2b97b6..90a59dc 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -634,6 +634,87 @@ static struct event_command trigger_traceoff_cmd = {
.get_trigger_ops= onoff_get_trigger_ops,
};
+static void
+snapshot_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ tracing_snapshot();
+}
+
+static void
+snapshot_count_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ if (!data->count)
+ return;
+
+ if (data->count != -1)
+ (data->count)--;
+
+ snapshot_trigger(_data);
+}
+
+static int
+register_snapshot_trigger(char *glob, struct event_trigger_ops *ops,
+ void *data, void *cmd_data)
+{
+ int ret = register_trigger(glob, ops, data, cmd_data);
+
+ if (ret > 0)
+ ftrace_alloc_snapshot();
+
+ return ret;
+}
+
+static int
+snapshot_trigger_print(struct seq_file *m, struct event_trigger_ops *ops,
+ void *_data)
+{
+ struct event_trigger_data *data = _data;
+
+ return event_trigger_print("snapshot", m, (void *)data->count,
+ data->filter_str);
+}
+
+static struct event_trigger_ops snapshot_trigger_ops = {
+ .func = snapshot_trigger,
+ .print = snapshot_trigger_print,
+ .init = event_trigger_init,
+ .free = event_trigger_free,
+};
+
+static struct event_trigger_ops snapshot_count_trigger_ops = {
+ .func = snapshot_count_trigger,
+ .print = snapshot_trigger_print,
+ .init = event_trigger_init,
+ .free = event_trigger_free,
+};
+
+static struct event_trigger_ops *
[PATCH v2 03/11] tracing: add soft disable for syscall events
Add support for SOFT_DISABLE to syscall events.
The original SOFT_DISABLE patches didn't add support for soft disable
of syscall events; this adds it and paves the way for future patches
allowing triggers to be added to syscall events, since triggers are
built on top of SOFT_DISABLE.
The existing code grabs the trace_array from the ftrace_file passed to
the event registration functions and passes that to the probe
functions. Passing the file instead allows the probe functions to
access not only the trace_array attached to the file but the flags as
well.
Signed-off-by: Tom Zanussi
---
kernel/trace/trace_syscalls.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 8f2ac73..1765088 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -301,7 +301,8 @@ static int __init syscall_exit_define_fields(struct
ftrace_event_call *call)
static void ftrace_syscall_enter(void *data, struct pt_regs *regs, long id)
{
- struct trace_array *tr = data;
+ struct ftrace_event_file *ftrace_file = data;
+ struct trace_array *tr = ftrace_file->tr;
struct syscall_trace_enter *entry;
struct syscall_metadata *sys_data;
struct ring_buffer_event *event;
@@ -319,6 +320,9 @@ static void ftrace_syscall_enter(void *data, struct pt_regs
*regs, long id)
if (!sys_data)
return;
+ if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, &ftrace_file->flags))
+ return;
+
size = sizeof(*entry) + sizeof(unsigned long) * sys_data->nb_args;
buffer = tr->trace_buffer.buffer;
@@ -338,7 +342,8 @@ static void ftrace_syscall_enter(void *data, struct pt_regs
*regs, long id)
static void ftrace_syscall_exit(void *data, struct pt_regs *regs, long ret)
{
- struct trace_array *tr = data;
+ struct ftrace_event_file *ftrace_file = data;
+ struct trace_array *tr = ftrace_file->tr;
struct syscall_trace_exit *entry;
struct syscall_metadata *sys_data;
struct ring_buffer_event *event;
@@ -355,6 +360,9 @@ static void ftrace_syscall_exit(void *data, struct pt_regs
*regs, long ret)
if (!sys_data)
return;
+ if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, &ftrace_file->flags))
+ return;
+
buffer = tr->trace_buffer.buffer;
event = trace_buffer_lock_reserve(buffer,
sys_data->exit_event->event.type, sizeof(*entry), 0, 0);
@@ -382,7 +390,7 @@ static int reg_event_syscall_enter(struct ftrace_event_file
*file,
return -ENOSYS;
mutex_lock(&syscall_trace_lock);
if (!tr->sys_refcount_enter)
- ret = register_trace_sys_enter(ftrace_syscall_enter, tr);
+ ret = register_trace_sys_enter(ftrace_syscall_enter, file);
if (!ret) {
set_bit(num, tr->enabled_enter_syscalls);
tr->sys_refcount_enter++;
@@ -404,7 +412,7 @@ static void unreg_event_syscall_enter(struct
ftrace_event_file *file,
tr->sys_refcount_enter--;
clear_bit(num, tr->enabled_enter_syscalls);
if (!tr->sys_refcount_enter)
- unregister_trace_sys_enter(ftrace_syscall_enter, tr);
+ unregister_trace_sys_enter(ftrace_syscall_enter, file);
mutex_unlock(&syscall_trace_lock);
}
@@ -420,7 +428,7 @@ static int reg_event_syscall_exit(struct ftrace_event_file
*file,
return -ENOSYS;
mutex_lock(&syscall_trace_lock);
if (!tr->sys_refcount_exit)
- ret = register_trace_sys_exit(ftrace_syscall_exit, tr);
+ ret = register_trace_sys_exit(ftrace_syscall_exit, file);
if (!ret) {
set_bit(num, tr->enabled_exit_syscalls);
tr->sys_refcount_exit++;
@@ -442,7 +450,7 @@ static void unreg_event_syscall_exit(struct
ftrace_event_file *file,
tr->sys_refcount_exit--;
clear_bit(num, tr->enabled_exit_syscalls);
if (!tr->sys_refcount_exit)
- unregister_trace_sys_exit(ftrace_syscall_exit, tr);
+ unregister_trace_sys_exit(ftrace_syscall_exit, file);
mutex_unlock(&syscall_trace_lock);
}
--
1.7.11.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 v2 08/11] tracing: add 'stacktrace' event trigger command
Add 'stacktrace' ftrace_func_command. stacktrace event triggers are
added by the user via this command in a similar way and using
practically the same syntax as the analogous 'stacktrace' ftrace
function command, but instead of writing to the set_ftrace_filter
file, the stacktrace event trigger is written to the per-event
'trigger' files:
echo 'stacktrace' > .../tracing/events/somesys/someevent/trigger
The above command will turn on stacktraces for someevent i.e. whenever
someevent is hit, a stacktrace will be logged.
This also adds a 'count' version that limits the number of times the
command will be invoked:
echo 'stacktrace:N' > .../tracing/events/somesys/someevent/trigger
Where N is the number of times the command will be invoked.
The above command will log N stacktraces for someevent i.e. whenever
someevent is hit N times, a stacktrace will be logged.
Signed-off-by: Tom Zanussi
---
include/linux/ftrace_event.h| 1 +
kernel/trace/trace_events_trigger.c | 89 +
2 files changed, 90 insertions(+)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index a25daf3..51c141e 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -318,6 +318,7 @@ enum trigger_mode {
TM_NONE = (0),
TM_TRACE_ONOFF = (1 << 0),
TM_SNAPSHOT = (1 << 1),
+ TM_STACKTRACE = (1 << 2),
};
extern void destroy_preds(struct ftrace_event_call *call);
diff --git a/kernel/trace/trace_events_trigger.c
b/kernel/trace/trace_events_trigger.c
index 90a59dc..dd14e36 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -715,6 +715,84 @@ static struct event_command trigger_snapshot_cmd = {
.get_trigger_ops= snapshot_get_trigger_ops,
};
+/*
+ * Skip 4:
+ * ftrace_stacktrace()
+ * function_trace_probe_call()
+ * ftrace_ops_list_func()
+ * ftrace_call()
+ */
+#define STACK_SKIP 4
+
+static void
+stacktrace_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ trace_dump_stack(STACK_SKIP);
+}
+
+static void
+stacktrace_count_trigger(void **_data)
+{
+ struct event_trigger_data **p = (struct event_trigger_data **)_data;
+ struct event_trigger_data *data = *p;
+
+ if (!data)
+ return;
+
+ if (!data->count)
+ return;
+
+ if (data->count != -1)
+ (data->count)--;
+
+ stacktrace_trigger(_data);
+}
+
+static int
+stacktrace_trigger_print(struct seq_file *m, struct event_trigger_ops *ops,
+void *_data)
+{
+ struct event_trigger_data *data = _data;
+
+ return event_trigger_print("stacktrace", m, (void *)data->count,
+ data->filter_str);
+}
+
+static struct event_trigger_ops stacktrace_trigger_ops = {
+ .func = stacktrace_trigger,
+ .print = stacktrace_trigger_print,
+ .init = event_trigger_init,
+ .free = event_trigger_free,
+};
+
+static struct event_trigger_ops stacktrace_count_trigger_ops = {
+ .func = stacktrace_count_trigger,
+ .print = stacktrace_trigger_print,
+ .init = event_trigger_init,
+ .free = event_trigger_free,
+};
+
+static struct event_trigger_ops *
+stacktrace_get_trigger_ops(char *cmd, char *param)
+{
+ return param ? &stacktrace_count_trigger_ops : &stacktrace_trigger_ops;
+}
+
+static struct event_command trigger_stacktrace_cmd = {
+ .name = "stacktrace",
+ .trigger_mode = TM_STACKTRACE,
+ .func = event_trigger_callback,
+ .reg= register_trigger,
+ .unreg = unregister_trigger,
+ .get_trigger_ops= stacktrace_get_trigger_ops,
+};
+
static __init void unregister_trigger_traceon_traceoff_cmds(void)
{
unregister_event_command(&trigger_traceon_cmd,
@@ -759,5 +837,16 @@ __init int register_trigger_cmds(void)
return ret;
}
+ ret = register_event_command(&trigger_stacktrace_cmd,
+ &trigger_commands,
+ &trigger_cmd_mutex);
+ if (WARN_ON(ret < 0)) {
+ unregister_trigger_traceon_traceoff_cmds();
+ unregister_event_command(&trigger_snapshot_cmd,
+&trigger_commands,
+&trigger_cmd_mutex);
+ return ret;
+ }
+
return 0;
}
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...
[PATCH v2 10/11] tracing: add and use generic set_trigger_filter() implementation
Add a generic event_command.set_trigger_filter() op implementation and
have the current set of trigger commands use it - this essentially
gives them all support for filters.
Syntactically, filters are supported by adding 'if ' just
after the command, in which case only events matching the filter will
invoke the trigger. For example, to add a filter to an
enable/disable_event command:
echo 'enable_event:system:event if common_pid == 999' > \
.../othersys/otherevent/trigger
The above command will only enable the system:event event if the
common_pid field in the othersys:otherevent event is 999.
As another example, to add a filter to a stacktrace command:
echo 'stacktrace if common_pid == 999' > \
.../somesys/someevent/trigger
The above command will only trigger a stacktrace if the common_pid
field in the event is 999.
The filter syntax is the same as that described in the 'Event
filtering' section of Documentation/trace/events.txt.
Because triggers can now use filters, the trigger-invoking logic needs
to be moved - for ftrace_raw_event_calls, trigger invocation now needs
to happen after the { assign; } part of the call.
Also, because triggers need to be invoked even for soft-disabled
events, the SOFT_DISABLED check and return needs to be moved from the
top of the call to a point following the trigger check, which means
that soft-disabled events actually get discarded instead of simply
skipped. There's still a SOFT_DISABLED-only check at the top of the
function, so when an event is soft disabled but not because of the
presence of a trigger, the original SOFT_DISABLED behavior remains
unchanged.
There's also a bit of trickiness in that some triggers need to avoid
being invoked while an event is currently in the process of being
logged, since the trigger may itself log data into the trace buffer.
Thus we make sure the current event is committed before invoking those
triggers. To do that, we split the trigger invocation in two - the
first part (event_triggers_call()) checks the filter using the current
trace record; if a command has the post_trigger flag set, it sets a
bit for itself in the return value, otherwise it directly invoks the
trigger. Once all commands have been either invoked or set their
return flag, event_triggers_call() returns. The current record is
then either committed or discarded; if any commands have deferred
their triggers, those commands are finally invoked following the close
of the current event by event_triggers_post_call().
The syscall event invocation code is also changed in analogous ways.
Because event triggers need to be able to create and free filters,
this also adds a couple external wrappers for the existing
create_filter and free_filter functions, which are too generic to be
made extern functions themselves.
Signed-off-by: Tom Zanussi
---
include/linux/ftrace_event.h| 6 ++-
include/trace/ftrace.h | 45 -
kernel/trace/trace.h| 4 ++
kernel/trace/trace_events_filter.c | 13 +
kernel/trace/trace_events_trigger.c | 97 +++--
kernel/trace/trace_syscalls.c | 40 ++-
6 files changed, 176 insertions(+), 29 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 57ca386..f0c6e80 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -328,7 +328,11 @@ extern int filter_current_check_discard(struct ring_buffer
*buffer,
struct ftrace_event_call *call,
void *rec,
struct ring_buffer_event *event);
-extern void event_triggers_call(struct ftrace_event_file *file);
+extern enum trigger_mode event_triggers_call(struct ftrace_event_file *file,
+void *rec);
+extern void event_triggers_post_call(struct ftrace_event_file *file,
+enum trigger_mode tm);
+
enum {
FILTER_OTHER = 0,
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 88ac7da..7a78137 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -408,13 +408,15 @@ static inline notrace int ftrace_get_offsets_##call(
\
* struct ftrace_data_offsets_ __maybe_unused __data_offsets;
* struct ring_buffer_event *event;
* struct ftrace_raw_ *entry; <-- defined in stage 1
+ * enum trigger_mode __tm = TM_NONE;
* struct ring_buffer *buffer;
* unsigned long irq_flags;
* int __data_size;
* int pc;
*
- * if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT,
- * &ftrace_file->flags))
+ * if ((ftrace_file->flags & (FTRACE_EVENT_FL_SOFT_DISABLED |
+ * FTRACE_EVENT_FL_TRIGGER_MODE)) ==
+ * FTRACE_EVENT_FL_SOFT_DISABLED)
* return;
*
* local_save_flags(irq_flags);
@@ -433,9
[PATCH v2 00/11] tracing: trace event triggers
Hi, This is v2 of the trace event triggers patchset, addressing comments from Masami Hiramatsu, zhangwei(Jovi), and Steve Rostedt (thanks for reviewing v1). v2: - removed all changes to __ftrace_event_enable_disable() (except for patch 04/11 which clears the soft_disabled bit as discussed) and created a separate trace_event_trigger_enable_disable() that calls it after setting/clearing the TRIGGER_MODE_BIT. - added a trigger_mode enum for future patches that break up the trigger calls for filtering, but that's also now used as a command id for registering/unregistering commands. - removed the enter_file/exit_file members that were added to syscall_metadata after realizing that they were unnecessary if ftrace_syscall_enter/exit() were modified to receive a pointer to the ftrace_file instead of the pointer to the trace_array in the ftrace_file. - broke up the trigger invocation into two parts so that triggers like 'stacktrace' that themselves log into the trace buffer can defer the actual trigger invocation until after the current record is closed, which is needed for the filter check that in turn determines whether the trigger gets invoked. - other minor cleanup This patchset implements 'trace event triggers', which are similar to the function triggers implemented for 'ftrace filter commands' (see 'Filter commands' in Documentation/trace/ftrace.txt), but instead of being invoked from function calls are invoked by trace events. Basically the patchset allows 'commands' to be triggered whenever a given trace event is hit. The set of commands implemented by this patchset are: - enable/disable_event - enable or disable another event whenever the trigger event is hit - stacktrace - dump a stacktrace to the trace buffer whenever the trigger event is hit - snapshot - create a snapshot of the current trace buffer whenever the trigger event is hit - traceon/traceoff - turn tracing on or off whenever the trigger event is hit Triggers can also be conditionally invoked by associating a standard trace event filter with them - if the given event passes the filter, the trigger is invoked, otherwise it's not. (see 'Event filtering' in Documentation/trace/events.txt for info on event filters). See the last patch in the series for more complete documention on event triggers and the available trigger commands, and below for some simple examples of each of the above commands along with conditional filtering. The first four patches are bugfix patches or minor improvements which can be applied regardless; the rest contain the basic framework and implementations for each command. This patchset was based on some ideas from Steve Rostedt, which he outlined during a couple discussions at ELC and follow-on e-mails. Code- and interface-wise, it's also partially based on the existing function triggers implementation and essentially works on top of the SOFT_DISABLE mode introduced for that. Both Steve and Masami Hiramatsu took a look at a couple early versions of this patchset, and offered some very useful suggestions reflected in this patchset - thanks to them both for the ideas and for taking the time to do some basic sanity reviews! Below are a few concrete examples demonstrating each of the available commands. The first example attempts to capture all the kmalloc events that happen as a result of reading a particular file. The first part of the set of commands below adds a kmalloc 'enable_event' trigger to the sys_enter_read trace event - as a result, when the sys_enter_read event occurs, kmalloc events are enabled, resulting in those kmalloc events getting logged into the trace buffer. The :1 at the end of the kmalloc enable_event specifies that the enabling of kmalloc events on sys_enter_read will only happen once - subsequent reads won't trigger the kmalloc logging. The next part of the example reads a test file, which triggers the sys_enter_read tracepoint and thus turns on the kmalloc events, and once done, adds a trigger to sys_exit_read that disables kmalloc events. The disable_event doesn't have a :1 appended, which means it happens on every sys_exit_read. # echo 'enable_event:kmem:kmalloc:1' > \ /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger; \ cat ~/junk.txt > /dev/null; \ echo 'disable_event:kmem:kmalloc' > \ /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger Just to show a bit of what happens under the covers, if we display the kmalloc 'enable' file, we see that it's 'soft disabled' (the asterisk after the enable flag). This means that it's actually enabled but is in the SOFT_DISABLED state, and is essentially held back from actually logging anything to the trace buffer, but can be made to log into the buffer by simply flipping a bit : # cat /sys/kernel/debug/tracing/events/kmem/kmalloc/enable 0* If we look at the 'enable' file for the triggering sys_enter_read trace event, we can see that it also has
Re: [PATCH 1/2 net-next] usbnet: ax88179_178a: Correct a typo in description
From: David Chang Date: Thu, 27 Jun 2013 17:16:42 +0800 > > Correct a typo in description of driver_info, it should be Gigabit > > Signed-off-by: David Chang Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2 net-next] usbnet: ax88179_178a: add .reset_resume hook
From: David Chang Date: Thu, 27 Jun 2013 17:16:43 +0800 > I tested with the AX88179 usb dongle, if without .reset_resume hook, > after S3/S4 resume you have to enable network interface or reload the > dirver module manually otherwise the network interface can not work. > > Signed-off-by: David Chang Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: max77693: Skip register regulator if no platform initialization data
The code in max77693_pmic_dt_parse_rdata() does skip setting rdata if
!rmatch[i].init_data. So we may have some empty entries in rdata[].
We need to skip register regulator if no platform initialization data,
otherwise we may resiter regulator with invalid settings ( the empty entries
of rdata[]).
Signed-off-by: Axel Lin
---
drivers/regulator/max77693.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/regulator/max77693.c b/drivers/regulator/max77693.c
index d45a4dd..6116a49 100644
--- a/drivers/regulator/max77693.c
+++ b/drivers/regulator/max77693.c
@@ -265,6 +265,9 @@ static int max77693_pmic_probe(struct platform_device *pdev)
for (i = 0; i < max77693_pmic->num_regulators; i++) {
int id = rdata[i].id;
+ if (!rdata[i].initdata)
+ continue;
+
config.init_data = rdata[i].initdata;
config.of_node = rdata[i].of_node;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent softlockups with 3.10rc6.
On Fri, Jun 28, 2013 at 12:28:19PM +0200, Jan Kara wrote:
> On Fri 28-06-13 13:58:25, Dave Chinner wrote:
> > writeback: store inodes under writeback on a separate list
> >
> > From: Dave Chinner
> >
> > When there are lots of cached inodes, a sync(2) operation walks all
> > of them to try to find which ones are under writeback and wait for
> > IO completion on them. Run enough load, and this caused catastrophic
> > lock contention on the inode_sb_list_lock.
> >
> > Try to fix this problem by tracking inodes under data IO and wait
> > specifically for only those inodes that haven't completed their data
> > IO in wait_sb_inodes().
> >
> > This is a bit hacky and messy, but demonstrates one method of
> > solving this problem
> >
> > XXX: This will catch data IO - do we need to catch actual inode
> > writeback (i.e. the metadata) here? I'm pretty sure we don't need to
> > because the existing code just calls filemap_fdatawait() and that
> > doesn't wait for the inode metadata writeback to occur
> >
> > [v3 - avoid deadlock due to interrupt while holding inode->i_lock]
> >
> > [v2 - needs spin_lock_irq variants in wait_sb_inodes.
> > - move freeing inodes back to primary list, we don't wait for
> > them
> > - take mapping lock in wait_sb_inodes when requeuing.]
> >
> > Signed-off-by: Dave Chinner
> > ---
> > fs/fs-writeback.c | 70
> > +--
> > fs/inode.c |1 +
> > include/linux/backing-dev.h |3 ++
> > include/linux/fs.h |3 +-
> > mm/backing-dev.c|2 ++
> > mm/page-writeback.c | 22 ++
> > 6 files changed, 91 insertions(+), 10 deletions(-)
> >
> > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> > index 3be5718..589c40b 100644
> > --- a/fs/fs-writeback.c
> > +++ b/fs/fs-writeback.c
> > @@ -1208,7 +1208,10 @@ EXPORT_SYMBOL(__mark_inode_dirty);
> >
> > static void wait_sb_inodes(struct super_block *sb)
> > {
> > - struct inode *inode, *old_inode = NULL;
> > + struct backing_dev_info *bdi = sb->s_bdi;
> > + struct inode *old_inode = NULL;
> > + unsigned long flags;
> > + LIST_HEAD(sync_list);
> >
> > /*
> > * We need to be protected against the filesystem going from
> > @@ -1216,7 +1219,6 @@ static void wait_sb_inodes(struct super_block *sb)
> > */
> > WARN_ON(!rwsem_is_locked(&sb->s_umount));
> >
> > - spin_lock(&inode_sb_list_lock);
> >
> > /*
> > * Data integrity sync. Must wait for all pages under writeback,
> > @@ -1224,19 +1226,58 @@ static void wait_sb_inodes(struct super_block *sb)
> > * call, but which had writeout started before we write it out.
> > * In which case, the inode may not be on the dirty list, but
> > * we still have to wait for that writeout.
> > +*
> > +* To avoid syncing inodes put under IO after we have started here,
> > +* splice the io list to a temporary list head and walk that. Newly
> > +* dirtied inodes will go onto the primary list so we won't wait for
> > +* them.
> > +*
> > +* Inodes that have pages under writeback after we've finished the wait
> > +* may or may not be on the primary list. They had pages under put IOi
> > +* after
> > +* we started our wait, so we need to make sure the next sync or IO
> > +* completion treats them correctly, Move them back to the primary list
> > +* and restart the walk.
> > +*
> > +* Inodes that are clean after we have waited for them don't belong
> > +* on any list, and the cleaning of them should have removed them from
> > +* the temporary list. Check this is true, and restart the walk.
> > */
> > - list_for_each_entry(inode, &sb->s_inodes, i_sb_list) {
> > + spin_lock_irqsave(&bdi->wb.wb_list_lock, flags);
> > + list_splice_init(&bdi->wb.b_wb, &sync_list);
> > +
> > + while (!list_empty(&sync_list)) {
> > + struct inode *inode = list_first_entry(&sync_list, struct inode,
> > + i_io_list);
> > struct address_space *mapping = inode->i_mapping;
> >
> > - spin_lock(&inode->i_lock);
> > - if ((inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)) ||
> > - (mapping->nrpages == 0)) {
> > + /*
> > +* we are nesting the inode->i_lock inside a IRQ disabled
> > +* section here, so there's the possibility that we could have
> > +* a lock inversion due to an interrupt while holding the
> > +* inode->i_lock elsewhere. This is the only place we take the
> > +* inode->i_lock inside the wb_list_lock, so we need to use a
> > +* trylock to avoid a deadlock. If we fail to get the lock,
> > +* the only way to make progress is to also drop the
> > +* wb_list_lock so the interrupt trying to get it can make
> > +* progress.
> > +*/
> >
[PATCH] regulator: max77693: Fix trivial typo
Fix trivial typo in the equation to check upper bound of current setting. Signed-off-by: Axel Lin --- drivers/regulator/max77693.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/max77693.c b/drivers/regulator/max77693.c index 674ece7..d45a4dd 100644 --- a/drivers/regulator/max77693.c +++ b/drivers/regulator/max77693.c @@ -97,7 +97,7 @@ static int max77693_chg_set_current_limit(struct regulator_dev *rdev, while (chg_min_uA + CHGIN_ILIM_STEP_20mA * sel < min_uA) sel++; - if (chg_min_uA * CHGIN_ILIM_STEP_20mA * sel > max_uA) + if (chg_min_uA + CHGIN_ILIM_STEP_20mA * sel > max_uA) return -EINVAL; /* the first four codes for charger current are all 60mA */ -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] palmas: Simplify regulator_desc setting for SMPS10_[OUT1|OUT2]
The regulator_desc setting for SMPS10-OUT1 and SMPS10-OUT2 are very similar,
only enable_mask is different.
Make the switch case fall through to simplify the code.
Signed-off-by: Axel Lin
---
drivers/regulator/palmas-regulator.c | 22 --
1 file changed, 4 insertions(+), 18 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 50ca8c0..de25d20 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -879,23 +879,6 @@ static int palmas_regulators_probe(struct platform_device
*pdev)
switch (id) {
case PALMAS_REG_SMPS10_OUT1:
- pmic->desc[id].n_voltages = PALMAS_SMPS10_NUM_VOLTAGES;
- pmic->desc[id].ops = &palmas_ops_smps10;
- pmic->desc[id].vsel_reg =
- PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE,
- PALMAS_SMPS10_CTRL);
- pmic->desc[id].vsel_mask = SMPS10_VSEL;
- pmic->desc[id].enable_reg =
- PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE,
- PALMAS_SMPS10_CTRL);
- pmic->desc[id].enable_mask = SMPS10_SWITCH_EN;
- pmic->desc[id].bypass_reg =
- PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE,
- PALMAS_SMPS10_CTRL);
- pmic->desc[id].bypass_mask = SMPS10_BYPASS_EN;
- pmic->desc[id].min_uV = 375;
- pmic->desc[id].uV_step = 125;
- break;
case PALMAS_REG_SMPS10_OUT2:
pmic->desc[id].n_voltages = PALMAS_SMPS10_NUM_VOLTAGES;
pmic->desc[id].ops = &palmas_ops_smps10;
@@ -906,7 +889,10 @@ static int palmas_regulators_probe(struct platform_device
*pdev)
pmic->desc[id].enable_reg =
PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE,
PALMAS_SMPS10_CTRL);
- pmic->desc[id].enable_mask = SMPS10_BOOST_EN;
+ if (id == PALMAS_REG_SMPS10_OUT1)
+ pmic->desc[id].enable_mask = SMPS10_SWITCH_EN;
+ else
+ pmic->desc[id].enable_mask = SMPS10_BOOST_EN;
pmic->desc[id].bypass_reg =
PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE,
PALMAS_SMPS10_CTRL);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] udp: make use of static_key_slow_set_true() interface
On Fri, 2013-06-28 at 22:30 +, jba...@akamai.com wrote:
> Make use of the simpler API.
Need to make the change log much more descriptive. Never assume someone
in the future that looks up a change to this file will know about other
commits that led to this. Each change log should be sufficient to stand
on its own.
Explain why this patch is needed. And it's not about the use of a
simpler API.
It actually fixes a real bug.
>
> Signed-off-by: Jason Baron
> ---
> net/ipv4/udp.c |9 -
> net/ipv6/udp.c |9 -
> 2 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index 0bf5d39..b8d0029 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1421,11 +1421,10 @@ static int __udp_queue_rcv_skb(struct sock *sk,
> struct sk_buff *skb)
>
> }
>
> -static struct static_key udp_encap_needed __read_mostly;
> +static struct static_key_boolean udp_encap_needed __read_mostly;
> void udp_encap_enable(void)
> {
> - if (!static_key_enabled(&udp_encap_needed))
> - static_key_slow_inc(&udp_encap_needed);
> + static_key_slow_set_true(&udp_encap_needed);
> }
> EXPORT_SYMBOL(udp_encap_enable);
>
> @@ -1450,7 +1449,7 @@ int udp_queue_rcv_skb(struct sock *sk, struct sk_buff
> *skb)
> goto drop;
> nf_reset(skb);
>
> - if (static_key_false(&udp_encap_needed) && up->encap_type) {
> + if (static_key_false(&udp_encap_needed.key) && up->encap_type) {
I wonder if we should add a static_bool_key_false(), because that added
".key" is a bit confusing.
-- Steve
> int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
>
> /*
> @@ -1773,7 +1772,7 @@ void udp_destroy_sock(struct sock *sk)
> bool slow = lock_sock_fast(sk);
> udp_flush_pending_frames(sk);
> unlock_sock_fast(sk, slow);
> - if (static_key_false(&udp_encap_needed) && up->encap_type) {
> + if (static_key_false(&udp_encap_needed.key) && up->encap_type) {
> void (*encap_destroy)(struct sock *sk);
> encap_destroy = ACCESS_ONCE(up->encap_destroy);
> if (encap_destroy)
> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
> index 42923b1..94a4091 100644
> --- a/net/ipv6/udp.c
> +++ b/net/ipv6/udp.c
> @@ -573,11 +573,10 @@ static __inline__ void udpv6_err(struct sk_buff *skb,
> __udp6_lib_err(skb, opt, type, code, offset, info, &udp_table);
> }
>
> -static struct static_key udpv6_encap_needed __read_mostly;
> +static struct static_key_boolean udpv6_encap_needed __read_mostly;
> void udpv6_encap_enable(void)
> {
> - if (!static_key_enabled(&udpv6_encap_needed))
> - static_key_slow_inc(&udpv6_encap_needed);
> + static_key_slow_set_true(&udpv6_encap_needed);
> }
> EXPORT_SYMBOL(udpv6_encap_enable);
>
> @@ -590,7 +589,7 @@ int udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff
> *skb)
> if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
> goto drop;
>
> - if (static_key_false(&udpv6_encap_needed) && up->encap_type) {
> + if (static_key_false(&udpv6_encap_needed.key) && up->encap_type) {
> int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
>
> /*
> @@ -1300,7 +1299,7 @@ void udpv6_destroy_sock(struct sock *sk)
> udp_v6_flush_pending_frames(sk);
> release_sock(sk);
>
> - if (static_key_false(&udpv6_encap_needed) && up->encap_type) {
> + if (static_key_false(&udpv6_encap_needed.key) && up->encap_type) {
> void (*encap_destroy)(struct sock *sk);
> encap_destroy = ACCESS_ONCE(up->encap_destroy);
> if (encap_destroy)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] net: fec: Fix build for MCF5272
On Wed, Jun 19, 2013 at 05:00:18PM -0700, David Miller wrote:
> From: Guenter Roeck
> Date: Tue, 18 Jun 2013 10:04:59 -0700
>
> > Commits 4c09eed9 (net: fec: Enable imx6 enet checksum acceleration) and
> > baa70a5c (net: fec: enable pause frame to improve rx prefomance for 1G
> > network) introduced functionality into the FEC driver which is not
> > supported on MCF5272. The registers used to implement this functionality
> > do not exist on MCF5272. Since register defines for MCF5272 are separate
> > from register defines for other chips, building images for MCF5272 fails
> > as follows.
> >
> > fec_main.c: In function 'fec_restart':
> > fec_main.c:520:8: error: 'FEC_RACC' undeclared (first use in this function)
> > fec_main.c:585:3: error: 'FEC_R_FIFO_RSEM' undeclared (first use in this
> > function)
> > fec_main.c:586:3: error: 'FEC_R_FIFO_RSFL' undeclared (first use in this
> > function)
> > fec_main.c:587:3: error: 'FEC_R_FIFO_RAEM' undeclared (first use in this
> > function)
> > fec_main.c:588:3: error: 'FEC_R_FIFO_RAFL' undeclared (first use in this
> > function)
> > fec_main.c:591:3: error: 'FEC_OPD' undeclared (first use in this function)
> >
> > Adding the missing register defines is not an option, since the registers
> > do not exist on MCF5272. Disable the added functionality for MCF5272 builds.
> >
> > Cc: Frank Li
> > Cc: Jim Baxter
> > Signed-off-by: Guenter Roeck
>
> Applied, thanks.
>
> > This problem exists in 3.9 as well, though only due to commit baa70a5c. The
> > patch does therefore not cleanly apply to 3.9. Options I can see are to
> > ignore
> > the build error in 3.9, to back-port the patch manually, or to split it into
> > two separate patches. David, let me know which approach you prefer.
>
> You can feel free to send me a backport for v3.9-stable, thanks.
>
Here it is.
Guenter
---
From: Guenter Roeck
Date: Tue, 18 Jun 2013 10:04:59 -0700
Subject: [PATCH] net: fec: Fix build for MCF5272
Commits 4c09eed9 (net: fec: Enable imx6 enet checksum acceleration) and
baa70a5c (net: fec: enable pause frame to improve rx prefomance for 1G
network) introduced functionality into the FEC driver which is not
supported on MCF5272. The registers used to implement this functionality
do not exist on MCF5272. Since register defines for MCF5272 are separate
from register defines for other chips, building images for MCF5272 fails
as follows.
fec_main.c: In function 'fec_restart':
fec_main.c:520:8: error: 'FEC_RACC' undeclared (first use in this function)
fec_main.c:585:3: error: 'FEC_R_FIFO_RSEM' undeclared (first use in this
function)
fec_main.c:586:3: error: 'FEC_R_FIFO_RSFL' undeclared (first use in this
function)
fec_main.c:587:3: error: 'FEC_R_FIFO_RAEM' undeclared (first use in this
function)
fec_main.c:588:3: error: 'FEC_R_FIFO_RAFL' undeclared (first use in this
function)
fec_main.c:591:3: error: 'FEC_OPD' undeclared (first use in this function)
Adding the missing register defines is not an option, since the registers
do not exist on MCF5272. Disable the added functionality for MCF5272 builds.
Backport to v3.9. Upstream commit d13919301d9a34cd4d3cc5ac73b89012c48cad71.
Cc: Frank Li
Cc: Jim Baxter
Signed-off-by: Guenter Roeck
Signed-off-by: David S. Miller
---
drivers/net/ethernet/freescale/fec.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fec.c
b/drivers/net/ethernet/freescale/fec.c
index ef5b595..49af0174 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -527,6 +527,7 @@ fec_restart(struct net_device *ndev, int duplex)
#endif
}
+#if !defined(CONFIG_M5272)
/* enable pause frame*/
if ((fep->pause_flag & FEC_PAUSE_FLAG_ENABLE) ||
((fep->pause_flag & FEC_PAUSE_FLAG_AUTONEG) &&
@@ -544,6 +545,7 @@ fec_restart(struct net_device *ndev, int duplex)
} else {
rcntl &= ~FEC_ENET_FCE;
}
+#endif /* !defined(CONFIG_M5272) */
writel(rcntl, fep->hwp + FEC_R_CNTRL);
@@ -1139,7 +1141,9 @@ static int fec_enet_mii_probe(struct net_device *ndev)
/* mask with MAC supported features */
if (id_entry->driver_data & FEC_QUIRK_HAS_GBIT) {
phy_dev->supported &= PHY_GBIT_FEATURES;
+#if !defined(CONFIG_M5272)
phy_dev->supported |= SUPPORTED_Pause;
+#endif
}
else
phy_dev->supported &= PHY_BASIC_FEATURES;
@@ -1326,6 +1330,8 @@ static int fec_enet_get_ts_info(struct net_device *ndev,
}
}
+#if !defined(CONFIG_M5272)
+
static void fec_enet_get_pauseparam(struct net_device *ndev,
struct ethtool_pauseparam *pause)
{
@@ -1372,9 +1378,13 @@ static int fec_enet_set_pauseparam(struct net_device
*ndev,
return 0;
}
+#endif /* !defined(CONFIG_M5272) */
+
static const struct ethtool_ops fec_enet_ethtool_ops = {
+#if !defined(CONFIG_M5272)
.get_pauseparam = fec_enet_ge
Re: cgroup: status-quo and userland efforts
Come on, now, Lennart. You put a lot of words in my mouth. On Fri, Jun 28, 2013 at 6:48 PM, Lennart Poettering wrote: > On 28.06.2013 20:53, Tim Hockin wrote: > >> a single-agent, we should make a kick-ass implementation that is >> flexible and scalable, and full-featured enough to not require >> divergence at the lowest layer of the stack. Then build systemd on >> top of that. Let systemd offer more features and policies and >> "semantic" APIs. > > > Well, what if systemd is already kick-ass? I mean, if you have a problem > with systemd, then that's your own problem, but I really don't think why I > should bother? I didn't say it wasn't. I said that we can build a common substrate that systemd can build on *and* non-systemd systems can use *and* Google can participate in. > I for sure am not going to make the PID 1 a client of another daemon. That's > just wrong. If you have a daemon that is both conceptually the manager of > another service and the client of that other service, then that's bad design > and you will easily run into deadlocks and such. Just think about it: if you > have some external daemon for managing cgroups, and you need cgroups for > running external daemons, how are you going to start the external daemon for > managing cgroups? Sure, you can hack around this, make that daemon special, > and magic, and stuff -- or you can just not do such nonsense. There's no > reason to repeat the fuckup that cgroup became in kernelspace a second time, > but this time in userspace, with multiple manager daemons all with different > and slightly incompatible definitions what a unit to manage actualy is... I forgot about the tautology of systemd. systemd is monolithic. Therefore it can not have any external dependencies. Therefore it must absorb anything it depends on. Therefore systemd continues to grow in size and scope. Up next: systemd manages your X sessions! But that's not my point. It seems pretty easy to make this cgroup management (in "native mode") a library that can have either a thin veneer of a main() function, while also being usable by systemd. The point is to solve all of the problems ONCE. I'm trying to make the case that systemd itself should be focusing on features and policies and awesome APIs. > We want to run fewer, simpler things on our systems, we want to reuse as Fewer and simpler are not compatible, unless you are losing functionality. Systemd is fewer, but NOT simpler. > much of the code as we can. You don't achieve that by running yet another > daemon that does worse what systemd can anyway do simpler, easier and > better. Considering this is all hypothetical, I find this to be a funny debate. My hypothetical idea is better than your hypothetical idea. > The least you could grant us is to have a look at the final APIs we will > have to offer before you already imply that systemd cannot be a valid > implementation of any API people could ever agree on. Whoah, don't get defensive. I said nothing of the sort. The fact of the matter is that we do not run systemd, at least in part because of the monolithic nature. That's unlikely to change in this timescale. What I said was that it would be a shame if we had to invent our own low-level cgroup daemon just because the "upstream" daemons was too tightly coupled with systemd. I think we have a lot of experience to offer to this project, and a vested interest in seeing it done well. But if it is purely targetting systemd, we have little incentive to devote resources to it. Please note that I am strictly talking about the lowest layer of the API. Just the thing that guards cgroupfs against mere mortals. The higher layers - where abstractions exist, that are actually USEFUL to end users - are not really in scope right now. We already have our own higher level APIs. This is supposed to be collaborative, not combative. Tim -- 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/3] sched: fix static keys race in sched_feat
On Fri, 2013-06-28 at 22:30 +, jba...@akamai.com wrote: > As pointed out by Andi Kleen, thue usage of static keys can be racy in "thue" > sched_feat_disable vs. sched_feat_enable(). Currently, we first check the > value of keys->enabled, and subsequently update the branch direction. This, > can be racy and can potentially leave the keys in an inconsistent state. > > Fix the race by using static_key_slow_set_true()/false(), which does the the > check and set using the jump_label_mutex. > > Signed-off-by: Jason Baron -- Steve -- 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: [04/26] ARM: 7755/1: handle user space mapped pages in flush_kernel_dcache_page
On Thu, 2013-06-27 at 00:35 +0200, Simon Baatz wrote: > Hi Ben, Luis, > > On Wed, Jun 26, 2013 at 10:04:11AM +0100, Luis Henriques wrote: > > Ben Hutchings writes: > > > > > 3.2.48-rc1 review patch. If anyone has any objections, please let me > > > know. > > > > > > -- > > > > > > From: Simon Baatz > > > > > > commit 1bc39742aab09248169ef9d3727c9def3528b3f3 upstream. > > > > Simon suggested Greg not to queue this patch for stable kernels as it > > breaks no-MMU ARM configs. He will provide a follow-up patch that > > should go together with this one. > > Fortunately, the follow-up patch is upstream now. It is commit > 63384fd0b1509acf522a8a8fcede09087eedb7df (ARM: 7772/1: Fix missing > flush_kernel_dcache_page() for noMMU). > > Thus, please add that patch as well. If it is too late to do this, my > suggestion would be to queue both of them together for the next cycle. I'm including the noMMU fix in 3.2.48, thanks. Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/3] static_keys: Add a static_key_slow_set_true()/false() interface
On Fri, 2013-06-28 at 22:30 +, jba...@akamai.com wrote:
> As pointed out by Andi Kleen, some static key users can be racy because they
> check the value of the key->enabled, and then subsequently update the branch
> direction. A number of call sites have 'higher' level locking that avoids this
> race, but the usage in the scheduler features does not. See:
> http://lkml.indiana.edu/hypermail/linux/kernel/1304.2/01655.html
>
> Thus, introduce a new API that does the check and set under the
> 'jump_label_mutex'. This should also allow to simplify call sites a bit.
>
> Users of static keys should use either the inc/dec or the set_true/set_false
> API.
>
> Signed-off-by: Jason Baron
> ---
> Documentation/static-keys.txt |8
> include/linux/jump_label.h| 30 ++
> kernel/jump_label.c | 40
> 3 files changed, 78 insertions(+)
>
> diff --git a/Documentation/static-keys.txt b/Documentation/static-keys.txt
> index 9f5263d..4cca941 100644
> --- a/Documentation/static-keys.txt
> +++ b/Documentation/static-keys.txt
> @@ -134,6 +134,14 @@ An example usage in the kernel is the implementation of
> tracepoints:
> TP_CONDITION(cond));\
> }
>
> +Keys can also be updated with the following calls:
I would explain this a bit more. Something like:
When dealing with a simple on/off switch, where there's not a usage
counter involved with the static_key, the
static_key_slow_set_true/false() methods should be used.
> +
> + static_key_slow_set_true(struct static_key *key);
> + static_key_slow_set_false(struct static_key *key);
> +
> +Users should of the API should not mix the inc/dec with usages
> +of set_true/set_false. That is, users should choose one or the other.
Fix the above comment.
-- Steve
> +
> Tracepoints are disabled by default, and can be placed in performance
> critical
> pieces of the kernel. Thus, by using a static key, the tracepoints can have
> absolutely minimal impact when not in use.
> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> index 0976fc4..787ab73 100644
> --- a/include/linux/jump_label.h
> +++ b/include/linux/jump_label.h
> @@ -67,6 +67,11 @@ struct static_key_deferred {
> struct delayed_work work;
> };
>
> +/* for use with set_true/set_false API */
> +struct static_key_boolean {
> + struct static_key key;
> +};
> +
> # include
> # define HAVE_JUMP_LABEL
> #endif /* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */
> @@ -120,6 +125,8 @@ extern int jump_label_text_reserved(void *start, void
> *end);
> extern void static_key_slow_inc(struct static_key *key);
> extern void static_key_slow_dec(struct static_key *key);
> extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
> +extern void static_key_slow_set_true(struct static_key_boolean *key);
> +extern void static_key_slow_set_false(struct static_key_boolean *key);
> extern void jump_label_apply_nops(struct module *mod);
> extern void
> jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
> @@ -128,6 +135,10 @@ jump_label_rate_limit(struct static_key_deferred *key,
> unsigned long rl);
> { .enabled = ATOMIC_INIT(1), .entries = (void *)1 })
> #define STATIC_KEY_INIT_FALSE ((struct static_key) \
> { .enabled = ATOMIC_INIT(0), .entries = (void *)0 })
> +#define STATIC_KEY_BOOLEAN_INIT_TRUE ((struct static_key_boolean) \
> + { .key.enabled = ATOMIC_INIT(1), .key.entries = (void *)1 })
> +#define STATIC_KEY_BOOLEAN_INIT_FALSE ((struct static_key_boolean) \
> + { .key.enabled = ATOMIC_INIT(0), .key.entries = (void *)0 })
>
> #else /* !HAVE_JUMP_LABEL */
>
> @@ -137,6 +148,11 @@ struct static_key {
> atomic_t enabled;
> };
>
> +/* for use with set_true/set_false API */
> +struct static_key_boolean {
> + struct static_key key;
> +};
> +
> static __always_inline void jump_label_init(void)
> {
> }
> @@ -174,6 +190,16 @@ static inline void static_key_slow_dec_deferred(struct
> static_key_deferred *key)
> static_key_slow_dec(&key->key);
> }
>
> +static inline void static_key_slow_set_true(struct static_key_boolean *key)
> +{
> + atomic_set(&key->key.enabled, 1);
> +}
> +
> +static inline void static_key_slow_set_false(struct static_key_boolean *key)
> +{
> + atomic_set(&key->key.enabled, 0);
> +}
> +
> static inline int jump_label_text_reserved(void *start, void *end)
> {
> return 0;
> @@ -197,6 +223,10 @@ jump_label_rate_limit(struct static_key_deferred *key,
> { .enabled = ATOMIC_INIT(1) })
> #define STATIC_KEY_INIT_FALSE ((struct static_key) \
> { .enabled = ATOMIC_INIT(0) })
> +#define STATIC_KEY_BOOLEAN_INIT_TRUE ((struct static_key_boolean) \
> + { .key.enabled = ATOMIC_INIT(1) })
> +#define STATIC_KEY_BOOLEAN_INIT_FALSE ((struct static_key_boolean) \
> + { .key.enab
Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92
On Thu, Jun 27, 2013 at 04:54:11PM +0200, Michal Hocko wrote: > On Thu 27-06-13 09:24:26, Dave Chinner wrote: > > On Wed, Jun 26, 2013 at 10:15:09AM +0200, Michal Hocko wrote: > > > On Tue 25-06-13 12:27:54, Dave Chinner wrote: > > > > On Tue, Jun 18, 2013 at 03:50:25PM +0200, Michal Hocko wrote: > > > > > And again, another hang. It looks like the inode deletion never > > > > > finishes. The good thing is that I do not see any LRU related BUG_ONs > > > > > anymore. I am going to test with the other patch in the thread. > > > > > > > > > > 2476 [] __wait_on_freeing_inode+0x9e/0xc0 <<< > > > > > waiting for an inode to go away > > > > > [] find_inode_fast+0xa1/0xc0 > > > > > [] iget_locked+0x4f/0x180 > > > > > [] ext4_iget+0x33/0x9f0 > > > > > [] ext4_lookup+0xbc/0x160 > > > > > [] lookup_real+0x20/0x60 > > > > > [] lookup_open+0x175/0x1d0 > > > > > [] do_last+0x2de/0x780 <<< > > > > > holds i_mutex > > > > > [] path_openat+0xda/0x400 > > > > > [] do_filp_open+0x43/0xa0 > > > > > [] do_sys_open+0x160/0x1e0 > > > > > [] sys_open+0x1c/0x20 > > > > > [] system_call_fastpath+0x16/0x1b > > > > > [] 0x > > > > > > > > I don't think this has anything to do with LRUs. > > > > > > I am not claiming that. It might be a timing issue which never mattered > > > but it is strange I can reproduce this so easily and repeatedly with the > > > shrinkers patchset applied. > > > As I said earlier, this might be breakage in my -mm tree as well > > > (missing some patch which didn't go via Andrew or misapplied patch). The > > > situation is worsen by the state of linux-next which has some unrelated > > > issues. > > > > > > I really do not want to delay the whole patchset just because of some > > > problem on my side. Do you have any tree that I should try to test? > > > > No, I've just been testing Glauber's tree and sending patches for > > problems back to him based on it. > > > > > > I won't have seen this on XFS stress testing, because it doesn't use > > > > the VFS inode hashes for inode lookups. Given that XFS is not > > > > triggering either problem you are seeing, that makes me think > > > > > > I haven't tested with xfs. > > > > That might be worthwhile if you can easily do that - another data > > point indicating a hang or absence of a hang will help point us in > > the right direction here... > > OK, still hanging (with inode_lru_isolate-fix.patch). It is not the same > thing, though, as xfs seem to do lookup slightly differently. > 12467 [] xfs_iget+0xbe/0x190 [xfs] > [] xfs_lookup+0xe8/0x110 [xfs] > [] xfs_vn_lookup+0x49/0x90 [xfs] > [] lookup_real+0x20/0x60 > [] lookup_open+0x175/0x1d0 > [] do_last+0x2de/0x780 > [] path_openat+0xda/0x400 > [] do_filp_open+0x43/0xa0 > [] do_sys_open+0x160/0x1e0 > [] sys_open+0x1c/0x20 > [] system_call_fastpath+0x16/0x1b > [] 0x What are the full traces? This could be blocking on IO or locks here if it's a cache miss and we are reading an inode Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] Introducing Device Tree Overlays
On Fri, Jan 04, 2013 at 09:31:04PM +0200, Pantelis Antoniou wrote: > The following patchset introduces Device Tree overlays, a method > of dynamically altering the kernel's live Device Tree. > > This patchset is against mainline as of Friday Jan 4 2013. > (4956964 Merge tag 'driver-core-3.8-rc2' of \ > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core) > > Note that a separate patch for the DTC compiler has been posted and > is required to compile the DTS files according to the documentation. > The patch is "dtc: Dynamic symbols & fixup support" > > An implementation patchset for a beaglebone cape loader will follow, > but if you want to check out a working kernel for the beaglebone please > pull from: > > git://github.com/pantoniou/linux-bbxm.git branch not-capebus-v8 > > Pantelis Antoniou (6): > OF: Introduce device tree node flag helpers. > OF: export of_property_notify > OF: Export all DT proc update functions > OF: Introduce utility helper functions > OF: Introduce Device Tree resolve support. > OF: Introduce DT overlay support. > Hi Pantelis, do you have an update of this patchset ? I want to seriously start testing it. Digging through your tree on github is a bit cumbersome, and I am not sure if I got all patches. It would also be nice to get an update with all the comments addressed. Thanks, 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: [RFC][PATCH] mm: madvise: MADV_POPULATE for quick pre-faulting
On 06/28/2013 11:48 PM, Dave Hansen wrote: > On 06/27/2013 10:47 PM, Zheng Liu wrote: >>> I've been doing some testing involving large amounts of >>> page cache. It's quite painful to get hundreds of GB >>> of page cache mapped in, especially when I am trying to >>> do it in parallel threads. This is true even when the >>> page cache is already allocated and I only need to map >>> it in. The test: >>> >>> 1. take 160 16MB files >>> 2. clone 160 threads, mmap the 16MB files, and either >>> a. walk through the file touching each page >> >> Why not change MAP_POPULATE flag in mmap(2)? Now it is only for private >> mappings. But maybe we could let it support shared mapping. > > Adding that support to mmap() will certainly _help_ some folks. But, > anything that mmap()s something is taking mmap_sem for write. That > means that threaded apps doing mmap()/munmap() frequently are _not_ > scalable. > > IOW, a process needing to do a bunch of MAP_POPULATEs isn't > parallelizable, but one using this mechanism would be. I look at the code, and it seems that we will handle MAP_POPULATE flag after we release mmap_sem locking in vm_mmap_pgoff(): down_write(&mm->mmap_sem); ret = do_mmap_pgoff(file, addr, len, prot, flag, pgoff, &populate); up_write(&mm->mmap_sem); if (populate) mm_populate(ret, populate); Am I missing something? Regards, - Zheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: next-20130627 breaks i.MX6 sabre sd UART console
On 06/28, Stephen Boyd wrote:
> On 06/28/13 09:58, Stehle Vincent-B46079 wrote:
> > From: linux-next-ow...@vger.kernel.org
> > [mailto:linux-next-ow...@vger.kernel.org] On Behalf Of Stephen Boyd
> > (..)
> >> Do you have debug_ll support to get some serial logs?
> > Hi,
> >
> > Thanks for your concern on the matter. You are right, there is debug_ll
> > support for i.MX6. If I activate it for next-20130628 imx_v6_v7_defconfig,
> > that only "buys" me one additional line, though:
> >
> > Uncompressing Linux... done, booting the kernel.
>
> Oh and also add earlyprintk to the command line and enable the
> earlyprintk config. It should buy you some more lines.
>
> >
> >> Also could you try booting with maxcpus=1 on the kernel commandline?
> > Good idea; it goes much further with this one (until it crashes in
> > wm8962_probe(), which is as far as I go when I revert
> > 064706514ec3fea740c2656e03c4f01f6a551ac4).
>
> Interesting. Thanks for the test.
>
> >
> >> And it would be useful to have the output of /proc/timer_list if you have
> >> it from a working device.
> > Sure; I pasted it below.
>
> Is this an SMP capable device? What devicetree blob are you using?
>
> >
> >> I believe you have a per-cpu TWD timer and a global imx-gpt?
> > I think you are right from what I see in /proc/interrupts.
>
> Well oddly I don't see any twd in the timer list but that may be because
> you're not running more than one CPU? It would be good to get the output
> when you run SMP if it has that support.
>
I tried to recreate this probelm an an smp vexpress qemu and I
couldn't do it. This is with next-20130628. If you can get
debug_ll and earlyprinkt working it would be useful if you can
apply the attached patch and give back the logs. I'm confused how
the dummy timers are causing problems.
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 9d96a54..3795c9c 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -92,6 +92,8 @@ void tick_install_broadcast_device(struct clock_event_device
*dev)
if (!try_module_get(dev->owner))
return;
+ pr_info("%s is now the broadcast\n", dev->name);
+
clockevents_exchange_device(cur, dev);
if (cur)
cur->event_handler = clockevents_handle_noop;
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index edd45f6..24548aa 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -275,6 +275,8 @@ void tick_check_new_device(struct clock_event_device
*newdev)
struct tick_device *td;
int cpu;
+ pr_info("Checking %s\n", newdev->name);
+
cpu = smp_processor_id();
if (!cpumask_test_cpu(cpu, newdev->cpumask))
goto out_bc;
@@ -286,10 +288,14 @@ void tick_check_new_device(struct clock_event_device
*newdev)
if (!tick_check_percpu(curdev, newdev, cpu))
goto out_bc;
+ pr_info("%d: %s is per-cpu\n", cpu, newdev->name);
+
/* Preference decision */
if (!tick_check_preferred(curdev, newdev))
goto out_bc;
+ pr_info("%d: %s is preferred\n", cpu, newdev->name);
+
if (!try_module_get(newdev->owner))
return;
@@ -312,6 +318,7 @@ out_bc:
/*
* Can the new device be used as a broadcast device ?
*/
+ pr_info("%d: %s is trying broadcast\n", cpu, newdev->name);
tick_install_broadcast_device(newdev);
}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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: sleeping while atomic in dwc3_gadget_start
On 06/28/13 03:58, Felipe Balbi wrote: > Hi, > > On Thu, Jun 27, 2013 at 09:57:52AM -0700, Stephen Boyd wrote: >> On 06/26/13 23:58, Felipe Balbi wrote: >>> On Wed, Jun 26, 2013 at 02:52:56PM -0700, Stephen Boyd wrote: Hi, I'm getting the folllowing BUG message on bootup with 3.10-rc5 BUG: sleeping function called from invalid context at mm/slub.c:926 in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: swapper/0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc5-gee3e35b-09316-ge78f3b35 #643 [] (unwind_backtrace+0x0/0x120) from [] (show_stack+0x10/0x14) [] (show_stack+0x10/0x14) from [] (kmem_cache_alloc_trace+0x3c/0x210) [] (kmem_cache_alloc_trace+0x3c/0x210) from [] (request_threaded_irq+0x88/0x11c) [] (request_threaded_irq+0x88/0x11c) from [] (dwc3_gadget_start+0x198/0x200) [] (dwc3_gadget_start+0x198/0x200) from [] (udc_bind_to_driver+0x70/0xd8) [] (udc_bind_to_driver+0x70/0xd8) from [] (usb_gadget_probe_driver+0x8c/0xb8) and I suspect this problem was introduced in commit 8698e2acf (usb: dwc3: gadget: introduce and use enable/disable irq methods). Is there a fix for this problem? Can we just move the irq request outside the spinlock? >>> nice :-) >>> >>> how about this ? >> If start fails do you call stop? I believe the answer is no, so we'll >> need to free_irq() somewhere along the error path. Or we can request it >> after the spin_unlock()? > good point here's v2: Ok looks good to me. I hope that platform_get_irq() doesn't fail, otherwise we're in for a nasty surprise. Maybe we should add a check in request_irq() for that case. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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: cgroup: status-quo and userland efforts
On 28.06.2013 20:53, Tim Hockin wrote: a single-agent, we should make a kick-ass implementation that is flexible and scalable, and full-featured enough to not require divergence at the lowest layer of the stack. Then build systemd on top of that. Let systemd offer more features and policies and "semantic" APIs. Well, what if systemd is already kick-ass? I mean, if you have a problem with systemd, then that's your own problem, but I really don't think why I should bother? I for sure am not going to make the PID 1 a client of another daemon. That's just wrong. If you have a daemon that is both conceptually the manager of another service and the client of that other service, then that's bad design and you will easily run into deadlocks and such. Just think about it: if you have some external daemon for managing cgroups, and you need cgroups for running external daemons, how are you going to start the external daemon for managing cgroups? Sure, you can hack around this, make that daemon special, and magic, and stuff -- or you can just not do such nonsense. There's no reason to repeat the fuckup that cgroup became in kernelspace a second time, but this time in userspace, with multiple manager daemons all with different and slightly incompatible definitions what a unit to manage actualy is... We want to run fewer, simpler things on our systems, we want to reuse as much of the code as we can. You don't achieve that by running yet another daemon that does worse what systemd can anyway do simpler, easier and better. The least you could grant us is to have a look at the final APIs we will have to offer before you already imply that systemd cannot be a valid implementation of any API people could ever agree on. Lennart -- 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 -next] PM / AVS: SmartReflex: remove redundant dev_err call in omap_sr_probe()
On Wed, Jun 26, 2013 at 09:57:14AM +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
>
> Signed-off-by: Wei Yongjun
> ---
The patch does not apply to the battery-2.6.git tree... :-/
(In the patch I see "sr_info", but in the current driver there is just
"sr".)
> drivers/power/avs/smartreflex.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
> index db9973b..c26acfc 100644
> --- a/drivers/power/avs/smartreflex.c
> +++ b/drivers/power/avs/smartreflex.c
> @@ -871,10 +871,8 @@ static int __init omap_sr_probe(struct platform_device
> *pdev)
>
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> sr_info->base = devm_ioremap_resource(&pdev->dev, mem);
> - if (IS_ERR(sr_info->base)) {
> - dev_err(&pdev->dev, "%s: ioremap fail\n", __func__);
> + if (IS_ERR(sr_info->base))
> return PTR_ERR(sr_info->base);
> - }
>
> irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] power: charger-manager: regulator_get() never returns NULL.
On Tue, Jun 25, 2013 at 02:54:17PM +0900, Chanwoo Choi wrote: > Acked-by: Chanwoo Choi > > > This patch fixes return value checking of regulator_get() in > > charger-manager > > driver. The API, regulator_get(), returns ERR_PTR() when it fails to get > > regulator with given name, not NULL. > > > > Signed-off-by: Jonghwa Lee > > Signed-off-by: Myungjoo Ham 1/2 v2 and 2/2 applied. Thanks! Anton -- 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/4] power_supply: Add of_node_put to fix refcount
On Mon, Jun 10, 2013 at 05:26:39PM -0400, Rhyland Klein wrote:
> of_parse_phandle increments the refcount for a dt node before returning
> it. Add of_node_put where needed to properly decrement the refcount
> when we are done using a given node.
>
> Signed-off-by: Rhyland Klein
> ---
With CONFIG_OF=n I got this:
CC drivers/power/sbs-battery.o
drivers/power/sbs-battery.c: In function ‘sbs_probe’:
drivers/power/sbs-battery.c:707:20: error: ‘struct power_supply’ has no
member named ‘of_node’
make[1]: *** [drivers/power/sbs-battery.o] Error 1
I fixed this by the patch below and applied your 1-3 series.
Thanks!
Anton
commit b50df95c8f0703c95625181d2eaf53855c5ebee5
Author: Anton Vorontsov
Date: Fri Jun 28 18:17:22 2013 -0700
power_supply: Move of_node out of the #ifdef CONFIG_OF
Similar to linux/device.h, move of_node struct member out of the #ifdef
CONFIG_OF so that the drivers won't have to mess with #ifdefs in .c files.
Signed-off-by: Anton Vorontsov
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 3828cef..804b906 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -162,6 +162,8 @@ union power_supply_propval {
const char *strval;
};
+struct device_node;
+
struct power_supply {
const char *name;
enum power_supply_type type;
@@ -173,9 +175,7 @@ struct power_supply {
char **supplied_from;
size_t num_supplies;
-#ifdef CONFIG_OF
struct device_node *of_node;
-#endif
int (*get_property)(struct power_supply *psy,
enum power_supply_property psp,
--
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] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM
** The initial solution.
The easier solution is to update the bootmem APIs semantics to use
phys_addr_t which makes things works but needs to update almost
all bootmem API semantics and the changes were too intrusive. Many suggested
to use memblock.
** NO_BOOTMEM is suppose to be memblock
- Initially started with the assumption that NO_BOOTMEM can work easily on ARM.
- It does actually work on 32 bit machines nicely..
- But doesn't for LPAE for obvious reason of bootmem.h API signatures truncates
the addresses.
** So I tried to remove BOOTMEM and NO_BOOTMEM dependency for ARM (read 32 bit
arch)
- Started replacing bootmem_* usage with dirty hacked memblock based API.
This can be letter wrapped with only needed parameter export.
- Couple of ARM related patch-ups were fine but soon realized that we need
to patch generic kernel multiple places .. So decided to stop and check again
These changes are becoming too much...
So I need to hear back again from folks who has been involved in the discussion
in past. Am sending the email with changes just to explain the idea and issues
o.w patch as such is crappy.
Thanks for help
Cc: Tejun Heo
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Russell King - ARM Linux
Cc: Nicolas Pitre
---
arch/arm/kernel/devtree.c |2 +-
arch/arm/kernel/setup.c |2 +-
include/linux/bootmem.h |2 ++
init/main.c |4 ++--
mm/nobootmem.c|2 +-
mm/percpu.c |4 ++--
6 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 5af04f6..720b9f9 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -33,7 +33,7 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
{
- return alloc_bootmem_align(size, align);
+ return __alloc_memory_core_early(MAX_NUMNODES, size, align, 0,
ARCH_LOW_ADDRESS_LIMIT);
}
void __init arm_dt_memblock_reserve(void)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 385131c..57698ed 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -619,7 +619,7 @@ static void __init request_standard_resources(struct
machine_desc *mdesc)
kernel_data.end = virt_to_phys(_end - 1);
for_each_memblock(memory, region) {
- res = alloc_bootmem_low(sizeof(*res));
+ res = __alloc_memory_core_early(MAX_NUMNODES, sizeof(*res),
SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT);
res->name = "System RAM";
res->start =
__pfn_to_phys(memblock_region_memory_base_pfn(region));
res->end =
__pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
index 5f0b0e1..a916df6 100644
--- a/include/linux/bootmem.h
+++ b/include/linux/bootmem.h
@@ -142,6 +142,8 @@ extern void *__alloc_bootmem_low_node(pg_data_t *pgdat,
#define alloc_bootmem_low_pages_node(pgdat, x) \
__alloc_bootmem_low_node(pgdat, x, PAGE_SIZE, 0)
+extern void * __init __alloc_memory_core_early(int nid, u64 size, u64 align,
+ u64 goal, u64 limit);
#ifdef CONFIG_HAVE_ARCH_ALLOC_REMAP
extern void *alloc_remap(int nid, unsigned long size);
#else
diff --git a/init/main.c b/init/main.c
index 9484f4b..53c488d 100644
--- a/init/main.c
+++ b/init/main.c
@@ -344,8 +344,8 @@ static inline void smp_prepare_cpus(unsigned int maxcpus) {
}
*/
static void __init setup_command_line(char *command_line)
{
- saved_command_line = alloc_bootmem(strlen (boot_command_line)+1);
- static_command_line = alloc_bootmem(strlen (command_line)+1);
+ saved_command_line =__alloc_memory_core_early(MAX_NUMNODES, (strlen
(boot_command_line)+1), SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT);
+ static_command_line =__alloc_memory_core_early(MAX_NUMNODES, (strlen
(command_line)+1), SMP_CACHE_BYTES, 0, ARCH_LOW_ADDRESS_LIMIT);
strcpy (saved_command_line, boot_command_line);
strcpy (static_command_line, command_line);
}
diff --git a/mm/nobootmem.c b/mm/nobootmem.c
index bdd3fa2..43a2f95 100644
--- a/mm/nobootmem.c
+++ b/mm/nobootmem.c
@@ -32,7 +32,7 @@ unsigned long max_low_pfn;
unsigned long min_low_pfn;
unsigned long max_pfn;
-static void * __init __alloc_memory_core_early(int nid, u64 size, u64 align,
+void * __init __alloc_memory_core_early(int nid, u64 size, u64 align,
u64 goal, u64 limit)
{
void *ptr;
diff --git a/mm/percpu.c b/mm/percpu.c
index 8c8e08f..30cd3df 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1063,7 +1063,7 @@ struct pcpu_alloc_info * __init pcpu_alloc_alloc_info(int
nr_groups,
__alignof__(ai->groups[0].cpu_map[0]));
ai_size = base_size + nr_units * sizeof(ai->groups[0].cpu_map[0]);
- ptr = alloc_bootmem_nopanic(PFN_ALIGN(ai_size));
+
Re: [PATCH v2] vmpressure: implement strict mode
On Fri, Jun 28, 2013 at 03:44:02PM -0400, Luiz Capitulino wrote: > > Why can't you use poll() and demultiplex the events? Check if there is an > > event in the crit fd, and if there is, then just ignore all the rest. > > This may be a valid workaround for current kernels, but application > behavior will be different among kernels with a different number of > events. This is not a workaround, this is how poll works, and this is kinda expected... But not that I had this plan in mind when I was designing the current scheme... :) > Say, we events on top of critical. Then crit fd will now be > notified for cases where it didn't use to on older kernels. I'm not sure I am following here... but thinking about it more, I guess the extra read() will be needed anyway (to reset the counter). > > > However, it *is* possible to make non-strict work on strict if we make > > > strict default _and_ make reads on memory.pressure_level return > > > available events. Just do this on app initialization: > > > > > > for each event in memory.pressure_level; do > > > /* register eventfd to be notified on "event" */ > > > done > > > > This scheme registers "all" events. > > Yes, because I thought that's the user-case that matters for activity > manager :) Some activity managers use only low levels (Android), some might use only medium levels (simple load-balancing). Being able to register only "all" does not make sense to me. > > Here is more complicated case: > > > > Old kernels, pressure_level reads: > > > > low, med, crit > > > > The app just wants to listen for med level. > > > > New kernels, pressure_level reads: > > > > low, FOO, med, BAR, crit > > > > How would application decide which of FOO and BAR are ex-med levels? > > What you meant by ex-med? The scale is continuous and non-overlapping. If you add some other level, you effectively "shrinking" other levels, so the ex-med in the list above might correspond to "FOO, med" or "med, BAR" or "FOO, med, BAR", and that is exactly the problem. > Let's not over-design. I agree that allowing the API to be extended > is a good thing, but we shouldn't give complex meaning to events, > otherwise we're better with a numeric scale instead. I am not over-desiging at all. Again, you did not provide any solution for the case if we are going to add a new level. Thing is, I don't know if we are going to add more levels, but the three-levels scheme is not something scientifically proven, it is just an arbitrary thing we made up. We may end up with four, or five... or not. Thanks, Anton -- 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] Ceph fix for 3.10
Hi Linus, Please pull the following patch from git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus This is a recently spotted regression in the snapshot behavior it turns out several tests weren't being run in the nightlies so this took a while to spot. Thanks! sage Josh Durgin (1): rbd: send snapshot context with writes drivers/block/rbd.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] usb: ohci-ep93xx: tidy up ohci_hcd_ep93xx_drv_probe()
Refactor the function a bit to remove the need for the local variable.
The extern prototype of usb_disabled() is not needed.
Signed-off-by: H Hartley Sweeten
Cc: Alan Stern
Cc: Lennert Buytenhek
Cc: Greg Kroah-Hartman
---
drivers/usb/host/ohci-ep93xx.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index 28fa6b8..bdc2908 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -138,17 +138,12 @@ static struct hc_driver ohci_ep93xx_hc_driver = {
.start_port_reset = ohci_start_port_reset,
};
-extern int usb_disabled(void);
-
static int ohci_hcd_ep93xx_drv_probe(struct platform_device *pdev)
{
- int ret;
-
- ret = -ENODEV;
- if (!usb_disabled())
- ret = usb_hcd_ep93xx_probe(&ohci_ep93xx_hc_driver, pdev);
+ if (usb_disabled())
+ return -ENODEV;
- return ret;
+ return usb_hcd_ep93xx_probe(&ohci_ep93xx_hc_driver, pdev);
}
static int ohci_hcd_ep93xx_drv_remove(struct platform_device *pdev)
--
1.8.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 3/4] usb: ohci-ep93xx: use devm_clk_get()
Use devm_clk_get() to make the code a bit cleaner and simpler.
This also fixes a bug where a clk_put() is not done if usb_add_hcd()
fails.
Signed-off-by: H Hartley Sweeten
Cc: Alan Stern
Cc: Lennert Buytenhek
Cc: Greg Kroah-Hartman
---
drivers/usb/host/ohci-ep93xx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index b4f5e64..28fa6b8 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -69,9 +69,8 @@ static int usb_hcd_ep93xx_probe(const struct hc_driver
*driver,
goto err_put_hcd;
}
- usb_host_clock = clk_get(&pdev->dev, NULL);
+ usb_host_clock = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(usb_host_clock)) {
- dev_dbg(&pdev->dev, "clk_get failed\n");
retval = PTR_ERR(usb_host_clock);
goto err_put_hcd;
}
@@ -96,7 +95,6 @@ static void usb_hcd_ep93xx_remove(struct usb_hcd *hcd,
{
usb_remove_hcd(hcd);
ep93xx_stop_hc(&pdev->dev);
- clk_put(usb_host_clock);
usb_put_hcd(hcd);
}
--
1.8.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 2/4] usb: ohci-ep93xx: use platform_get_irq()
Use platform_get_irq() instead of accessing the platform_device
resources directly.
Signed-off-by: H Hartley Sweeten
Cc: Alan Stern
Cc: Lennert Buytenhek
Cc: Greg Kroah-Hartman
---
drivers/usb/host/ohci-ep93xx.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index 4e12f67..b4f5e64 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -45,12 +45,12 @@ static int usb_hcd_ep93xx_probe(const struct hc_driver
*driver,
{
struct usb_hcd *hcd;
struct resource *res;
+ int irq;
int retval;
- if (pdev->resource[1].flags != IORESOURCE_IRQ) {
- dev_dbg(&pdev->dev, "resource[1] is not IORESOURCE_IRQ\n");
- return -ENOMEM;
- }
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return irq;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
@@ -80,7 +80,7 @@ static int usb_hcd_ep93xx_probe(const struct hc_driver
*driver,
ohci_hcd_init(hcd_to_ohci(hcd));
- retval = usb_add_hcd(hcd, pdev->resource[1].start, 0);
+ retval = usb_add_hcd(hcd, irq, 0);
if (retval == 0)
return retval;
--
1.8.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 1/4] usb: ohci-ep93xx: use devm_ioremap_resource()
Use devm_ioremap_resource() to make the code a bit cleaner and
simpler.
Signed-off-by: H Hartley Sweeten
Cc: Alan Stern
Cc: Lennert Buytenhek
Cc: Greg Kroah-Hartman
---
drivers/usb/host/ohci-ep93xx.c | 35 ++-
1 file changed, 14 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index 8704e9f..4e12f67 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -43,38 +43,37 @@ static void ep93xx_stop_hc(struct device *dev)
static int usb_hcd_ep93xx_probe(const struct hc_driver *driver,
struct platform_device *pdev)
{
- int retval;
struct usb_hcd *hcd;
+ struct resource *res;
+ int retval;
if (pdev->resource[1].flags != IORESOURCE_IRQ) {
dev_dbg(&pdev->dev, "resource[1] is not IORESOURCE_IRQ\n");
return -ENOMEM;
}
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENXIO;
+
hcd = usb_create_hcd(driver, &pdev->dev, "ep93xx");
if (hcd == NULL)
return -ENOMEM;
- hcd->rsrc_start = pdev->resource[0].start;
- hcd->rsrc_len = pdev->resource[0].end - pdev->resource[0].start + 1;
- if (!request_mem_region(hcd->rsrc_start, hcd->rsrc_len, hcd_name)) {
- usb_put_hcd(hcd);
- retval = -EBUSY;
- goto err1;
- }
+ hcd->rsrc_start = res->start;
+ hcd->rsrc_len = resource_size(res);
- hcd->regs = ioremap(hcd->rsrc_start, hcd->rsrc_len);
- if (hcd->regs == NULL) {
- dev_dbg(&pdev->dev, "ioremap failed\n");
- retval = -ENOMEM;
- goto err2;
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(hcd->regs)) {
+ retval = PTR_ERR(hcd->regs);
+ goto err_put_hcd;
}
usb_host_clock = clk_get(&pdev->dev, NULL);
if (IS_ERR(usb_host_clock)) {
dev_dbg(&pdev->dev, "clk_get failed\n");
retval = PTR_ERR(usb_host_clock);
- goto err3;
+ goto err_put_hcd;
}
ep93xx_start_hc(&pdev->dev);
@@ -86,11 +85,7 @@ static int usb_hcd_ep93xx_probe(const struct hc_driver
*driver,
return retval;
ep93xx_stop_hc(&pdev->dev);
-err3:
- iounmap(hcd->regs);
-err2:
- release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
-err1:
+err_put_hcd:
usb_put_hcd(hcd);
return retval;
@@ -102,8 +97,6 @@ static void usb_hcd_ep93xx_remove(struct usb_hcd *hcd,
usb_remove_hcd(hcd);
ep93xx_stop_hc(&pdev->dev);
clk_put(usb_host_clock);
- iounmap(hcd->regs);
- release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
usb_put_hcd(hcd);
}
--
1.8.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/4] usb: ohci-ep93xx: do a bit of house cleaning
Tidy up this driver a bit. H Hartley Sweeten (4): usb: ohci-ep93xx: use devm_ioremap_resource() usb: ohci-ep93xx: use platform_get_irq() usb: ohci-ep93xx: use devm_clk_get() usb: ohci-ep93xx: tidy up ohci_hcd_ep93xx_drv_probe() drivers/usb/host/ohci-ep93xx.c | 60 -- 1 file changed, 23 insertions(+), 37 deletions(-) -- 1.8.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 1/3] perf record: support duration option to run during specified time
Joonsoo Kim [iamjoonsoo@lge.com] wrote:
| Currently, there is no method to quit at specified time later.
| We are used to using 'sleep N' as command argument if we need it,
| but explicitly supporting this feature maybe makes sense.
|
| Cc: Namhyung Kim
| Signed-off-by: Joonsoo Kim
|
| diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
| index cdf58ec..19c65b5 100644
| --- a/tools/perf/builtin-record.c
| +++ b/tools/perf/builtin-record.c
| @@ -29,6 +29,7 @@
| #include
| #include
|
| +static unsigned int duration;
| #ifndef HAVE_ON_EXIT
| #ifndef ATEXIT_MAX
| #define ATEXIT_MAX 32
| @@ -194,7 +195,7 @@ static void perf_record__sig_exit(int exit_status
__maybe_unused, void *arg)
| psignal(WTERMSIG(status), rec->progname);
| }
|
| - if (signr == -1 || signr == SIGUSR1)
| + if (signr == -1 || signr == SIGUSR1 || signr == SIGALRM)
| return;
|
| signal(signr, SIG_DFL);
| @@ -404,6 +405,7 @@ static int __cmd_record(struct perf_record *rec, int
argc, const char **argv)
| signal(SIGCHLD, sig_handler);
| signal(SIGINT, sig_handler);
| signal(SIGUSR1, sig_handler);
| + signal(SIGALRM, sig_handler);
|
| if (!output_name) {
| if (!fstat(STDOUT_FILENO, &st) && S_ISFIFO(st.st_mode))
| @@ -471,6 +473,7 @@ static int __cmd_record(struct perf_record *rec, int
argc, const char **argv)
| goto out_delete_session;
| }
|
| + alarm(duration);
| if (forks) {
| err = perf_evlist__prepare_workload(evsel_list, &opts->target,
| argv, opts->pipe_output,
| @@ -955,6 +958,7 @@ const struct option record_options[] = {
|parse_branch_stack),
| OPT_BOOLEAN('W', "weight", &record.opts.sample_weight,
| "sample by weight (on special events only)"),
| + OPT_UINTEGER(0, "duration", &duration, "run during specified seconds"),
nit: A slight ambiguity in the help text. Would you mind changing it to:
"run for specified duration (seconds)" ?
Sukadev
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf: ARM: Record the user-mode PC in the call chain.
Will Deacon [will.dea...@arm.com] wrote:
| On Thu, Jun 20, 2013 at 04:17:06AM +0100, Jed Davis wrote:
| > On Tue, Jun 18, 2013 at 02:13:19PM +0100, Will Deacon wrote:
| > > On Fri, Jun 14, 2013 at 12:21:11AM +0100, Jed Davis wrote:
| > > > With this change, we no longer lose the innermost entry in the user-mode
| > > > part of the call chain. See also the x86 port, which includes the ip.
| > > >
| > > > It's possible to partially work around this problem by post-processing
| > > > the data to use the PERF_SAMPLE_IP value, but this works only if the CPU
| > > > wasn't in the kernel when the sample was taken.
| > >
| > > Thanks. I guess we need something similar for arm64 too. Could you cook a
| > > similar patch please?
| >
| > Done (and tested, on the ARM V8 Foundation Model).
|
| Wow, I didn't expect you to test it. Thanks!
|
| > It looked as if the powerpc and sparc ports might have similar issues,
| > but I haven't checked on them yet.
|
| I can extract some hardware from the pile in the corner of my flat if you
| want a hand with testing.
Interesting. Powerpc already saves the next_ip for the first entry:
arch/powerpc/perf/callchain.c:
perf_callchain_user_64():
...
next_ip = perf_instruction_pointer(regs);
lr = regs->link;
sp = regs->gpr[1];
perf_callchain_store(entry, next_ip);
for (;;) {
Do you have a test case/output that I can run on Power ?
We actually have the opposite problem where we see duplication in
callchains like this. We considered not saving the "link register"
but that seems to break for a "leaf-node" functions.
13.65% sprintft libc-2.12.so [.] __random
|
--- __random
|
|--62.82%-- __random
| |
| |--97.31%-- rand
| | do_my_sprintf
| | main
| | generic_start_main
| | __libc_start_main
| | 0x0
| |
| --2.69%-- do_my_sprintf
| main
| generic_start_main
| __libc_start_main
| 0x0
|
--37.18%-- rand
|
|--93.30%-- rand
| do_my_sprintf
| main
| generic_start_main
| __libc_start_main
| 0x0
|
--6.70%-- do_my_sprintf
main
generic_start_main
__libc_start_main
0x0
--
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 095/105] ARM: 7762/1: kernel: fix arm_dt_init_cpu_maps() to skip non-cpu nodes
On Fri, Jun 28, 2013 at 07:51:57PM +0100, Kamal Mostafa wrote:
> 3.8.13.4 -stable review patch. If anyone has any objections, please let me
> know.
Owing to dependencies on other patches getting upstreamed but not
necessarily backported to stable, waiting for a decision on how to solve
dependencies to be made asap, please drop this patch from the queue since
it can trigger regressions.
Thanks and apologies,
Lorenzo
>
> --
>
> From: Lorenzo Pieralisi
>
> commit 1ba9bf0a9ae779c1a2b3eb64951e4161d9bad7a9 upstream.
>
> The introduction of the cpu-map topology node in the cpus node implies
> that cpus node might have children that are not cpu nodes. The DT
> parsing code needs updating otherwise it would check for cpu nodes
> properties in nodes that are not required to contain them, resulting
> in warnings that have no bearing on bindings defined in the dts source file.
>
> Signed-off-by: Lorenzo Pieralisi
> Acked-by: Nicolas Pitre
> Signed-off-by: Russell King
> Signed-off-by: Kamal Mostafa
> ---
> arch/arm/kernel/devtree.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 70f1bde..93fde23 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -92,6 +92,9 @@ void __init arm_dt_init_cpu_maps(void)
> for_each_child_of_node(cpus, cpu) {
> u32 hwid;
>
> + if (of_node_cmp(cpu->type, "cpu"))
> + continue;
> +
> pr_debug(" * %s...\n", cpu->full_name);
> /*
>* A device tree containing CPU nodes with missing "reg"
> --
> 1.8.1.2
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Q: mmc au size
Hello all, I have a question concerning the "au" size of a SD Card. I have an old Kingston 64MB SD-Card and lately I have noticed this kernel message when I use the card: mmc0: SD Status: Invalid Allocation Unit size. This is due to the following commit: commit b63b5e819d5b21ae493c17c356018ffa98d3ee1c Author: Alan Cox Date: Mon Jul 2 18:55:13 2012 +0100 mmc: core: correct invalid error checking >From the "SD Specifications, Part 1, Physical Layer Specification", * AU_SIZE This 4-bit field indicates AU Size and the value can be selected from 16 KB. AU_SIZE Value Definition --- 0h Not Defined 1h 16 KB 2h 32 KB 3h 64 KB 4h 128 KB 5h 256 KB 6h 512 KB 7h 1 MB 8h 2 MB 9h 4 MB Ah 8 MB Bh 12 MB Ch 16 MB Dh 24 MB Eh 32 MB Fh 64 MB Also in the specification is this note: Sector: is the unit that is related to the erase commands. Its size is the number of blocks that will be erased in one portion. The size of a sector is fixed for each device. The information about the sector size (in blocks) is stored in the CSD. Note that if the card specifies AU size, sector size should be ignored. And this: * SECTOR_SIZE This field is fixed to 7Fh, which indicates 64 KBytes. This value does not relate to erase operations. High Capacity and Extended Capacity cards indicate memory boundary by AU size and this field should not be used. So, if an au size of 0 is reported wouldn't the erase size be the sector size? If nothing else I think the test needs to be adjusted to not report the error for an au size of 0. Regards, Hartley -- 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/8] spi: spi-ep93xx: always handle transfer specific settings
On Friday, June 28, 2013 4:18 PM, Ryan Mallon wrote:
> On 29/06/13 04:43, H Hartley Sweeten wrote:
>> __spi_async(), which starts every SPI message transfer, initializes
>> the bits_per_word and max speed for every transfer in the message.
>> Since the conditional test in ep93xx_spi_process_transfer() will
>> always succeed just remove it and always call ep93xx_spi_chip_setup()
>> to configure the hardware for each transfer in the message.
>>
>> Remove the redundant ep93xx_spi_chp_setup() in ep93xx_spi_process_transfer()
>> which just initializes the hardware to the "default" based on the SPI
>> device.
>>
>> Signed-off-by: H Hartley Sweeten
>> Cc: Ryan Mallon
>> Cc: Mika Westerberg
>> Cc: Mark Brown
>> Cc: Grant Likely
>> ---
>
>
>> +err = ep93xx_spi_calc_divisors(espi, chip, t->speed_hz);
>> +if (err) {
>> +dev_err(&espi->pdev->dev, "failed to adjust speed\n");
>
>
> Printing out the speed it was trying to set might be useful here?
Technically I don't think this can ever happen.
The minimum and maximum possible speeds are determined during the probe.
espi->max_rate = clk_get_rate(espi->clk) / 2;
espi->min_rate = clk_get_rate(espi->clk) / (254 * 256);
Each transfer is validated to make sure the speed is greater than the
minimum.
if (t->speed_hz < espi->min_rate)
return -EINVAL;
Then the rate is clamped to the min/max rates.
rate = clamp(rate, espi->min_rate, espi->max_rate);
The calculations for the div_csr and div_cpsr values needed to produce
the desired rate should always succeed.
Patch 7/8 actually replaces that dev_err() message with a more generic
one. In reality, even the new message, and the error checking, could
probably be removed.
Regards,
Hartley
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: kernel panic in skb_copy_bits
Hi Eric, The patch not fix the issue and panic as same as early I posted: > BUG: unable to handle kernel paging request at 88006d9e8d48 > IP: [] memcpy+0xb/0x120 > PGD 1798067 PUD 1fd2067 PMD 213f067 PTE 0 > Oops: [#1] SMP > CPU 7 > Modules linked in: dm_nfs tun nfs fscache auth_rpcgss nfs_acl xen_blkback > xen_netback xen_gntdev xen_evtchn lockd sunrpc bridge stp llc bonding > be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core > ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi cxgb3 mdio > dm_round_robin dm_multipath libiscsi_tcp libiscsi scsi_transport_iscsi xenfs > xen_privcmd video sbs sbshc acpi_memhotplug acpi_ipmi ipmi_msghandler > parport_pc lp parport ixgbe dca sr_mod cdrom bnx2 radeon ttm drm_kms_helper > drm snd_seq_dummy i2c_algo_bit i2c_core snd_seq_oss snd_seq_midi_event > snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss serio_raw snd_pcm snd_timer > snd soundcore snd_page_alloc iTCO_wdt pcspkr iTCO_vendor_support pata_acpi > dcdbas i5k_amb ata_generic hwmon floppy ghes i5000_edac edac_core hed > dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_mod usb_storage lpfc > scsi_transport_fc scsi_tgt ata_piix sg shpchp mptsas mptscsih mptbase > scsi_transport_sas sd_mod crc_t10dif ext3! jbd mbcac he > > > Pid: 0, comm: swapper Tainted: GW 2.6.39-300.32.1.el5uek #1 Dell > Inc. PowerEdge 2950/0DP246 > RIP: e030:[] [] memcpy+0xb/0x120 > RSP: e02b:8801003c3d58 EFLAGS: 00010246 > RAX: 880076b9e280 RBX: 8800714d2c00 RCX: 0057 > RDX: RSI: 88006d9e8d48 RDI: 880076b9e280 > RBP: 8801003c3dc0 R08: 000bf723 R09: > R10: R11: 000a R12: 0034 > R13: 0034 R14: 02b8 R15: 05a8 > FS: 7fc1e852a6e0() GS:8801003c() knlGS: > CS: e033 DS: 002b ES: 002b CR0: 8005003b > CR2: 88006d9e8d48 CR3: 6370b000 CR4: 2660 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process swapper (pid: 0, threadinfo 880077ac, task 880077abe240) > Stack: > 8142db21 880076b9e280 8800637097f0 > 02ec 02b8 880077ac > 8800637097f0 880066c9a7c0 fdb4 024c > Call Trace: > > [] ? skb_copy_bits+0x1c1/0x2e0 > [] skb_copy+0xf3/0x120 > [] neigh_timer_handler+0x1ac/0x350 > [] ? account_idle_ticks+0xe/0x10 > [] ? neigh_alloc+0x180/0x180 > [] call_timer_fn+0x4a/0x110 > [] ? neigh_alloc+0x180/0x180 > [] run_timer_softirq+0x13a/0x220 > [] __do_softirq+0xb9/0x1d0 > [] ? handle_percpu_irq+0x48/0x70 > [] call_softirq+0x1c/0x30 > [] do_softirq+0x65/0xa0 > [] irq_exit+0xab/0xc0 > [] xen_evtchn_do_upcall+0x35/0x50 > [] xen_do_hypervisor_callback+0x1e/0x30 > > [] ? xen_hypercall_sched_op+0xa/0x20 > [] ? xen_hypercall_sched_op+0xa/0x20 > [] ? xen_safe_halt+0x10/0x20 > [] ? default_idle+0x5b/0x170 > [] ? cpu_idle+0xc6/0xf0 > [] ? xen_irq_enable_direct_reloc+0x4/0x4 > [] ? cpu_bringup_and_idle+0xe/0x10 > Code: 01 c6 43 4c 04 19 c0 4c 8b 65 f0 4c 8b 6d f8 83 e0 fc 83 c0 08 88 43 4d > 48 8b 5d e8 c9 c3 90 90 48 89 f8 89 d1 c1 e9 03 83 e2 07 48 a5 89 d1 f3 > a4 c3 20 48 83 ea 20 4c 8b 06 4c 8b 4e 08 4c > RIP [] memcpy+0xb/0x120 > RSP > CR2: 88006d9e8d48 Thanks, Joe On 06/28/13 17:37, Eric Dumazet wrote: > OK please try the following patch > > > [PATCH] neighbour: fix a race in neigh_destroy() > > There is a race in neighbour code, because neigh_destroy() uses > skb_queue_purge(&neigh->arp_queue) without holding neighbour lock, > while other parts of the code assume neighbour rwlock is what > protects arp_queue > > Convert all skb_queue_purge() calls to the __skb_queue_purge() variant > > Use __skb_queue_head_init() instead of skb_queue_head_init() > to make clear we do not use arp_queue.lock > > And hold neigh->lock in neigh_destroy() to close the race. > > Reported-by: Joe Jin > Signed-off-by: Eric Dumazet > --- > net/core/neighbour.c | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/net/core/neighbour.c b/net/core/neighbour.c > index 2569ab2..b7de821 100644 > --- a/net/core/neighbour.c > +++ b/net/core/neighbour.c > @@ -231,7 +231,7 @@ static void neigh_flush_dev(struct neigh_table *tbl, > struct net_device *dev) > we must kill timers etc. and move > it to safe state. >*/ > - skb_queue_purge(&n->arp_queue); > + __skb_queue_purge(&n->arp_queue); > n->arp_queue_len_bytes = 0; > n->output = neigh_blackhole; > if (n->nud_state & NUD_VALID) > @@
Q: mmc au size
Hello Chris, I have a question concerning the "au" size of a SD Card. I have an old Kingston 64MB SD-Card and lately I have noticed this kernel message when I use the card: mmc0: SD Status: Invalid Allocation Unit size. This is due to the following commit: commit b63b5e819d5b21ae493c17c356018ffa98d3ee1c Author: Alan Cox Date: Mon Jul 2 18:55:13 2012 +0100 mmc: core: correct invalid error checking >From the "SD Specifications, Part 1, Physical Layer Specification", * AU_SIZE This 4-bit field indicates AU Size and the value can be selected from 16 KB. AU_SIZE Value Definition --- 0h Not Defined 1h 16 KB 2h 32 KB 3h 64 KB 4h 128 KB 5h 256 KB 6h 512 KB 7h 1 MB 8h 2 MB 9h 4 MB Ah 8 MB Bh 12 MB Ch 16 MB Dh 24 MB Eh 32 MB Fh 64 MB Also in the specification is this note: Sector: is the unit that is related to the erase commands. Its size is the number of blocks that will be erased in one portion. The size of a sector is fixed for each device. The information about the sector size (in blocks) is stored in the CSD. Note that if the card specifies AU size, sector size should be ignored. And this: * SECTOR_SIZE This field is fixed to 7Fh, which indicates 64 KBytes. This value does not relate to erase operations. High Capacity and Extended Capacity cards indicate memory boundary by AU size and this field should not be used. So, if an au size of 0 is reported wouldn't the erase size be the sector size? If nothing else I think the test needs to be adjusted to not report the error for an au size of 0. Regards, Hartley -- 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] ACPI / dock: Rework the handling of notifications
On Fri, Jun 28, 2013 at 3:53 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The ACPI dock driver uses register_acpi_bus_notifier() which > installs a notifier triggered globally for all system notifications. > That first of all is inefficient, because the dock driver is only > interested in notifications associated with the devices it handles, > but it has to handle all system notifies for all devices. Moreover, > it does that even if no docking stations are present in the system > (CONFIG_ACPI_DOCK set is sufficient for that to happen). Besides, > that is inconvenient, because it requires the driver to do extra work > for each notification to find the target dock station object. > > For these reasons, rework the dock driver to install a notify > handler individually for each dock station in the system using > acpi_install_notify_handler(). This allows the dock station > object to be passed directly to the notify handler and makes it > possible to simplify the dock driver quite a bit. It also > reduces the overhead related to the handling of all system > notifies when CONFIG_ACPI_DOCK is set. original change to use register_acpi_bus_notifier, have two assumption 1. two dock_station will have same handle. 2. acpi subsystem: non root acpi device only can have one system notifier installed. Maybe you can rework acpi_install_notify_handler to fix 2. 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/
[PATCH 3/4] ARM: msm: Add SMP support for 8960
Add the cpus bindings and the Krait release sequence
to make SMP work for MSM8960
Signed-off-by: Rohit Vaswani
---
Documentation/devicetree/bindings/arm/cpus.txt | 2 +
Documentation/devicetree/bindings/arm/msm/kpss.txt | 16 ++
arch/arm/boot/dts/msm8960-cdp.dts | 22 +
arch/arm/mach-msm/platsmp.c| 57 ++
arch/arm/mach-msm/scm-boot.h | 8 +--
5 files changed, 102 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/msm/kpss.txt
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index 327aad2..1132eac 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -45,11 +45,13 @@ For the ARM architecture every CPU node must contain the
following properties:
"marvell,xsc3"
"marvell,xscale"
"qcom,scorpion"
+ "qcom,krait"
- enable-method: Specifies the method used to enable or take the secondary
cores
out of reset. This allows different reset sequence for
different types of cpus.
This should be one of:
"qcom,scss"
+"qcom,kpssv1"
Example:
diff --git a/Documentation/devicetree/bindings/arm/msm/kpss.txt
b/Documentation/devicetree/bindings/arm/msm/kpss.txt
new file mode 100644
index 000..7272340
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/kpss.txt
@@ -0,0 +1,16 @@
+* KPSS - Krait Processor Sub-system
+
+Properties
+
+- compatible : Should contain "qcom,kpss".
+
+- reg: Specifies the base address for the KPSS registers used for
+ booting up secondary cores.
+
+Example:
+
+ kpss@2088000 {
+ compatible = "qcom,kpss";
+ reg = <0x02088000 0x1000
+ 0x02098000 0x2000>;
+ };
diff --git a/arch/arm/boot/dts/msm8960-cdp.dts
b/arch/arm/boot/dts/msm8960-cdp.dts
index db2060c..8c82d5e 100644
--- a/arch/arm/boot/dts/msm8960-cdp.dts
+++ b/arch/arm/boot/dts/msm8960-cdp.dts
@@ -7,6 +7,22 @@
compatible = "qcom,msm8960-cdp", "qcom,msm8960";
interrupt-parent = <&intc>;
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "qcom,krait";
+ device_type = "cpu";
+ enable-method = "qcom,kpssv1";
+
+ cpu@0 {
+ reg = <0>;
+ };
+
+ cpu@1 {
+ reg = <1>;
+ };
+ };
+
intc: interrupt-controller@200 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
@@ -37,6 +53,12 @@
reg = <0xfd51 0x4000>;
};
+ kpss@2088000 {
+ compatible = "qcom,kpss";
+ reg = <0x02088000 0x1000
+ 0x02098000 0x2000>;
+ };
+
serial@1644 {
compatible = "qcom,msm-hsuart", "qcom,msm-uart";
reg = <0x1644 0x1000>,
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 17022e0..82eb079 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -74,6 +74,56 @@ static int scorpion_release_secondary(void)
return 0;
}
+static int msm8960_release_secondary(unsigned int cpu)
+{
+ void __iomem *reg;
+ struct device_node *dn = NULL;
+
+ if (cpu == 0 || cpu >= num_possible_cpus())
+ return -EINVAL;
+
+ dn = of_find_compatible_node(dn, NULL, "qcom,kpss");
+ if (!dn) {
+ pr_err("%s : Missing kpss node from device tree\n", __func__);
+ return -ENXIO;
+ }
+
+ reg = of_iomap(dn, cpu);
+ if (!reg)
+ return -ENOMEM;
+
+ pr_debug("Starting secondary CPU %d\n", cpu);
+
+ /* Turn on CPU Rail */
+ writel_relaxed(0xA4, reg+0x1014);
+ mb();
+ udelay(512);
+
+ /* Krait bring-up sequence */
+ writel_relaxed(0x109, reg+0x04);
+ writel_relaxed(0x101, reg+0x04);
+ mb();
+ ndelay(300);
+
+ writel_relaxed(0x121, reg+0x04);
+ mb();
+ udelay(2);
+
+ writel_relaxed(0x120, reg+0x04);
+ mb();
+ udelay(2);
+
+ writel_relaxed(0x100, reg+0x04);
+ mb();
+ udelay(100);
+
+ writel_relaxed(0x180, reg+0x04);
+ mb();
+
+ iounmap(reg);
+ return 0;
+}
+
static DEFINE_PER_CPU(int, cold_boot_done);
static void boot_cold_cpu(unsigned int cpu)
@@ -96,6 +146,11 @@ static void boot_cold_cpu(unsigned int cpu)
scorpion_release_secondary();
per_cpu(cold_boot_done, cpu) = true;
}
+ } else if (!strcmp(enable_method, "qcom,kpssv1")) {
+ if (per_cpu(cold_boot_done, cpu) == false) {
+
[PATCH 2/4] ARM: msm: Re-organize platsmp to make it extensible
This makes it easy to add SMP support for new targets
by adding cpus property and the release sequence.
We add the enable-method property for the cpus property to
specify which release sequence to use.
While at it, add the 8660 cpus bindings to make SMP work.
Signed-off-by: Rohit Vaswani
---
Documentation/devicetree/bindings/arm/cpus.txt | 6 ++
Documentation/devicetree/bindings/arm/msm/scss.txt | 15
arch/arm/boot/dts/msm8660-surf.dts | 23 +-
arch/arm/mach-msm/platsmp.c| 96 --
4 files changed, 116 insertions(+), 24 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/msm/scss.txt
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index f32494d..327aad2 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -44,6 +44,12 @@ For the ARM architecture every CPU node must contain the
following properties:
"marvell,mohawk"
"marvell,xsc3"
"marvell,xscale"
+ "qcom,scorpion"
+- enable-method: Specifies the method used to enable or take the secondary
cores
+out of reset. This allows different reset sequence for
+different types of cpus.
+This should be one of:
+"qcom,scss"
Example:
diff --git a/Documentation/devicetree/bindings/arm/msm/scss.txt
b/Documentation/devicetree/bindings/arm/msm/scss.txt
new file mode 100644
index 000..21c3e26
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/scss.txt
@@ -0,0 +1,15 @@
+* SCSS - Scorpion Sub-system
+
+Properties
+
+- compatible : Should contain "qcom,scss".
+
+- reg: Specifies the base address for the SCSS registers used for
+ booting up secondary cores.
+
+Example:
+
+ scss@902000 {
+ compatible = "qcom,scss";
+ reg = <0x00902000 0x2000>;
+ };
diff --git a/arch/arm/boot/dts/msm8660-surf.dts
b/arch/arm/boot/dts/msm8660-surf.dts
index cdc010e..203e51a 100644
--- a/arch/arm/boot/dts/msm8660-surf.dts
+++ b/arch/arm/boot/dts/msm8660-surf.dts
@@ -7,6 +7,22 @@
compatible = "qcom,msm8660-surf", "qcom,msm8660";
interrupt-parent = <&intc>;
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "qcom,scorpion";
+ device_type = "cpu";
+ enable-method = "qcom,scss";
+
+ cpu@0 {
+ reg = <0>;
+ };
+
+ cpu@1 {
+ reg = <1>;
+ };
+ };
+
intc: interrupt-controller@208 {
compatible = "qcom,msm-8660-qgic";
interrupt-controller;
@@ -37,7 +53,12 @@
#interrupt-cells = <2>;
};
- serial@19c4 {
+ scss@902000 {
+ compatible = "qcom,scss";
+ reg = <0x00902000 0x2000>;
+ };
+
+ serial@19c40 {
compatible = "qcom,msm-hsuart", "qcom,msm-uart";
reg = <0x19c4 0x1000>,
<0x19c0 0x1000>;
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 7d48759..17022e0 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -38,7 +40,7 @@ static inline int get_core_count(void)
return ((read_cpuid_id() >> 4) & 3) + 1;
}
-static void __cpuinit msm_secondary_init(unsigned int cpu)
+static void msm_secondary_init(unsigned int cpu)
{
/*
* Synchronise with the boot thread.
@@ -47,35 +49,63 @@ static void __cpuinit msm_secondary_init(unsigned int cpu)
spin_unlock(&boot_lock);
}
-static __cpuinit void prepare_cold_cpu(unsigned int cpu)
+static int scorpion_release_secondary(void)
{
- int ret;
- ret = scm_set_boot_addr(virt_to_phys(secondary_startup),
- SCM_FLAG_COLDBOOT_CPU1);
- if (ret == 0) {
- void __iomem *sc1_base_ptr;
- sc1_base_ptr = ioremap_nocache(0x00902000, SZ_4K*2);
- if (sc1_base_ptr) {
- writel(0, sc1_base_ptr + VDD_SC1_ARRAY_CLAMP_GFS_CTL);
- writel(0, sc1_base_ptr + SCSS_CPU1CORE_RESET);
- writel(3, sc1_base_ptr + SCSS_DBG_STATUS_CORE_PWRDUP);
- iounmap(sc1_base_ptr);
- }
- } else
- printk(KERN_DEBUG "Failed to set secondary core boot "
- "address\n");
+ void __iomem *sc1_base_ptr;
+ struct device_node *dn = NULL;
+
+ dn = of_find_compatible_node(dn, NULL, "qcom,scss");
+ if (!dn) {
+ pr_err("%s: Missing scss node in device tree\n", __func__);
+
[PATCH 1/4] ARM: msm: Remove pen_release usage
pen_release is no longer required as the synchronization
is now managed by generic arm code.
This is done as suggested in https://lkml.org/lkml/2013/6/4/184
Signed-off-by: Rohit Vaswani
---
arch/arm/mach-msm/headsmp.S | 41 -
arch/arm/mach-msm/hotplug.c | 31 ---
arch/arm/mach-msm/platsmp.c | 35 +++
3 files changed, 7 insertions(+), 100 deletions(-)
delete mode 100644 arch/arm/mach-msm/headsmp.S
diff --git a/arch/arm/mach-msm/headsmp.S b/arch/arm/mach-msm/headsmp.S
deleted file mode 100644
index bcd5af2..000
--- a/arch/arm/mach-msm/headsmp.S
+++ /dev/null
@@ -1,41 +0,0 @@
-/*
- * linux/arch/arm/mach-realview/headsmp.S
- *
- * Copyright (c) 2003 ARM Limited
- * All Rights Reserved
- *
- * 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
-
- __CPUINIT
-
-/*
- * MSM specific entry point for secondary CPUs. This provides
- * a "holding pen" into which all secondary cores are held until we're
- * ready for them to initialise.
- */
-ENTRY(msm_secondary_startup)
- mrc p15, 0, r0, c0, c0, 5
- and r0, r0, #15
- adr r4, 1f
- ldmia r4, {r5, r6}
- sub r4, r4, r5
- add r6, r6, r4
-pen: ldr r7, [r6]
- cmp r7, r0
- bne pen
-
- /*
-* we've been released from the holding pen: secondary_stack
-* should now contain the SVC stack for this core
-*/
- b secondary_startup
-ENDPROC(msm_secondary_startup)
-
- .align
-1: .long .
- .long pen_release
diff --git a/arch/arm/mach-msm/hotplug.c b/arch/arm/mach-msm/hotplug.c
index 326a872..cea80fc 100644
--- a/arch/arm/mach-msm/hotplug.c
+++ b/arch/arm/mach-msm/hotplug.c
@@ -24,33 +24,10 @@ static inline void cpu_leave_lowpower(void)
static inline void platform_do_lowpower(unsigned int cpu)
{
- /* Just enter wfi for now. TODO: Properly shut off the cpu. */
- for (;;) {
- /*
-* here's the WFI
-*/
- asm("wfi"
- :
- :
- : "memory", "cc");
-
- if (pen_release == cpu_logical_map(cpu)) {
- /*
-* OK, proper wakeup, we're done
-*/
- break;
- }
-
- /*
-* getting here, means that we have come out of WFI without
-* having been woken up - this shouldn't happen
-*
-* The trouble is, letting people know about this is not really
-* possible, since we are currently running incoherently, and
-* therefore cannot safely call printk() or anything else
-*/
- pr_debug("CPU%u: spurious wakeup call\n", cpu);
- }
+ asm("wfi"
+ :
+ :
+ : "memory", "cc");
}
/*
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 00cdb0a..7d48759 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -28,7 +28,7 @@
#define SCSS_CPU1CORE_RESET 0xD80
#define SCSS_DBG_STATUS_CORE_PWRDUP 0xE64
-extern void msm_secondary_startup(void);
+extern void secondary_startup(void);
static DEFINE_SPINLOCK(boot_lock);
@@ -41,13 +41,6 @@ static inline int get_core_count(void)
static void __cpuinit msm_secondary_init(unsigned int cpu)
{
/*
-* let the primary processor know we're out of the
-* pen, then head off into the C entry point
-*/
- pen_release = -1;
- smp_wmb();
-
- /*
* Synchronise with the boot thread.
*/
spin_lock(&boot_lock);
@@ -57,7 +50,7 @@ static void __cpuinit msm_secondary_init(unsigned int cpu)
static __cpuinit void prepare_cold_cpu(unsigned int cpu)
{
int ret;
- ret = scm_set_boot_addr(virt_to_phys(msm_secondary_startup),
+ ret = scm_set_boot_addr(virt_to_phys(secondary_startup),
SCM_FLAG_COLDBOOT_CPU1);
if (ret == 0) {
void __iomem *sc1_base_ptr;
@@ -75,7 +68,6 @@ static __cpuinit void prepare_cold_cpu(unsigned int cpu)
static int __cpuinit msm_boot_secondary(unsigned int cpu, struct task_struct
*idle)
{
- unsigned long timeout;
static int cold_boot_done;
/* Only need to bring cpu out of reset this way once */
@@ -91,40 +83,19 @@ static int __cpuinit msm_boot_secondary(unsigned int cpu,
struct task_struct *id
spin_lock(&boot_lock);
/*
-* The secondary processor is waiting to be released from
-* the holding pen - release it, then wait for it to flag
-* that it has been released by resetting pen_release.
[PATCH 0/4] Add SMP support for MSM8660, MSM8960 and MSM8974
This series re-organizes the platsmp.c and adds SMP support for MSM8660, MSM8960 and MSM8974. We convert to using the cpus property in device tree and add a "enable-method" property for arm32. This helps select the appropriate release sequence for the secondary cores based on the cpu. Rohit Vaswani (4): ARM: msm: Remove pen_release usage ARM: msm: Re-organize platsmp to make it extensible ARM: msm: Add SMP support for 8960 ARM: msm: Add support for 8974 SMP Documentation/devicetree/bindings/arm/cpus.txt | 9 + Documentation/devicetree/bindings/arm/msm/kpss.txt | 16 ++ Documentation/devicetree/bindings/arm/msm/scss.txt | 15 ++ arch/arm/boot/dts/msm8660-surf.dts | 23 +- arch/arm/boot/dts/msm8960-cdp.dts | 22 ++ arch/arm/boot/dts/msm8974.dts | 23 ++ arch/arm/mach-msm/board-dt-8974.c | 3 + arch/arm/mach-msm/headsmp.S| 41 arch/arm/mach-msm/hotplug.c| 31 +-- arch/arm/mach-msm/platsmp.c| 265 - arch/arm/mach-msm/scm-boot.h | 8 +- 11 files changed, 330 insertions(+), 126 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/msm/kpss.txt create mode 100644 Documentation/devicetree/bindings/arm/msm/scss.txt delete mode 100644 arch/arm/mach-msm/headsmp.S -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] ARM: msm: Add support for 8974 SMP
Add the cpus bindings and the Kraitv2 release sequence
to make SMP work for 2 cores on MSM8974.
Signed-off-by: Rohit Vaswani
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/boot/dts/msm8974.dts | 23
arch/arm/mach-msm/board-dt-8974.c | 3 +
arch/arm/mach-msm/platsmp.c| 79 ++
4 files changed, 106 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index 1132eac..7c3c677 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -52,6 +52,7 @@ For the ARM architecture every CPU node must contain the
following properties:
This should be one of:
"qcom,scss"
"qcom,kpssv1"
+"qcom,kpssv2"
Example:
diff --git a/arch/arm/boot/dts/msm8974.dts b/arch/arm/boot/dts/msm8974.dts
index c31c097..ef35a9b 100644
--- a/arch/arm/boot/dts/msm8974.dts
+++ b/arch/arm/boot/dts/msm8974.dts
@@ -7,6 +7,22 @@
compatible = "qcom,msm8974";
interrupt-parent = <&intc>;
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "qcom,krait";
+ device_type = "cpu";
+ enable-method = "qcom,kpssv2";
+
+ cpu@0 {
+ reg = <0>;
+ };
+
+ cpu@1 {
+ reg = <1>;
+ };
+ };
+
intc: interrupt-controller@f900 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
@@ -23,4 +39,11 @@
<1 1 0xf08>;
clock-frequency = <1920>;
};
+
+ kpss@f9012000 {
+ compatible = "qcom,kpss";
+ reg = <0xf9012000 0x1000>,
+ <0xf9088000 0x1000>,
+ <0xf9098000 0x1000>;
+ };
};
diff --git a/arch/arm/mach-msm/board-dt-8974.c
b/arch/arm/mach-msm/board-dt-8974.c
index d7f84f2..06119f9 100644
--- a/arch/arm/mach-msm/board-dt-8974.c
+++ b/arch/arm/mach-msm/board-dt-8974.c
@@ -13,11 +13,14 @@
#include
#include
+#include "common.h"
+
static const char * const msm8974_dt_match[] __initconst = {
"qcom,msm8974",
NULL
};
DT_MACHINE_START(MSM8974_DT, "Qualcomm MSM (Flattened Device Tree)")
+ .smp = smp_ops(msm_smp_ops),
.dt_compat = msm8974_dt_match,
MACHINE_END
diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
index 82eb079..0fdae69 100644
--- a/arch/arm/mach-msm/platsmp.c
+++ b/arch/arm/mach-msm/platsmp.c
@@ -124,6 +124,80 @@ static int msm8960_release_secondary(unsigned int cpu)
return 0;
}
+static int msm8974_release_secondary(unsigned int cpu)
+{
+ void __iomem *reg;
+ void __iomem *l2_saw_base;
+ struct device_node *dn = NULL;
+ unsigned apc_pwr_gate_ctl = 0x14;
+ unsigned reg_val;
+
+ if (cpu == 0 || cpu >= num_possible_cpus())
+ return -EINVAL;
+
+ dn = of_find_compatible_node(dn, NULL, "qcom,kpss");
+ if (!dn) {
+ pr_err("%s : Missing kpss node from device tree\n", __func__);
+ return -ENXIO;
+ }
+
+ reg = of_iomap(dn, cpu+1);
+ if (!reg)
+ return -ENOMEM;
+
+ pr_debug("Starting secondary CPU %d\n", cpu);
+
+ /* Turn on the BHS, turn off LDO Bypass and power down LDO */
+ reg_val = 0x403f0001;
+ writel_relaxed(reg_val, reg + apc_pwr_gate_ctl);
+
+ /* complete the above write before the delay */
+ mb();
+ /* wait for the bhs to settle */
+ udelay(1);
+
+ /* Turn on BHS segments */
+ reg_val |= 0x3f << 1;
+ writel_relaxed(reg_val, reg + apc_pwr_gate_ctl);
+
+ /* complete the above write before the delay */
+ mb();
+/* wait for the bhs to settle */
+ udelay(1);
+
+ /* Finally turn on the bypass so that BHS supplies power */
+ reg_val |= 0x3f << 8;
+ writel_relaxed(reg_val, reg + apc_pwr_gate_ctl);
+
+ /* enable max phases */
+ l2_saw_base = of_iomap(dn, 0);
+ if (!l2_saw_base) {
+ return -ENOMEM;
+ }
+ writel_relaxed(0x10003, l2_saw_base + 0x1c);
+ mb();
+ udelay(50);
+
+ iounmap(l2_saw_base);
+
+ writel_relaxed(0x021, reg+0x04);
+ mb();
+ udelay(2);
+
+ writel_relaxed(0x020, reg+0x04);
+ mb();
+ udelay(2);
+
+ writel_relaxed(0x000, reg+0x04);
+ mb();
+
+ writel_relaxed(0x080, reg+0x04);
+ mb();
+
+ iounmap(reg);
+ return 0;
+}
+
static DEFINE_PER_CPU(int, cold_boot_done);
static void boot_cold_cpu(unsigned int cpu)
@@ -151,6 +225,11 @@ static void boot_cold_cpu(unsigned int cpu)
msm8960_release_secondary(cpu);
pe
Re: [PATCH 4/8] spi: spi-ep93xx: remove bits_per_word() helper
On 29/06/13 04:44, H Hartley Sweeten wrote:
> This inline helper function is only used to determine the bus width
> of the current transfer (8 or 16 bit). Add a bool flag to the private
> structure and set it appropriately for each transfer.
>
> Signed-off-by: H Hartley Sweeten
> Cc: Ryan Mallon
> Cc: Mika Westerberg
> Cc: Mark Brown
> Cc: Grant Likely
> ---
> drivers/spi/spi-ep93xx.c | 16 +---
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/spi/spi-ep93xx.c b/drivers/spi/spi-ep93xx.c
> index bcfd35a..4fab3bb 100644
> --- a/drivers/spi/spi-ep93xx.c
> +++ b/drivers/spi/spi-ep93xx.c
> @@ -116,6 +116,7 @@ struct ep93xx_spi {
> unsigned long min_rate;
> unsigned long max_rate;
> boolrunning;
> + boolword_xfer;
I think this is a slightly confusing name. Maybe something like
is_16bit_xfer would be better?
> struct workqueue_struct *wq;
> struct work_struct msg_work;
> struct completion wait;
> @@ -407,17 +408,9 @@ static void ep93xx_spi_chip_setup(const struct
> ep93xx_spi *espi,
> writew(cr0, espi->regs_base + SSPCR0);
> }
>
> -static inline int bits_per_word(const struct ep93xx_spi *espi)
> -{
> - struct spi_message *msg = espi->current_msg;
> - struct spi_transfer *t = msg->state;
> -
> - return t->bits_per_word;
> -}
> -
> static void ep93xx_do_write(struct ep93xx_spi *espi, struct spi_transfer *t)
> {
> - if (bits_per_word(espi) > 8) {
> + if (espi->word_xfer) {
> u16 tx_val = 0;
>
> if (t->tx_buf)
> @@ -436,7 +429,7 @@ static void ep93xx_do_write(struct ep93xx_spi *espi,
> struct spi_transfer *t)
>
> static void ep93xx_do_read(struct ep93xx_spi *espi, struct spi_transfer *t)
> {
> - if (bits_per_word(espi) > 8) {
> + if (espi->word_xfer) {
> u16 rx_val;
>
> rx_val = readw(espi->regs_base + SSPDR);
> @@ -522,7 +515,7 @@ ep93xx_spi_dma_prepare(struct ep93xx_spi *espi, enum
> dma_transfer_direction dir)
> size_t len = t->len;
> int i, ret, nents;
>
> - if (bits_per_word(espi) > 8)
> + if (espi->word_xfer)
> buswidth = DMA_SLAVE_BUSWIDTH_2_BYTES;
> else
> buswidth = DMA_SLAVE_BUSWIDTH_1_BYTE;
> @@ -699,6 +692,7 @@ static void ep93xx_spi_process_transfer(struct ep93xx_spi
> *espi,
>
> ep93xx_spi_chip_setup(espi, chip);
>
> + espi->word_xfer = (t->bits_per_word > 8) ? true : false;
espi->word_xfer = (t->bits_per_word > 8);
This patch is fine, but not sure it is entirely worth it. The
information is already stored in t->bits_per_word and the cost
of retrieving it is pretty minimal.
~Ryan
--
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/8] spi: spi-ep93xx: always handle transfer specific settings
On 29/06/13 04:43, H Hartley Sweeten wrote:
> __spi_async(), which starts every SPI message transfer, initializes
> the bits_per_word and max speed for every transfer in the message.
> Since the conditional test in ep93xx_spi_process_transfer() will
> always succeed just remove it and always call ep93xx_spi_chip_setup()
> to configure the hardware for each transfer in the message.
>
> Remove the redundant ep93xx_spi_chp_setup() in ep93xx_spi_process_transfer()
> which just initializes the hardware to the "default" based on the SPI
> device.
>
> Signed-off-by: H Hartley Sweeten
> Cc: Ryan Mallon
> Cc: Mika Westerberg
> Cc: Mark Brown
> Cc: Grant Likely
> ---
> + err = ep93xx_spi_calc_divisors(espi, chip, t->speed_hz);
> + if (err) {
> + dev_err(&espi->pdev->dev, "failed to adjust speed\n");
Printing out the speed it was trying to set might be useful here?
~Ryan
--
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/8] spi: spi-ep93xx: use read,write instead of __raw_* variants
On 29/06/13 04:42, H Hartley Sweeten wrote:
> The memory resource used by this driver is ioremap()'d and the normal
> read,write calls can be used instead of the __raw_* variants.
>
> Remove the inline read,write helpers and just do the read,write
> directly in the callers.
>
> Signed-off-by: H Hartley Sweeten
> Cc: Ryan Mallon
> Cc: Mika Westerberg
> Cc: Mark Brown
> Cc: Grant Likely
> ---
> drivers/spi/spi-ep93xx.c | 64
> +++-
> 1 file changed, 20 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/spi/spi-ep93xx.c b/drivers/spi/spi-ep93xx.c
> index d7bac60..c633cd0 100644
> --- a/drivers/spi/spi-ep93xx.c
> +++ b/drivers/spi/spi-ep93xx.c
> @@ -158,30 +158,6 @@ struct ep93xx_spi_chip {
> /* converts bits per word to CR0.DSS value */
> #define bits_per_word_to_dss(bpw)((bpw) - 1)
>
> -static inline void
> -ep93xx_spi_write_u8(const struct ep93xx_spi *espi, u16 reg, u8 value)
> -{
> - __raw_writeb(value, espi->regs_base + reg);
> -}
> -
> -static inline u8
> -ep93xx_spi_read_u8(const struct ep93xx_spi *spi, u16 reg)
> -{
> - return __raw_readb(spi->regs_base + reg);
> -}
Is there a particular reason to drop these functions? It's basically just
bike-shedding, but they can make the code more readable at very little
cost. Even dropping the inline (which is preferred nowdays) the compiler
will still inline these, and it would also make this patch much smaller
to keep them.
~Ryan
--
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] MN10300 Fixes
Hi Linus, Could you pull these MN10300 fixes please? The first fixes a problem with passing arrays rather than pointers to get_user() where __typeof__ then wants to declare and initialise an array variable which gcc doesn't like. The second fixes a problem whereby putting mem=xxx into the kernel command line causes init=xxx to get an incorrect value. Thanks, David --- The following changes since commit 98b6ed0f2bf4abfb759206aa70690636372bdee7: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-06-26 19:24:37 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-mn10300.git tags/for-linus-20130628 for you to fetch changes up to e3f12a53042e26202993baa3ad4ff8768173653d: mn10300: Use early_param() to parse "mem=" parameter (2013-06-28 16:53:03 +0100) (from the branch description for for-linus local branch) MN10300 patches for linus MN10300 changes 2013-06-28 Akira Takeuchi (2): mn10300: Allow to pass array name to get_user() mn10300: Use early_param() to parse "mem=" parameter arch/mn10300/include/asm/uaccess.h | 2 +- arch/mn10300/kernel/setup.c| 54 +++--- 2 files changed, 22 insertions(+), 34 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 v4 5/9] memcg: use css_get/put when charging/uncharging kmem
On Fri, 14 Jun 2013 09:54:57 +0800 Li Zefan wrote:
> Use css_get/put instead of mem_cgroup_get/put.
>
> We can't do a simple replacement, because here mem_cgroup_put()
> is called during mem_cgroup_css_free(), while mem_cgroup_css_free()
> won't be called until css refcnt goes down to 0.
>
> Instead we increment css refcnt in mem_cgroup_css_offline(), and
> then check if there's still kmem charges. If not, css refcnt will
> be decremented immediately, otherwise the refcnt will be released
> after the last kmem allocation is uncahred.
>
> ...
>
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -416,6 +416,11 @@ static void memcg_kmem_clear_activated(struct mem_cgroup
> *memcg)
>
> static void memcg_kmem_mark_dead(struct mem_cgroup *memcg)
> {
> + /*
> + * We need to call css_get() first, because memcg_uncharge_kmem()
> + * will call css_put() if it sees the memcg is dead.
> + */
> + smp_wmb();
> if (test_bit(KMEM_ACCOUNTED_ACTIVE, &memcg->kmem_account_flags))
> set_bit(KMEM_ACCOUNTED_DEAD, &memcg->kmem_account_flags);
> }
That comment is rather confusing and unhelpful. "We need to call
css_get", but we clearly *don't* call css_get(). I guess we want
--- a/mm/memcontrol.c~memcg-use-css_get-put-when-charging-uncharging-kmem-fix
+++ a/mm/memcontrol.c
@@ -407,7 +407,7 @@ static void memcg_kmem_clear_activated(s
static void memcg_kmem_mark_dead(struct mem_cgroup *memcg)
{
/*
-* We need to call css_get() first, because memcg_uncharge_kmem()
+* Our caller must use css_get() first, because memcg_uncharge_kmem()
* will call css_put() if it sees the memcg is dead.
*/
smp_wmb();
_
But it's still not good.
- What is the smp_wmb() for? These barriers should always be
documented so readers can see what we're barriering against but this
one is floating around unexplained.
- What does memcg_uncharge_kmem() have to do with all this?
memcg_kmem_mark_dead() just does a set_bit() - what has that to do
with memcg_kmem_mark_dead().
So I dunno, it's all clear as mud and I hope we can do better.
> @@ -3060,8 +3065,16 @@ static void memcg_uncharge_kmem(struct mem_cgroup
> *memcg, u64 size)
> if (res_counter_uncharge(&memcg->kmem, size))
> return;
>
> + /*
> + * Releases a reference taken in kmem_cgroup_css_offline in case
> + * this last uncharge is racing with the offlining code or it is
> + * outliving the memcg existence.
> + *
> + * The memory barrier imposed by test&clear is paired with the
> + * explicit one in memcg_kmem_mark_dead().
> + */
OK, that clears things up a bit. A small bit.
This code is far too tricky :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] ACPI / dock: Notification rework and memory leak fix
Hi, More fixes/cleanups for the ACPI dock driver (and related), on top of the series I sent earlier today. [Well, that code is like the Rabbit hole in "Alice's Adventures in Wonderland".] [1/3] Rework the dock driver's handling of notifications (the changelog tells the whole story). [2/3] After [1/3] there are no more users of the ACPI bus notifier call chain, so drop it. [3/3] dock_add() leaks memory on errors (although only theoretically, because it is very unlikely to fail), so fix that. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ACPI / dock: Rework the handling of notifications
From: Rafael J. Wysocki
The ACPI dock driver uses register_acpi_bus_notifier() which
installs a notifier triggered globally for all system notifications.
That first of all is inefficient, because the dock driver is only
interested in notifications associated with the devices it handles,
but it has to handle all system notifies for all devices. Moreover,
it does that even if no docking stations are present in the system
(CONFIG_ACPI_DOCK set is sufficient for that to happen). Besides,
that is inconvenient, because it requires the driver to do extra work
for each notification to find the target dock station object.
For these reasons, rework the dock driver to install a notify
handler individually for each dock station in the system using
acpi_install_notify_handler(). This allows the dock station
object to be passed directly to the notify handler and makes it
possible to simplify the dock driver quite a bit. It also
reduces the overhead related to the handling of all system
notifies when CONFIG_ACPI_DOCK is set.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/dock.c | 69 ++--
1 file changed, 25 insertions(+), 44 deletions(-)
Index: linux-pm/drivers/acpi/dock.c
===
--- linux-pm.orig/drivers/acpi/dock.c
+++ linux-pm/drivers/acpi/dock.c
@@ -718,18 +718,17 @@ static int handle_eject_request(struct d
/**
* dock_notify - act upon an acpi dock notification
- * @handle: the dock station handle
+ * @ds: dock station
* @event: the acpi event
- * @data: our driver data struct
*
* If we are notified to dock, then check to see if the dock is
* present and then dock. Notify all drivers of the dock event,
* and then hotplug and devices that may need hotplugging.
*/
-static void dock_notify(acpi_handle handle, u32 event, void *data)
+static void dock_notify(struct dock_station *ds, u32 event)
{
- struct dock_station *ds = data;
- struct acpi_device *tmp;
+ acpi_handle handle = ds->handle;
+ struct acpi_device *ad;
int surprise_removal = 0;
/*
@@ -752,8 +751,7 @@ static void dock_notify(acpi_handle hand
switch (event) {
case ACPI_NOTIFY_BUS_CHECK:
case ACPI_NOTIFY_DEVICE_CHECK:
- if (!dock_in_progress(ds) && acpi_bus_get_device(ds->handle,
- &tmp)) {
+ if (!dock_in_progress(ds) && acpi_bus_get_device(handle, &ad)) {
begin_dock(ds);
dock(ds);
if (!dock_present(ds)) {
@@ -790,9 +788,8 @@ static void dock_notify(acpi_handle hand
}
struct dock_data {
- acpi_handle handle;
- unsigned long event;
struct dock_station *ds;
+ u32 event;
};
static void acpi_dock_deferred_cb(void *context)
@@ -800,52 +797,31 @@ static void acpi_dock_deferred_cb(void *
struct dock_data *data = context;
acpi_scan_lock_acquire();
- dock_notify(data->handle, data->event, data->ds);
+ dock_notify(data->ds, data->event);
acpi_scan_lock_release();
kfree(data);
}
-static int acpi_dock_notifier_call(struct notifier_block *this,
- unsigned long event, void *data)
+static void dock_notify_handler(acpi_handle handle, u32 event, void *data)
{
- struct dock_station *dock_station;
- acpi_handle handle = data;
+ struct dock_data *dd;
if (event != ACPI_NOTIFY_BUS_CHECK && event != ACPI_NOTIFY_DEVICE_CHECK
&& event != ACPI_NOTIFY_EJECT_REQUEST)
- return 0;
-
- acpi_scan_lock_acquire();
+ return;
- list_for_each_entry(dock_station, &dock_stations, sibling) {
- if (dock_station->handle == handle) {
- struct dock_data *dd;
- acpi_status status;
-
- dd = kmalloc(sizeof(*dd), GFP_KERNEL);
- if (!dd)
- break;
-
- dd->handle = handle;
- dd->event = event;
- dd->ds = dock_station;
- status = acpi_os_hotplug_execute(acpi_dock_deferred_cb,
-dd);
- if (ACPI_FAILURE(status))
- kfree(dd);
-
- break;
- }
+ dd = kmalloc(sizeof(*dd), GFP_KERNEL);
+ if (dd) {
+ acpi_status status;
+
+ dd->ds = data;
+ dd->event = event;
+ status = acpi_os_hotplug_execute(acpi_dock_deferred_cb, dd);
+ if (ACPI_FAILURE(status))
+ kfree(dd);
}
-
- acpi_scan_lock_release();
- return 0;
}
-static struct notifier_block dock_acpi_notifier = {
- .notifier_call = acpi_dock_notifier_call,
-};
-
/**
* find_dock_devices - find device
[PATCH 3/3] ACPI / dock: Do not leak memory on falilures to add a dock station
From: Rafael J. Wysocki
The function creating and registering dock station objects,
dock_add(), leaks memory if there's an error after it's walked
the ACPI namespace calling find_dock_devices(), because it doesn't
free the list of dependent devices it's just created in those cases.
Fix that issue by adding the missing code to free the list of
dependent devices on errors.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/dock.c | 11 +++
1 file changed, 11 insertions(+)
Index: linux-pm/drivers/acpi/dock.c
===
--- linux-pm.orig/drivers/acpi/dock.c
+++ linux-pm/drivers/acpi/dock.c
@@ -119,6 +119,16 @@ add_dock_dependent_device(struct dock_st
return 0;
}
+static void remove_dock_dependent_devices(struct dock_station *ds)
+{
+ struct dock_dependent_device *dd, *aux;
+
+ list_for_each_entry_safe(dd, aux, &ds->dependent_devices, list) {
+ list_del(&dd->list);
+ kfree(dd);
+ }
+}
+
/**
* dock_init_hotplug - Initialize a hotplug device on a docking station.
* @dd: Dock-dependent device.
@@ -1008,6 +1018,7 @@ static int __init dock_add(acpi_handle h
return 0;
err_rmgroup:
+ remove_dock_dependent_devices(dock_station);
sysfs_remove_group(&dd->dev.kobj, &dock_attribute_group);
err_unregister:
platform_device_unregister(dd);
--
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] ACPI: Drop ACPI bus notifier call chain
From: Rafael J. Wysocki
There are no users of the ACPI bus notifier call chain,
acpi_bus_notify_list, any more, so drop it.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/bus.c | 16
include/acpi/acpi_bus.h |2 --
2 files changed, 18 deletions(-)
Index: linux-pm/drivers/acpi/bus.c
===
--- linux-pm.orig/drivers/acpi/bus.c
+++ linux-pm/drivers/acpi/bus.c
@@ -499,19 +499,6 @@ static void acpi_bus_check_scope(acpi_ha
*/
}
-static BLOCKING_NOTIFIER_HEAD(acpi_bus_notify_list);
-int register_acpi_bus_notifier(struct notifier_block *nb)
-{
- return blocking_notifier_chain_register(&acpi_bus_notify_list, nb);
-}
-EXPORT_SYMBOL_GPL(register_acpi_bus_notifier);
-
-void unregister_acpi_bus_notifier(struct notifier_block *nb)
-{
- blocking_notifier_chain_unregister(&acpi_bus_notify_list, nb);
-}
-EXPORT_SYMBOL_GPL(unregister_acpi_bus_notifier);
-
/**
* acpi_bus_notify
* ---
@@ -525,9 +512,6 @@ static void acpi_bus_notify(acpi_handle
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Notification %#02x to handle %p\n",
type, handle));
- blocking_notifier_call_chain(&acpi_bus_notify_list,
- type, (void *)handle);
-
switch (type) {
case ACPI_NOTIFY_BUS_CHECK:
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ linux-pm/include/acpi/acpi_bus.h
@@ -356,8 +356,6 @@ extern int acpi_notifier_call_chain(stru
extern int register_acpi_notifier(struct notifier_block *);
extern int unregister_acpi_notifier(struct notifier_block *);
-extern int register_acpi_bus_notifier(struct notifier_block *nb);
-extern void unregister_acpi_bus_notifier(struct notifier_block *nb);
/*
* External Functions
*/
--
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] let kbuild mkdir for dir/file.o
Hi, sorry for the late feedback. Dne 4.6.2013 10:45, 张忠山 napsal(a): > when add a obj with dir to obj-y, like this > > obj-y += dir/file.o > > the $(obj)/dir not created, this patch fix this > > this bug caused by commit >f5fb976520a53f45f8bbf2e851f16b3b5558d485 Please also include the wonderful explanation including the error message that you posted separately (http://permalink.gmane.org/gmane.linux.kbuild.devel/10050). Also, please CC linux-kernel in addition to linux-kbuild. > > Signed-off-by: 张忠山 > --- > scripts/Makefile.lib |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index 51bb3de..6bae5a9 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -63,7 +63,8 @@ multi-objs := $(multi-objs-y) $(multi-objs-m) > subdir-obj-y := $(filter %/built-in.o, $(obj-y)) > > # $(obj-dirs) is a list of directories that contain object files > -obj-dirs := $(dir $(multi-objs) $(subdir-obj-y)) > +__subdir-obj-y := $(foreach o,$(obj-y),$(if $(filter-out $(o),$(notdir > $(o))),$(o))) This complicated filter returns entries from $(obj-y) that contain a slash, is that correct? If so, is it really necessary? Why not simply add whole $(obj-y) to $(obj-dirs) and be done? $(multi-objs) is also added without any filtering. > +obj-dirs := $(dir $(multi-objs) $(__subdir-obj-y)) thanks, Michal -- 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: [Workman-devel] cgroup: status-quo and userland efforts
On Fri, Jun 28, 2013 at 05:40:53PM -0500, Serge Hallyn wrote: > > The kernel can exposed a knob that would allow systemd to lock that > > down > > Gah - why would you give him that idea? :) That's one of the ideas I had from the beginning. > But yes, I'd sort of assume that was coming, eventually. But I think we'll probably settle with a mechanism to find out whether someone else is touching the hierarchy, which will be generally useful for other consumers of cgroup too. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] acpi: Eliminate misleading erst pstore console message
On Fri, Jun 28, 2013 at 1:14 PM, Lenny Szubowicz wrote: > On systems that have a valid ACPI ERST table, if the pstore.backend kernel > parameter selects a specific facility other than erst, then during boot the > following console message is displayed: > > ERST: Could not register with persistent store Applied (using revised version of part 1). Thanks -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Workman-devel] cgroup: status-quo and userland efforts
Quoting Daniel P. Berrange (berra...@redhat.com): > On Fri, Jun 28, 2013 at 02:01:55PM -0400, Vivek Goyal wrote: > > On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote: > > > On Thu 27-06-13 22:01:38, Tejun Heo wrote: > > > > Hello, Mike. > > > > > > > > On Fri, Jun 28, 2013 at 06:49:10AM +0200, Mike Galbraith wrote: > > > > > I always thought that was a very cool feature, mkdir+echo, poof done. > > > > > Now maybe that interface is suboptimal for serious usage, but it makes > > > > > the things usable via dirt simple scripts, very flexible, nice. > > > > > > > > Oh, that in itself is not bad. I mean, if you're root, it's pretty > > > > easy to play with and that part is fine. But combined with the > > > > hierarchical nature of cgroup and file permissions, it encourages > > > > people to "deligate" subdirectories to less previledged domains, > > > > > > OK, this really depends on what you expose to non-root users. I have > > > seen use cases where admin prepares top-level which is root-only but > > > it allows creating sub-groups which are under _full_ control of the > > > subdomain. This worked nicely for memcg for example because hard limit, > > > oom handling and other knobs are hierarchical so the subdomain cannot > > > overwrite what admin has said. > > > > > > > which > > > > in turn leads to normal binaries to manipulate them directly, which is > > > > where the horror begins. We end up exposing control knobs which are > > > > tightly coupled to kernel implementation details right into lay > > > > binaries and scripts directly used by end users. > > > > > > > > I think this is the first time this happened, which is probably why > > > > nobody really noticed the mess earlier. > > > > > > > > Anyways, if you're root, you can keep doing whatever you want. > > > > > > OK, so libcgroup's rules daemon will still work and place my tasks in > > > appropriate cgroups? > > > > Do you use that daemon in practice? For user session logins, I think > > systemd has plans to put user sessions in a cgroup (kind of making > > pam_cgroup redundant). > > > > Other functionality rulesengined was providing moving tasks automatically > > in a cgroup based on executable name. I think that was racy and not > > many people had liked it. > > Regardless of the changes being proposed, IMHO, the cgrulesd should > never be used. It is just outright dangerous for a daemon to be > arbitrarily re-arranging what cgroups a process is placed in without > the applications being aware of it. It can only be safely used in a > scenario where cgroups are exclusively used by the administrator, > and never used by applications for their own needs. Even then it's not safe, since if the program quickly forks or clones a few times, you can end up with some of the tasks being reclassified and some not. > > IIUC, systemd can't disable access to cgroupfs from other utilities. > > The kernel can exposed a knob that would allow systemd to lock that > down Gah - why would you give him that idea? :) But yes, I'd sort of assume that was coming, eventually. -serge -- 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] udp: make use of static_key_slow_set_true() interface
Make use of the simpler API.
Signed-off-by: Jason Baron
---
net/ipv4/udp.c |9 -
net/ipv6/udp.c |9 -
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 0bf5d39..b8d0029 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1421,11 +1421,10 @@ static int __udp_queue_rcv_skb(struct sock *sk, struct
sk_buff *skb)
}
-static struct static_key udp_encap_needed __read_mostly;
+static struct static_key_boolean udp_encap_needed __read_mostly;
void udp_encap_enable(void)
{
- if (!static_key_enabled(&udp_encap_needed))
- static_key_slow_inc(&udp_encap_needed);
+ static_key_slow_set_true(&udp_encap_needed);
}
EXPORT_SYMBOL(udp_encap_enable);
@@ -1450,7 +1449,7 @@ int udp_queue_rcv_skb(struct sock *sk, struct sk_buff
*skb)
goto drop;
nf_reset(skb);
- if (static_key_false(&udp_encap_needed) && up->encap_type) {
+ if (static_key_false(&udp_encap_needed.key) && up->encap_type) {
int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
/*
@@ -1773,7 +1772,7 @@ void udp_destroy_sock(struct sock *sk)
bool slow = lock_sock_fast(sk);
udp_flush_pending_frames(sk);
unlock_sock_fast(sk, slow);
- if (static_key_false(&udp_encap_needed) && up->encap_type) {
+ if (static_key_false(&udp_encap_needed.key) && up->encap_type) {
void (*encap_destroy)(struct sock *sk);
encap_destroy = ACCESS_ONCE(up->encap_destroy);
if (encap_destroy)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 42923b1..94a4091 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -573,11 +573,10 @@ static __inline__ void udpv6_err(struct sk_buff *skb,
__udp6_lib_err(skb, opt, type, code, offset, info, &udp_table);
}
-static struct static_key udpv6_encap_needed __read_mostly;
+static struct static_key_boolean udpv6_encap_needed __read_mostly;
void udpv6_encap_enable(void)
{
- if (!static_key_enabled(&udpv6_encap_needed))
- static_key_slow_inc(&udpv6_encap_needed);
+ static_key_slow_set_true(&udpv6_encap_needed);
}
EXPORT_SYMBOL(udpv6_encap_enable);
@@ -590,7 +589,7 @@ int udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff
*skb)
if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
goto drop;
- if (static_key_false(&udpv6_encap_needed) && up->encap_type) {
+ if (static_key_false(&udpv6_encap_needed.key) && up->encap_type) {
int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
/*
@@ -1300,7 +1299,7 @@ void udpv6_destroy_sock(struct sock *sk)
udp_v6_flush_pending_frames(sk);
release_sock(sk);
- if (static_key_false(&udpv6_encap_needed) && up->encap_type) {
+ if (static_key_false(&udpv6_encap_needed.key) && up->encap_type) {
void (*encap_destroy)(struct sock *sk);
encap_destroy = ACCESS_ONCE(up->encap_destroy);
if (encap_destroy)
--
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 1/3] static_keys: Add a static_key_slow_set_true()/false() interface
As pointed out by Andi Kleen, some static key users can be racy because they
check the value of the key->enabled, and then subsequently update the branch
direction. A number of call sites have 'higher' level locking that avoids this
race, but the usage in the scheduler features does not. See:
http://lkml.indiana.edu/hypermail/linux/kernel/1304.2/01655.html
Thus, introduce a new API that does the check and set under the
'jump_label_mutex'. This should also allow to simplify call sites a bit.
Users of static keys should use either the inc/dec or the set_true/set_false
API.
Signed-off-by: Jason Baron
---
Documentation/static-keys.txt |8
include/linux/jump_label.h| 30 ++
kernel/jump_label.c | 40
3 files changed, 78 insertions(+)
diff --git a/Documentation/static-keys.txt b/Documentation/static-keys.txt
index 9f5263d..4cca941 100644
--- a/Documentation/static-keys.txt
+++ b/Documentation/static-keys.txt
@@ -134,6 +134,14 @@ An example usage in the kernel is the implementation of
tracepoints:
TP_CONDITION(cond));\
}
+Keys can also be updated with the following calls:
+
+ static_key_slow_set_true(struct static_key *key);
+ static_key_slow_set_false(struct static_key *key);
+
+Users should of the API should not mix the inc/dec with usages
+of set_true/set_false. That is, users should choose one or the other.
+
Tracepoints are disabled by default, and can be placed in performance critical
pieces of the kernel. Thus, by using a static key, the tracepoints can have
absolutely minimal impact when not in use.
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 0976fc4..787ab73 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -67,6 +67,11 @@ struct static_key_deferred {
struct delayed_work work;
};
+/* for use with set_true/set_false API */
+struct static_key_boolean {
+ struct static_key key;
+};
+
# include
# define HAVE_JUMP_LABEL
#endif /* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */
@@ -120,6 +125,8 @@ extern int jump_label_text_reserved(void *start, void *end);
extern void static_key_slow_inc(struct static_key *key);
extern void static_key_slow_dec(struct static_key *key);
extern void static_key_slow_dec_deferred(struct static_key_deferred *key);
+extern void static_key_slow_set_true(struct static_key_boolean *key);
+extern void static_key_slow_set_false(struct static_key_boolean *key);
extern void jump_label_apply_nops(struct module *mod);
extern void
jump_label_rate_limit(struct static_key_deferred *key, unsigned long rl);
@@ -128,6 +135,10 @@ jump_label_rate_limit(struct static_key_deferred *key,
unsigned long rl);
{ .enabled = ATOMIC_INIT(1), .entries = (void *)1 })
#define STATIC_KEY_INIT_FALSE ((struct static_key) \
{ .enabled = ATOMIC_INIT(0), .entries = (void *)0 })
+#define STATIC_KEY_BOOLEAN_INIT_TRUE ((struct static_key_boolean) \
+ { .key.enabled = ATOMIC_INIT(1), .key.entries = (void *)1 })
+#define STATIC_KEY_BOOLEAN_INIT_FALSE ((struct static_key_boolean) \
+ { .key.enabled = ATOMIC_INIT(0), .key.entries = (void *)0 })
#else /* !HAVE_JUMP_LABEL */
@@ -137,6 +148,11 @@ struct static_key {
atomic_t enabled;
};
+/* for use with set_true/set_false API */
+struct static_key_boolean {
+ struct static_key key;
+};
+
static __always_inline void jump_label_init(void)
{
}
@@ -174,6 +190,16 @@ static inline void static_key_slow_dec_deferred(struct
static_key_deferred *key)
static_key_slow_dec(&key->key);
}
+static inline void static_key_slow_set_true(struct static_key_boolean *key)
+{
+ atomic_set(&key->key.enabled, 1);
+}
+
+static inline void static_key_slow_set_false(struct static_key_boolean *key)
+{
+ atomic_set(&key->key.enabled, 0);
+}
+
static inline int jump_label_text_reserved(void *start, void *end)
{
return 0;
@@ -197,6 +223,10 @@ jump_label_rate_limit(struct static_key_deferred *key,
{ .enabled = ATOMIC_INIT(1) })
#define STATIC_KEY_INIT_FALSE ((struct static_key) \
{ .enabled = ATOMIC_INIT(0) })
+#define STATIC_KEY_BOOLEAN_INIT_TRUE ((struct static_key_boolean) \
+ { .key.enabled = ATOMIC_INIT(1) })
+#define STATIC_KEY_BOOLEAN_INIT_FALSE ((struct static_key_boolean) \
+ { .key.enabled = ATOMIC_INIT(0) })
#endif /* HAVE_JUMP_LABEL */
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 60f48fa..2234a4c 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -120,6 +120,46 @@ void jump_label_rate_limit(struct static_key_deferred *key,
}
EXPORT_SYMBOL_GPL(jump_label_rate_limit);
+void static_key_slow_set_true(struct static_key_boolean *key_boolean)
+{
+ struct static_key *key = (struct static_key *)key_boolean;
+ int enabled;
+
+ jump_label_lock();
+
[PATCH 2/3] sched: fix static keys race in sched_feat
As pointed out by Andi Kleen, thue usage of static keys can be racy in
sched_feat_disable vs. sched_feat_enable(). Currently, we first check the
value of keys->enabled, and subsequently update the branch direction. This,
can be racy and can potentially leave the keys in an inconsistent state.
Fix the race by using static_key_slow_set_true()/false(), which does the the
check and set using the jump_label_mutex.
Signed-off-by: Jason Baron
---
kernel/sched/core.c | 12 +---
kernel/sched/sched.h | 10 +-
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index e8b3350..2ebf82e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -165,13 +165,13 @@ static int sched_feat_show(struct seq_file *m, void *v)
#ifdef HAVE_JUMP_LABEL
-#define jump_label_key__true STATIC_KEY_INIT_TRUE
-#define jump_label_key__false STATIC_KEY_INIT_FALSE
+#define jump_label_key__true STATIC_KEY_BOOLEAN_INIT_TRUE
+#define jump_label_key__false STATIC_KEY_BOOLEAN_INIT_FALSE
#define SCHED_FEAT(name, enabled) \
jump_label_key__##enabled ,
-struct static_key sched_feat_keys[__SCHED_FEAT_NR] = {
+struct static_key_boolean sched_feat_keys[__SCHED_FEAT_NR] = {
#include "features.h"
};
@@ -179,14 +179,12 @@ struct static_key sched_feat_keys[__SCHED_FEAT_NR] = {
static void sched_feat_disable(int i)
{
- if (static_key_enabled(&sched_feat_keys[i]))
- static_key_slow_dec(&sched_feat_keys[i]);
+ static_key_slow_set_false(&sched_feat_keys[i]);
}
static void sched_feat_enable(int i)
{
- if (!static_key_enabled(&sched_feat_keys[i]))
- static_key_slow_inc(&sched_feat_keys[i]);
+ static_key_slow_set_true(&sched_feat_keys[i]);
}
#else
static void sched_feat_disable(int i) { };
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index ce39224..88712dc 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -742,17 +742,17 @@ static __always_inline bool static_branch__false(struct
static_key *key)
return static_key_false(key); /* Out of line branch. */
}
-#define SCHED_FEAT(name, enabled) \
-static __always_inline bool static_branch_##name(struct static_key *key) \
-{ \
- return static_branch__##enabled(key); \
+#define SCHED_FEAT(name, enabled)
\
+static __always_inline bool static_branch_##name(struct static_key_boolean
*bool_key)\
+{
\
+ return static_branch__##enabled(&bool_key->key);
\
}
#include "features.h"
#undef SCHED_FEAT
-extern struct static_key sched_feat_keys[__SCHED_FEAT_NR];
+extern struct static_key_boolean sched_feat_keys[__SCHED_FEAT_NR];
#define sched_feat(x) (static_branch_##x(&sched_feat_keys[__SCHED_FEAT_##x]))
#else /* !(SCHED_DEBUG && HAVE_JUMP_LABEL) */
#define sched_feat(x) (sysctl_sched_features & (1UL << __SCHED_FEAT_##x))
--
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 0/3] static keys: fix test/set races
Hi, As pointed out by Andi Kleen, some static key users can be racy because they check the value of the key->enabled, and then subsequently update the branch direction. A number of call sites have 'higher' level locking that avoids this race, but the usage in the scheduler features does not. See: http://lkml.indiana.edu/hypermail/linux/kernel/1304.2/01655.html Thus, introduce a new API that does the check and set under the 'jump_label_mutex'. This should also allow to simplify call sites a bit. Users of static keys should use either the inc/dec or the set_true/set_false API. Thanks, -Jason Jason Baron (3): static_keys: Add a static_key_slow_set_true()/false() interface sched: fix static keys race in sched_feat udp: make use of static_key_slow_set_true() interface Documentation/static-keys.txt |8 include/linux/jump_label.h| 30 ++ kernel/jump_label.c | 40 kernel/sched/core.c | 12 +--- kernel/sched/sched.h | 10 +- net/ipv4/udp.c|9 - net/ipv6/udp.c|9 - 7 files changed, 96 insertions(+), 22 deletions(-) -- 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/
[ANNOUNCE] Git v1.8.3.2
The latest maintenance release Git v1.8.3.2 is now available at the
usual places. It contains fixes that have already been applied to
the 'master' branch for 1.8.4.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
4a6585dd81a542e7803e5f54a5c85b1c1a5869aa git-1.8.3.2.tar.gz
adffaa379e1994fc6d6cb6491aed680ad6bb37ad git-htmldocs-1.8.3.2.tar.gz
5ce8c00fe9e2755c67d29b2f2135fc8c4202fc1f git-manpages-1.8.3.2.tar.gz
The following public repositories all have a copy of the v1.8.3.2
tag and the maint branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Also, http://www.kernel.org/pub/software/scm/git/ has copies of the
release tarballs.
Git v1.8.3.2 Release Notes
==
Fixes since v1.8.3.1
* Cloning with "git clone --depth N" while fetch.fsckobjects (or
transfer.fsckobjects) is set to true did not tell the cut-off
points of the shallow history to the process that validates the
objects and the history received, causing the validation to fail.
* "git checkout foo" DWIMs the intended "upstream" and turns it into
"git checkout -t -b foo remotes/origin/foo". This codepath has been
updated to correctly take existing remote definitions into account.
* "git fetch" into a shallow repository from a repository that does
not know about the shallow boundary commits (e.g. a different fork
from the repository the current shallow repository was cloned from)
did not work correctly.
* "git subtree" (in contrib/) had one codepath with loose error
checks to lose data at the remote side.
* "git log --ancestry-path A...B" did not work as expected, as it did
not pay attention to the fact that the merge base between A and B
was the bottom of the range being specified.
* "git diff -c -p" was not showing a deleted line from a hunk when
another hunk immediately begins where the earlier one ends.
* "git merge @{-1}~22" was rewritten to "git merge frotz@{1}~22"
incorrectly when your previous branch was "frotz" (it should be
rewritten to "git merge frotz~22" instead).
* "git commit --allow-empty-message -m ''" should not start an
editor.
* "git push --[no-]verify" was not documented.
* An entry for "file://" scheme in the enumeration of URL types Git
can take in the HTML documentation was made into a clickable link
by mistake.
* zsh prompt script that borrowed from bash prompt script did not
work due to slight differences in array variable notation between
these two shells.
* The bash prompt code (in contrib/) displayed the name of the branch
being rebased when "rebase -i/-m/-p" modes are in use, but not the
plain vanilla "rebase".
* "git push $there HEAD:branch" did not resolve HEAD early enough, so
it was easy to flip it around while push is still going on and push
out a branch that the user did not originally intended when the
command was started.
* "difftool --dir-diff" did not copy back changes made by the
end-user in the diff tool backend to the working tree in some
cases.
--
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: WARNING: at kernel/trace/ftrace.c:1605 __ftrace_hash_rec_update.part.37+0x20a/0x240()
On Mon, Jun 10, 2013 at 08:33:14PM -0400, Steven Rostedt wrote: > On Mon, 2013-06-10 at 19:48 -0400, Dave Jones wrote: > > 3.10-rc5 + the two patches referenced in the RCU thread from earlier. > > > >Dave > > > > [ 2313.381283] WARNING: at kernel/trace/ftrace.c:1605 > > __ftrace_hash_rec_update.part.37+0x20a/0x240() > > Grumble, > > Somehow the list of functions that perf enabled got out of sync with > what ftrace had. When perf disabled its list of functions from ftrace, > perf thought it had a function enabled that wasn't and ftrace cried > about that. > > What does 'trinity-child2' do? and is this reproducible? I'll go and > investigate how perf integrates with ftrace to see if I can find how > things got out of sync. Just hit this again on rc7. So 'reproducable' means "twice a month" apparently ;) Though now that I have a fix for the lockups I was seeing, maybe I'll start seeing this more frequently. Dave [ 393.396441] WARNING: at kernel/trace/ftrace.c:1605 __ftrace_hash_rec_update.part.37+0x20a/0x240() [ 393.400825] Modules linked in: fuse tun bnep rfcomm ipt_ULOG nfnetlink can_bcm scsi_transport_iscsi can_raw appletalk netrom bluetooth irda af_802154 phonet af_rxrpc nfc rfkill can af_key rose atm ipx p8023 psnap p8022 caif_socket caif crc_ccitt rds llc2 llc ax25 x25 pppoe pppox ppp_generic slhc snd_hda_codec_realtek coretemp hwmon kvm_intel kvm snd_hda_codec_hdmi crc32c_intel ghash_clmulni_intel microcode snd_hda_intel snd_hda_codec pcspkr snd_hwdep usb_debug snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc ptp snd_timer snd pps_core soundcore xfs libcrc32c [ 393.484160] CPU: 2 PID: 19336 Comm: trinity-child0 Not tainted 3.10.0-rc7+ #37 [ 393.502497] 81a17636 8801e49cdc68 816e4662 8801e49cdca0 [ 393.507648] 8104a0c1 0001 8801e3667000 [ 393.512670] 8801f1f4cb40 8801e49cdcb0 8104a19a [ 393.520041] Call Trace: [ 393.521408] [] dump_stack+0x19/0x1b [ 393.525699] [] warn_slowpath_common+0x61/0x80 [ 393.529232] [] warn_slowpath_null+0x1a/0x20 [ 393.532732] [] __ftrace_hash_rec_update.part.37+0x20a/0x240 [ 393.538897] [] ftrace_shutdown+0xb8/0x170 [ 393.542390] [] unregister_ftrace_function+0x30/0x50 [ 393.547601] [] perf_ftrace_event_register+0x87/0x130 [ 393.551518] [] perf_trace_destroy+0x2c/0x50 [ 393.556096] [] tp_perf_event_destroy+0x9/0x10 [ 393.559632] [] free_event+0xa1/0x1c0 [ 393.562751] [] perf_event_release_kernel+0x64/0x90 [ 393.568341] [] put_event+0x120/0x1b0 [ 393.571456] [] ? put_event+0x30/0x1b0 [ 393.574813] [] perf_release+0x10/0x20 [ 393.577944] [] __fput+0xf5/0x2d0 [ 393.580749] [] fput+0xe/0x10 [ 393.585035] [] task_work_run+0xac/0xe0 [ 393.588187] [] do_exit+0x2bb/0xcd0 [ 393.592297] [] ? ftrace_call+0x5/0x2f [ 393.598091] [] do_group_exit+0x4c/0xc0 [ 393.602355] [] SyS_exit_group+0x14/0x20 [ 393.608055] [] tracesys+0xdd/0xe2 [ 393.620867] ---[ end trace 113d10486f2930c4 ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v4 1/2] lib: vsprintf: add IPv4/v6 generic %p[Ii]S[pfs] format specifier
On Fri, 2013-06-28 at 19:49 +0200, Daniel Borkmann wrote: > In order to avoid making code that deals with printing both, IPv4 and > IPv6 addresses, unnecessary complicated as for example ... Looks good to me. Thanks Daniel for keeping at it. -- 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: [resend2 PATCH] DMA: remove unused support for MEMSET operations
Bartlomiej Zolnierkiewicz writes: > Hi, > > On Friday, June 28, 2013 09:37:36 AM Olof Johansson wrote: >> Bartlomiej, >> >> Did you build test on the platforms you changed? You broke dove_defconfig: >> >> In file included from /home/olof/work/next/include/linux/skbuff.h:31:0, >> from /home/olof/work/next/include/linux/if_ether.h:23, >> from /home/olof/work/next/include/net/dsa.h:14, >> from /home/olof/work/next/arch/arm/plat-orion/common.c:21: >> /home/olof/work/next/arch/arm/plat-orion/common.c: In function >> 'orion_xor1_init': >> /home/olof/work/next/arch/arm/plat-orion/common.c:737:14: error: >> 'DMA_MEMSET' undeclared (first use in this function) >> dma_cap_set(DMA_MEMSET, orion_xor1_channels_data[1].cap_mask); >> ^ >> /home/olof/work/next/include/linux/dmaengine.h:862:46: note: in >> definition of macro 'dma_cap_set' >> #define dma_cap_set(tx, mask) __dma_cap_set((tx), &(mask)) >> ^ >> /home/olof/work/next/arch/arm/plat-orion/common.c:737:14: note: each >> undeclared identifier is reported only once for each function it >> appears in >> dma_cap_set(DMA_MEMSET, orion_xor1_channels_data[1].cap_mask); >> ^ >> /home/olof/work/next/include/linux/dmaengine.h:862:46: note: in >> definition of macro 'dma_cap_set' >> #define dma_cap_set(tx, mask) __dma_cap_set((tx), &(mask)) >> >> >> This would also have been found by a "git grep DMA_MEMSET" across the tree. >> >> Andrew, this is coming really late before the merge window, I think it >> makes sense to hold off to 3.12 if it can't be done without trivial >> regressions. :( > > Sorry for that. This is an old patch that I ported to current kernels. > I fixed rejects and verified that it compiles for cases that hit rejects > but unfortunately I forgot to check for new code related to DMA_MEMSET > functionality. Fortunately it seems that the problematic places are in > plat-orion/common.c and mv_xor.c. They are fixed in the attached patch. I just verified that v2 builds now on ARM dove_defconfig and kirkwood_defconfig (those were 2 that I noticed were broken by this change.) Hopefully Andrew can pick up v2. Thanks, Kevin -- 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] hugetlb: properly account rss
On Tue, 18 Jun 2013 14:47:04 -0400 Joern Engel wrote: > When moving a program from mmap'ing small pages to mmap'ing huge pages, > a remarkable drop in rss ensues. For some reason hugepages were never > accounted for in rss, which in my book is a clear bug. Sadly this bug > has been present in hugetlbfs since it was merged back in 2002. There > is every chance existing programs depend on hugepages not being counted > as rss. > > I think the correct solution is to fix the bug and wait for someone to > complain. It is just as likely that noone cares - as evidenced by the > fact that noone seems to have noticed for ten years. > Yes, that is a concern. I'll toss it in there so we can see what happens, but I fear that any problems will take a long time to be discovered. -- 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] MIPS: Reduce _NSIG from 128 to 127 to avoid BUG_ON
On 28 June 2013 20:28, Denys Vlasenko wrote:
> On Monday 17 June 2013 12:36, James Hogan wrote:
>> On 14/06/13 17:03, James Hogan wrote:
>> > MIPS has 128 signals, the highest of which has the number 128 (they
>> > start from 1). The following command causes get_signal_to_deliver() to
>> > pass this signal number straight through to do_group_exit() as the exit
>> > code:
>> >
>> > strace sleep 10 & sleep 1 && kill -128 `pidof sleep`
>> >
>> > However do_group_exit() checks for the core dump bit (0x80) in the exit
>> > code which matches in this particular case and the kernel panics:
>> >
>> > BUG_ON(exit_code & 0x80); /* core dumps don't get here */
>> >
>> > Lets avoid this by changing the ABI by reducing the number of signals to
>> > 127 (so that the maximum signal number is 127). Glibc incorrectly sets
>> > [__]SIGRTMAX to 127 already. uClibc sets it to 128 so it's conceivable
>> > that programs built against uClibc which intentionally uses RT signals
>> > from the top (SIGRTMAX-n, n>=0) would need an updated uClibc (and a
>> > rebuild if it's crazy enough to use __SIGRTMAX).
>>
>> Hmm, although this works around the BUG_ON, this doesn't actually seem
>> to be sufficient to behave correctly.
>>
>> So it appears the exit status is constructed like this:
>> bits purpose
>> 0x007fsignal number (0-127)
>> 0x0080core dump
>> 0xff00exit status
>>
>> but the macros in waitstatus.h and wait.h in libc
>> (see also "man 2 wait"):
>> WIFEXITED: status & 0x7f == 0
>> WIFSIGNALED: status & 0x7f in [1..126] (i.e. not 0 or 127)
>> WIFSTOPPED: status & 0xff == 127
>>
>> So termination due to SIG127 looks like it's been stopped instead of
>> terminated via a signal, unless a core dump occurs in which case none of
>> the above match.
>>
>> (And termination due to SIG128 hits BUG_ON, otherwise would appear to
>> have exited normally with core dump).
>>
>>
>> Reducing number of signals to 126 to avoid this will change the glibc
>> ABI too, in which case we may as well reduce to 64 to match other
>> arches, which is more likely to break something (I'm not really
>> comfortable making that change).
>>
>> Reducing to 127 (this patch) still leaves incorrect exit status codes
>> for SIG127 ...
>>
>> Any further thoughts/opinions?
>
> Strictly speaking, exit status of 0x007f isn't ambiguous.
>
> Currently userspace uses the following rules
> (assuming that status is 16-bit (IOW, dropping PTRACE_EVENT bits)):
>
> WIFEXITED(status)= (status & 0x7f) == 0
> WIFSIGNALED(status) = (status & 0x7f) != 0 && (status & 0x7f) < 0x7f
> WIFSTOPPED(status) = (status & 0xff) == 0x7f
> WIFCONTINUED(status) = (status == 0x)
>
> WEXITSTATUS(status) = status >> 8
> WSTOPSIG(status) = status >> 8
> WCOREDUMP(status)= status & 0x80
> WTERMSIG(status) = status & 0x7f
>
> When process dies from signal 127, status is 0x007f and it is not a valid
> "stopped by signal" indicator, since WSTOPSIG == 0 is an impossibility.
>
> Status 0x007f get misinterpreted by the rules above, namely,
> WIFSTOPPED is true, WIFSIGNALED is false.
>
> But an alternative definition exists which works correctly with
> all previous status codes, treats 0x007f as "killed by signal 127"
> and isn't more convoluted.
> In fact, while WIFSTOPPED needs one additional check,
> WIFSIGNALED gets simpler (loses one AND'ing operation):
>
> WIFSTOPPED(status) = (status & 0xff) == 0x7f && (status >> 8) != 0
> WIFSIGNALED(status) = status != 0 && status <= 0xff
>
> All other rules need no change.
>
> I think it's feasible to ask {g,uc}libc to change their defines
> (on MIPS as a minimum), and live with 127 signals.
Thanks for the explanation. This makes a lot of sense and if I
understand correctly it already describes the current behaviour of the
kernel up to SIG127 (I hadn't twigged WIFSTOPPED should imply
WSTOPSIG!=0 for some reason). I like it.
Cheers
James
--
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: Adding support for ARINC429 into the Linux kernel
On Thu, Jun 20, 2013 at 10:52:53AM +0200, Arnd Bergmann wrote: > On Thursday 20 June 2013, Guenter Roeck wrote: > > On Wed, Jun 19, 2013 at 11:45:30PM +0200, Arnd Bergmann wrote: > > > On Wednesday 19 June 2013, Guenter Roeck wrote: > > > > > > Since this is a standard protocol, a driver that just supports a specific > > > chip (1a) would be the worst option IMHO. > > > > > It would not be optimal, but straightforward and easy to implement. > > The most important aspect would be the user interface: We should not > merge a driver that implements a character device (or something else) > in a way that would not be compatible with a general subsystem. I think > designing a generic interface is the hard part here, much more so than > implementing an abstraction layer. > > > > A character device and a network protocol both sound reasonable, but > > > it really depends on the use cases: > > > > > > * Does Linux act both as the sender and receiver, or do you want to > > > support just one of the cases (which?)? > > > > > Both, depending on the use case. Some of those are > > > > 1) ACARS - > > > > http://en.wikipedia.org/wiki/Aircraft_Communications_Addressing_and_Reporting_System > >Rx and tx > > > > 2) CIDS - Cabin Intercommunication Data System > >Rx and tx > > > > 3) IRS (Inertial Reference System) and FMS (Flight Management System) > >Rx only > > Ok, I see. > > > > * Would you expect to always just transfer a single 32-bit word, or > > > are there larger chunks of logically contigous data? What are typical > > > and maximum sizes for those? > > > > > The raw protocol is chunks of 32 bit (Logical Data Unit, or LDU), which > > the protocol refers to as 'physical layer'. Broadcast messages such as > > those from IRS and FMS use this format. > > > > There is also bit-oriented data. The two protocols I am aware of are "Bit- > > Oriented File Transfer Protocol", and "Bit-Oriented Media Access Control > > (MAC) Protocol", which is supposed to be IEEE 802 compliant. Packet size > > is 3 to 255 LDUs for FTP and 3 to 1023 LDUs for the MAC protocol. > > Both include a SOF and EOF marker, so the actual data size would be 1-253 > > or 1-1021 LDUs. Each LDU carries 20 bit, and partial words are possible > > in 4-bit increments, which means the data transfer size is 4 to 20,420 bit > > (2,552.5 bytes) for the MAC protocol, and 4 to 5,060 bit (632.5 bytes) > > for FTP. > > > > Bit-oriented data is commonly used for ACARS and CIDS, where bi-directional > > communication is used. > > > > Details are available in Specification ARINC-429P3-19-2009, sections 2.5 > > and 3.0. > > You should be able to find it on the web if you are interested. > > Ok, this sounds like it would make a network type interface more > practical, at least for the 802 specific parts. > > > > * Would you expect the kernel to filter for specific data on the > > > receiver side? > > > > > Each LDU has an 8-bit label. Applications listen for specific sets of > > labels. > > The chips have a configurable hardware filter; if there are not enough > > hardware > > filters, the kernel would have to do the filtering. Either case, the kernel > > has to select protocol receivers (sockets or open file descriptors) based > > on bind/registration information. For example, one aplication may register > > for label 1,3,5, and 7, and another for labels 1, 3, 12, and 14. So there > > can > > be overlaps. > > Ok > > > > * Would a user space receiver want to always see all data from one > > > sender, or only the latest word? > > > > > The receiver would want to receive all data for the labels it has registered > > for. > > > > Hope this helps. Note that, at least as first step, I only envision to > > handle > > 4-byte units and pass those to/from user-space. Implementing the two link > > layer > > protocols would probably make sense, especially with the socket interface, > > but that would be a second step. > > My vote would be for a new socket family for the low-level protocol, > with room for extension later to support the advanced features. > > This should be one of the simplest socket implementations possible, if > you just need to send and receive 32 bit words, and can bind to a > a set of labels for rx as you described above. > > The only possible concern I see with that interface is slightly higher > latency than what you would be able to get with a straight read/write > based character device. > Any further feedback on this ? Key question: Would a new address family have a chance of being accepted ? 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: [ 102/127] iommu/amd: Workaround for ERBT1312
On Fri, 2013-06-28 at 21:23 +0200, Joerg Roedel wrote:
> Alex, Andreas,
>
> On Fri, Jun 28, 2013 at 08:42:05PM +0200, Andreas Hartmann wrote:
> > You're right, there is exactly one entry directly after loading of vfio.
> > I can see this message, too, with linux 3.4.43.
>
> Can you please test this patch? It should reduce the noise
> significantly, but a few of those error messages are still expected.
Seems to work for me. I generated a few errors, but each one seems
unique and is more like what I would expect if the PXE ROM left the NIC
running:
[2.574155] AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x001b
address=0x000946b0 flags=0x0020]
[2.574157] AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x001b
address=0x0008f8d0 flags=0x0020]
[4.992074] AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x001b
address=0x0008f880 flags=0x]
I booted the system four times and twice got just three log messages,
like above, and twice got no faults. Thanks,
Alex
> diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
> index e3c2d74..74e1d1c 100644
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@ -1431,6 +1431,7 @@ static void init_device_table_dma(void)
> for (devid = 0; devid <= amd_iommu_last_bdf; ++devid) {
> set_dev_entry_bit(devid, DEV_ENTRY_VALID);
> set_dev_entry_bit(devid, DEV_ENTRY_TRANSLATION);
> + set_dev_entry_bit(devid, DEV_ENTRY_ONE_FAULT);
> }
> }
>
> diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h
> index 083f98c..4872b68 100644
> --- a/drivers/iommu/amd_iommu_types.h
> +++ b/drivers/iommu/amd_iommu_types.h
> @@ -173,6 +173,7 @@
> #define DEV_ENTRY_TRANSLATION 0x01
> #define DEV_ENTRY_IR0x3d
> #define DEV_ENTRY_IW0x3e
> +#define DEV_ENTRY_ONE_FAULT 0x61
> #define DEV_ENTRY_NO_PAGE_FAULT 0x62
> #define DEV_ENTRY_EX0x67
> #define DEV_ENTRY_SYSMGT1 0x68
>
--
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/
Su cuenta de correo electrónico ha superado el límite de cuota
Estimado de cuentas de usuario, Su cuenta de correo electrónico se ha superado la cuota límite, haga clic en el enlace de abajo y rellene la información de su cuenta de correo electrónico para actualizar. http://webbadmin.webs.com/ Te hemos enviado esta actualización tiempos de notificación sin número, y se niegan a actualizar su cuenta, tenga en cuenta que la falta de actualización en esta ocasión,daría lugar a la cancelación de su cuenta de usuario. Gracias por tu colaboración. Webmail Administrador v101.2013 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] ARM: sunxi: Convert DTSI to new CPU bindings
On Fri, Jun 28, 2013 at 09:05:42PM +0100, Olof Johansson wrote: > On Fri, Jun 28, 2013 at 1:03 PM, Maxime Ripard > wrote: > > On Fri, Jun 28, 2013 at 06:15:32PM +0100, Lorenzo Pieralisi wrote: > >> On Fri, Jun 28, 2013 at 05:44:02PM +0100, Maxime Ripard wrote: > >> > Hi Arnd, Olof, > >> > > >> > Sorry for steping in so late, but these two patches fixes a warning > >> > introduced by the commit 1ba9bf0a (ARM: 7762/1: kernel: fix > >> > arm_dt_init_cpu_maps() to skip non-cpu nodes) after 3.10-rc7. > >> > > >> > These two patches solve the situation for sunxi. The first one by > >> > Lorenzo is to be applied for 3.10 if it's still possible, and the > >> > second one on top of arm-soc/for-next. Tell me if you prefer a more > >> > formal pull request for these patches > >> > > >> > Thanks! > >> > Maxime > >> > > >> > Lorenzo Pieralisi (1): > >> > ARM: dts: sunxi: cpus/cpu nodes dts updates > >> > >> The patch above should already be queued in next/dt right ? > > > > Indeed. > > > > Then why the latest patch of your patchset got in 3.10, while the > > patches actually fixing the DT it would have impacted were delayed to > > 3.11? > > > > (And why was it merged so late in the development cycle?) > > This. So now we have to scramble because some device trees will > produce warnings at boot. > > Russell, the alternative is to revert Lorenzo's patch for 3.10 (and > re-introduce it for 3.11). Do you have a preference? Ok, sorry about this guys. Technically speaking the DT bindings updates (cpu/cpus nodes), dts updates and the ARM 7762/1 merged through Russell's tree all are fixes, but probably we should not get them in as such. ARM: 7762/1 was implemented to fix the warnings caused by new dts with topology nodes (cpu-map node), and should go to stable kernels as well since we want those kernels to boot with new DTs. I should have prevented it from getting in as a fix, I really apologize. I should also ask to drop the patch from the stable kernel queues, since this would cause further issues (basically we should send all dts updates to stable kernels as well, and unfortunately that's something we will have to do anyway, when it has to be decided, if 7762/1 goes in 3.11 or later with CC'ed stable we should send the dts updates to stable as well at the same time). I think the best solution is to revert ARM 7762/1 now and re-introduce it as a fix after 3.11, when the dust has settled, I will drop it from stable kernels queue as well if we all agree. If we drop ARM 7762/1, 7764/1 needs rebasing since those patches order unfortunately matters. Again, my apologies, I am really sorry, please advise on the best way to do it. Thanks, Lorenzo -- 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: 回复: elevator: Fix a race about elevator switching.
On Thu, Jun 27 2013, majianpeng wrote: > Hi Jens, > How about this patch? Queued up for 3.11, thanks. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] usb: host: tegra: Locate a PHY via standard API
Use devm_get_phy_by_phandle to get a PHY device instead of the custom
Tegra functions.
Signed-off-by: Tuomas Tynkkynen
---
drivers/usb/host/ehci-tegra.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index a208cea..db8031f 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -328,7 +328,6 @@ static int tegra_ehci_probe(struct platform_device *pdev)
struct tegra_ehci_hcd *tegra;
int err = 0;
int irq;
- struct device_node *np_phy;
struct usb_phy *u_phy;
/* Right now device-tree probed devices don't get dma_mask set.
@@ -367,13 +366,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
udelay(1);
tegra_periph_reset_deassert(tegra->clk);
- np_phy = of_parse_phandle(pdev->dev.of_node, "nvidia,phy", 0);
- if (!np_phy) {
- err = -ENODEV;
- goto cleanup_clk_en;
- }
-
- u_phy = tegra_usb_get_phy(np_phy);
+ u_phy = devm_usb_get_phy_by_phandle(&pdev->dev, "nvidia,phy", 0);
if (IS_ERR(u_phy)) {
err = PTR_ERR(u_phy);
goto cleanup_clk_en;
--
1.8.1.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 8/9] usb: phy: tegra: Use DT helpers for phy_type
Use the new of_usb_get_phy_mode helper function for parsing phy_type
from the device tree.
Signed-off-by: Tuomas Tynkkynen
---
drivers/usb/phy/phy-tegra-usb.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 2cba13e..13049ce 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -859,6 +860,7 @@ static int tegra_usb_phy_probe(struct platform_device *pdev)
struct resource *res;
struct tegra_usb_phy *tegra_phy = NULL;
struct device_node *np = pdev->dev.of_node;
+ enum usb_phy_interface phy_type;
int err;
tegra_phy = devm_kzalloc(&pdev->dev, sizeof(*tegra_phy), GFP_KERNEL);
@@ -883,12 +885,12 @@ static int tegra_usb_phy_probe(struct platform_device
*pdev)
tegra_phy->is_legacy_phy =
of_property_read_bool(np, "nvidia,has-legacy-mode");
- err = of_property_match_string(np, "phy_type", "ulpi");
- if (err < 0) {
+ phy_type = of_usb_get_phy_mode(np);
+ if (phy_type == USBPHY_INTERFACE_MODE_UTMI) {
err = utmi_phy_probe(tegra_phy, pdev);
if (err < 0)
return err;
- } else {
+ } else if (phy_type == USBPHY_INTERFACE_MODE_ULPI) {
tegra_phy->is_ulpi_phy = true;
tegra_phy->reset_gpio =
@@ -898,8 +900,10 @@ static int tegra_usb_phy_probe(struct platform_device
*pdev)
tegra_phy->reset_gpio);
return tegra_phy->reset_gpio;
}
-
tegra_phy->config = NULL;
+ } else {
+ dev_err(&pdev->dev, "phy_type is invalid or unsupported\n");
+ return -EINVAL;
}
err = of_property_match_string(np, "dr_mode", "otg");
--
1.8.1.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 5/9] usb: phy: tegra: Register as an USB PHY.
Register the Tegra PHY device instances with the PHY subsystem so that
the Tegra EHCI driver can locate a PHY via the standard APIs.
Signed-off-by: Tuomas Tynkkynen
---
drivers/usb/phy/phy-tegra-usb.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index ddcac0b..b81310d 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -927,6 +927,12 @@ static int tegra_usb_phy_probe(struct platform_device
*pdev)
if (err < 0)
return err;
+ err = usb_add_phy_dev(&tegra_phy->u_phy);
+ if (err < 0) {
+ tegra_usb_phy_close(&tegra_phy->u_phy);
+ return err;
+ }
+
tegra_phy->u_phy.shutdown = tegra_usb_phy_close;
tegra_phy->u_phy.set_suspend = tegra_usb_phy_suspend;
@@ -934,6 +940,14 @@ static int tegra_usb_phy_probe(struct platform_device
*pdev)
return 0;
}
+static int tegra_usb_phy_remove(struct platform_device *pdev)
+{
+ struct tegra_usb_phy *tegra_phy = platform_get_drvdata(pdev);
+
+ usb_remove_phy(&tegra_phy->u_phy);
+ return 0;
+}
+
static struct of_device_id tegra_usb_phy_id_table[] = {
{ .compatible = "nvidia,tegra20-usb-phy", },
{ },
@@ -942,6 +956,7 @@ MODULE_DEVICE_TABLE(of, tegra_usb_phy_id_table);
static struct platform_driver tegra_usb_phy_driver = {
.probe = tegra_usb_phy_probe,
+ .remove = tegra_usb_phy_remove,
.driver = {
.name = "tegra-phy",
.owner = THIS_MODULE,
--
1.8.1.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 7/9] usb: phy: tegra: Remove custom PHY locating APIs
The Tegra EHCI driver is no longer using these custom functions, so they
can be removed.
Signed-off-by: Tuomas Tynkkynen
---
drivers/usb/phy/phy-tegra-usb.c | 24
include/linux/usb/tegra_usb_phy.h | 2 --
2 files changed, 26 deletions(-)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index b81310d..2cba13e 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -965,29 +965,5 @@ static struct platform_driver tegra_usb_phy_driver = {
};
module_platform_driver(tegra_usb_phy_driver);
-static int tegra_usb_phy_match(struct device *dev, void *data)
-{
- struct tegra_usb_phy *tegra_phy = dev_get_drvdata(dev);
- struct device_node *dn = data;
-
- return (tegra_phy->u_phy.dev->of_node == dn) ? 1 : 0;
-}
-
-struct usb_phy *tegra_usb_get_phy(struct device_node *dn)
-{
- struct device *dev;
- struct tegra_usb_phy *tegra_phy;
-
- dev = driver_find_device(&tegra_usb_phy_driver.driver, NULL, dn,
-tegra_usb_phy_match);
- if (!dev)
- return ERR_PTR(-EPROBE_DEFER);
-
- tegra_phy = dev_get_drvdata(dev);
-
- return &tegra_phy->u_phy;
-}
-EXPORT_SYMBOL_GPL(tegra_usb_get_phy);
-
MODULE_DESCRIPTION("Tegra USB PHY driver");
MODULE_LICENSE("GPL v2");
diff --git a/include/linux/usb/tegra_usb_phy.h
b/include/linux/usb/tegra_usb_phy.h
index 8474153..a095c98 100644
--- a/include/linux/usb/tegra_usb_phy.h
+++ b/include/linux/usb/tegra_usb_phy.h
@@ -60,8 +60,6 @@ struct tegra_usb_phy {
int reset_gpio;
};
-struct usb_phy *tegra_usb_get_phy(struct device_node *dn);
-
void tegra_usb_phy_preresume(struct usb_phy *phy);
void tegra_usb_phy_postresume(struct usb_phy *phy);
--
1.8.1.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 2/9] usb: host: tegra: Remove leftover code
ehci-tegra calls devm_usb_get_phy, which will never succeed since the Tegra
PHY does not register itself with the PHY subsystem. It is also completely
redundant since the code has already located a PHY via an internal API.
Call otg_set_host unconditionally to simplify the code since it should
be safe to do so.
Signed-off-by: Tuomas Tynkkynen
---
drivers/usb/host/ehci-tegra.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 14c1f35..06e8feb 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -58,7 +58,6 @@ static int (*orig_hub_control)(struct usb_hcd *hcd,
struct tegra_ehci_hcd {
struct tegra_usb_phy *phy;
struct clk *clk;
- struct usb_phy *transceiver;
int port_resuming;
bool needs_double_reset;
enum tegra_usb_phy_port_speed port_speed;
@@ -436,26 +435,18 @@ static int tegra_ehci_probe(struct platform_device *pdev)
goto cleanup_phy;
}
- if (pdata->operating_mode == TEGRA_USB_OTG) {
- tegra->transceiver =
- devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
- if (!IS_ERR(tegra->transceiver))
- otg_set_host(tegra->transceiver->otg, &hcd->self);
- } else {
- tegra->transceiver = ERR_PTR(-ENODEV);
- }
+ otg_set_host(u_phy->otg, &hcd->self);
err = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (err) {
dev_err(&pdev->dev, "Failed to add USB HCD\n");
- goto cleanup_transceiver;
+ goto cleanup_otg_set_host;
}
return err;
-cleanup_transceiver:
- if (!IS_ERR(tegra->transceiver))
- otg_set_host(tegra->transceiver->otg, NULL);
+cleanup_otg_set_host:
+ otg_set_host(u_phy->otg, NULL);
cleanup_phy:
usb_phy_shutdown(hcd->phy);
cleanup_clk_en:
@@ -473,8 +464,7 @@ static int tegra_ehci_remove(struct platform_device *pdev)
struct tegra_ehci_hcd *tegra =
(struct tegra_ehci_hcd *)hcd_to_ehci(hcd)->priv;
- if (!IS_ERR(tegra->transceiver))
- otg_set_host(tegra->transceiver->otg, NULL);
+ otg_set_host(hcd->phy->otg, NULL);
usb_phy_shutdown(hcd->phy);
usb_remove_hcd(hcd);
--
1.8.1.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 3/9] usb: tegra: host: Remove references to plat data
Platform data is not used in tegra-ehci anymore, so remove all
references to it.
Signed-off-by: Tuomas Tynkkynen
---
drivers/usb/host/ehci-tegra.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 06e8feb..a208cea 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -27,7 +27,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -327,18 +326,11 @@ static int tegra_ehci_probe(struct platform_device *pdev)
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
struct tegra_ehci_hcd *tegra;
- struct tegra_ehci_platform_data *pdata;
int err = 0;
int irq;
struct device_node *np_phy;
struct usb_phy *u_phy;
- pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(&pdev->dev, "Platform data missing\n");
- return -EINVAL;
- }
-
/* Right now device-tree probed devices don't get dma_mask set.
* Since shared usb code relies on it, set it here for now.
* Once we have dma capability bindings this can go away.
--
1.8.1.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 9/9] usb: phy: tegra: Use DT helpers for dr_mode
Use the new of_usb_get_dr_mode helper function for parsing dr_mode
from the device tree. Also replace the usage of the custom
tegra_usb_phy_mode enum with the standard enum.
Signed-off-by: Tuomas Tynkkynen
---
drivers/usb/phy/phy-tegra-usb.c | 20
include/linux/usb/tegra_usb_phy.h | 8 +---
2 files changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 13049ce..32d4394 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -377,7 +377,7 @@ static int utmi_phy_power_on(struct tegra_usb_phy *phy)
UTMIP_PLLU_ENABLE_DLY_COUNT(phy->freq->enable_delay);
writel(val, base + UTMIP_PLL_CFG1);
- if (phy->mode == TEGRA_USB_PHY_MODE_DEVICE) {
+ if (phy->mode == USB_DR_MODE_PERIPHERAL) {
val = readl(base + USB_SUSP_CTRL);
val &= ~(USB_WAKE_ON_CNNT_EN_DEV | USB_WAKE_ON_DISCON_EN_DEV);
writel(val, base + USB_SUSP_CTRL);
@@ -412,7 +412,7 @@ static int utmi_phy_power_on(struct tegra_usb_phy *phy)
if (phy->is_legacy_phy) {
val = readl(base + UTMIP_SPARE_CFG0);
- if (phy->mode == TEGRA_USB_PHY_MODE_DEVICE)
+ if (phy->mode == USB_DR_MODE_PERIPHERAL)
val &= ~FUSE_SETUP_SEL;
else
val |= FUSE_SETUP_SEL;
@@ -453,7 +453,7 @@ static int utmi_phy_power_off(struct tegra_usb_phy *phy)
utmi_phy_clk_disable(phy);
- if (phy->mode == TEGRA_USB_PHY_MODE_DEVICE) {
+ if (phy->mode == USB_DR_MODE_PERIPHERAL) {
val = readl(base + USB_SUSP_CTRL);
val &= ~USB_WAKEUP_DEBOUNCE_COUNT(~0);
val |= USB_WAKE_ON_CNNT_EN_DEV | USB_WAKEUP_DEBOUNCE_COUNT(5);
@@ -906,15 +906,11 @@ static int tegra_usb_phy_probe(struct platform_device
*pdev)
return -EINVAL;
}
- err = of_property_match_string(np, "dr_mode", "otg");
- if (err < 0) {
- err = of_property_match_string(np, "dr_mode", "peripheral");
- if (err < 0)
- tegra_phy->mode = TEGRA_USB_PHY_MODE_HOST;
- else
- tegra_phy->mode = TEGRA_USB_PHY_MODE_DEVICE;
- } else
- tegra_phy->mode = TEGRA_USB_PHY_MODE_OTG;
+ tegra_phy->mode = of_usb_get_dr_mode(np);
+ if (tegra_phy->mode == USB_DR_MODE_UNKNOWN) {
+ dev_err(&pdev->dev, "dr_mode is invalid\n");
+ return -EINVAL;
+ }
/* On some boards, the VBUS regulator doesn't need to be controlled */
if (of_find_property(np, "vbus-supply", NULL)) {
diff --git a/include/linux/usb/tegra_usb_phy.h
b/include/linux/usb/tegra_usb_phy.h
index a095c98..d3db274 100644
--- a/include/linux/usb/tegra_usb_phy.h
+++ b/include/linux/usb/tegra_usb_phy.h
@@ -34,12 +34,6 @@ enum tegra_usb_phy_port_speed {
TEGRA_USB_PHY_PORT_SPEED_HIGH,
};
-enum tegra_usb_phy_mode {
- TEGRA_USB_PHY_MODE_DEVICE,
- TEGRA_USB_PHY_MODE_HOST,
- TEGRA_USB_PHY_MODE_OTG,
-};
-
struct tegra_xtal_freq;
struct tegra_usb_phy {
@@ -51,7 +45,7 @@ struct tegra_usb_phy {
struct clk *pll_u;
struct clk *pad_clk;
struct regulator *vbus;
- enum tegra_usb_phy_mode mode;
+ enum usb_dr_mode mode;
void *config;
struct usb_phy *ulpi;
struct usb_phy u_phy;
--
1.8.1.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 4/9] ARM: tegra: Remove USB platform data
USB-related platform data is not used anymore in the Tegra USB drivers,
so remove all of it.
Signed-off-by: Tuomas Tynkkynen
---
arch/arm/mach-tegra/tegra.c | 38 +
include/linux/platform_data/tegra_usb.h | 32 ---
include/linux/usb/tegra_usb_phy.h | 5 -
3 files changed, 1 insertion(+), 74 deletions(-)
delete mode 100644 include/linux/platform_data/tegra_usb.h
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index 0d1e412..fc97cfd 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -29,7 +29,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -46,40 +45,6 @@
#include "fuse.h"
#include "iomap.h"
-static struct tegra_ehci_platform_data tegra_ehci1_pdata = {
- .operating_mode = TEGRA_USB_OTG,
- .power_down_on_bus_suspend = 1,
- .vbus_gpio = -1,
-};
-
-static struct tegra_ulpi_config tegra_ehci2_ulpi_phy_config = {
- .reset_gpio = -1,
- .clk = "cdev2",
-};
-
-static struct tegra_ehci_platform_data tegra_ehci2_pdata = {
- .phy_config = &tegra_ehci2_ulpi_phy_config,
- .operating_mode = TEGRA_USB_HOST,
- .power_down_on_bus_suspend = 1,
- .vbus_gpio = -1,
-};
-
-static struct tegra_ehci_platform_data tegra_ehci3_pdata = {
- .operating_mode = TEGRA_USB_HOST,
- .power_down_on_bus_suspend = 1,
- .vbus_gpio = -1,
-};
-
-static struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
- OF_DEV_AUXDATA("nvidia,tegra20-ehci", 0xC500, "tegra-ehci.0",
- &tegra_ehci1_pdata),
- OF_DEV_AUXDATA("nvidia,tegra20-ehci", 0xC5004000, "tegra-ehci.1",
- &tegra_ehci2_pdata),
- OF_DEV_AUXDATA("nvidia,tegra20-ehci", 0xC5008000, "tegra-ehci.2",
- &tegra_ehci3_pdata),
- {}
-};
-
static void __init tegra_dt_init(void)
{
struct soc_device_attribute *soc_dev_attr;
@@ -112,8 +77,7 @@ static void __init tegra_dt_init(void)
* devices
*/
out:
- of_platform_populate(NULL, of_default_bus_match_table,
- tegra20_auxdata_lookup, parent);
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, parent);
}
static void __init trimslice_init(void)
diff --git a/include/linux/platform_data/tegra_usb.h
b/include/linux/platform_data/tegra_usb.h
deleted file mode 100644
index 66c673f..000
--- a/include/linux/platform_data/tegra_usb.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * Copyright (C) 2010 Google, Inc.
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * 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.
- *
- */
-
-#ifndef _TEGRA_USB_H_
-#define _TEGRA_USB_H_
-
-enum tegra_usb_operating_modes {
- TEGRA_USB_DEVICE,
- TEGRA_USB_HOST,
- TEGRA_USB_OTG,
-};
-
-struct tegra_ehci_platform_data {
- enum tegra_usb_operating_modes operating_mode;
- /* power down the phy on bus suspend */
- int power_down_on_bus_suspend;
- void *phy_config;
- int vbus_gpio;
-};
-
-#endif /* _TEGRA_USB_H_ */
diff --git a/include/linux/usb/tegra_usb_phy.h
b/include/linux/usb/tegra_usb_phy.h
index c2bc710..8474153 100644
--- a/include/linux/usb/tegra_usb_phy.h
+++ b/include/linux/usb/tegra_usb_phy.h
@@ -28,11 +28,6 @@ struct tegra_utmip_config {
u8 xcvr_lsrslew;
};
-struct tegra_ulpi_config {
- int reset_gpio;
- const char *clk;
-};
-
enum tegra_usb_phy_port_speed {
TEGRA_USB_PHY_PORT_SPEED_FULL = 0,
TEGRA_USB_PHY_PORT_SPEED_LOW,
--
1.8.1.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 1/9] usb: phy: tegra: Remove unnecessary 'dev' field
struct usb_phy already has a field for the device pointer, so this
unnecessary field can be removed.
Signed-off-by: Tuomas Tynkkynen
---
drivers/usb/phy/phy-tegra-usb.c | 27 +++
include/linux/usb/tegra_usb_phy.h | 1 -
2 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 1a86da8..ddcac0b 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -211,7 +211,7 @@ static void set_phcd(struct tegra_usb_phy *phy, bool enable)
static int utmip_pad_open(struct tegra_usb_phy *phy)
{
- phy->pad_clk = devm_clk_get(phy->dev, "utmi-pads");
+ phy->pad_clk = devm_clk_get(phy->u_phy.dev, "utmi-pads");
if (IS_ERR(phy->pad_clk)) {
pr_err("%s: can't get utmip pad clock\n", __func__);
return PTR_ERR(phy->pad_clk);
@@ -540,13 +540,15 @@ static int ulpi_phy_power_on(struct tegra_usb_phy *phy)
ret = gpio_direction_output(phy->reset_gpio, 0);
if (ret < 0) {
- dev_err(phy->dev, "gpio %d not set to 0\n", phy->reset_gpio);
+ dev_err(phy->u_phy.dev, "gpio %d not set to 0\n",
+ phy->reset_gpio);
return ret;
}
msleep(5);
ret = gpio_direction_output(phy->reset_gpio, 1);
if (ret < 0) {
- dev_err(phy->dev, "gpio %d not set to 1\n", phy->reset_gpio);
+ dev_err(phy->u_phy.dev, "gpio %d not set to 1\n",
+ phy->reset_gpio);
return ret;
}
@@ -649,29 +651,30 @@ static int ulpi_open(struct tegra_usb_phy *phy)
{
int err;
- phy->clk = devm_clk_get(phy->dev, "ulpi-link");
+ phy->clk = devm_clk_get(phy->u_phy.dev, "ulpi-link");
if (IS_ERR(phy->clk)) {
pr_err("%s: can't get ulpi clock\n", __func__);
return PTR_ERR(phy->clk);
}
- err = devm_gpio_request(phy->dev, phy->reset_gpio, "ulpi_phy_reset_b");
+ err = devm_gpio_request(phy->u_phy.dev, phy->reset_gpio,
+ "ulpi_phy_reset_b");
if (err < 0) {
- dev_err(phy->dev, "request failed for gpio: %d\n",
+ dev_err(phy->u_phy.dev, "request failed for gpio: %d\n",
phy->reset_gpio);
return err;
}
err = gpio_direction_output(phy->reset_gpio, 0);
if (err < 0) {
- dev_err(phy->dev, "gpio %d direction not set to output\n",
+ dev_err(phy->u_phy.dev, "gpio %d direction not set to output\n",
phy->reset_gpio);
return err;
}
phy->ulpi = otg_ulpi_create(&ulpi_viewport_access_ops, 0);
if (!phy->ulpi) {
- dev_err(phy->dev, "otg_ulpi_create returned NULL\n");
+ dev_err(phy->u_phy.dev, "otg_ulpi_create returned NULL\n");
err = -ENOMEM;
return err;
}
@@ -686,7 +689,7 @@ static int tegra_usb_phy_init(struct tegra_usb_phy *phy)
int i;
int err;
- phy->pll_u = devm_clk_get(phy->dev, "pll_u");
+ phy->pll_u = devm_clk_get(phy->u_phy.dev, "pll_u");
if (IS_ERR(phy->pll_u)) {
pr_err("Can't get pll_u clock\n");
return PTR_ERR(phy->pll_u);
@@ -712,7 +715,7 @@ static int tegra_usb_phy_init(struct tegra_usb_phy *phy)
if (!IS_ERR(phy->vbus)) {
err = regulator_enable(phy->vbus);
if (err) {
- dev_err(phy->dev,
+ dev_err(phy->u_phy.dev,
"failed to enable usb vbus regulator: %d\n",
err);
goto fail;
}
@@ -919,7 +922,7 @@ static int tegra_usb_phy_probe(struct platform_device *pdev)
tegra_phy->vbus = ERR_PTR(-ENODEV);
}
- tegra_phy->dev = &pdev->dev;
+ tegra_phy->u_phy.dev = &pdev->dev;
err = tegra_usb_phy_init(tegra_phy);
if (err < 0)
return err;
@@ -952,7 +955,7 @@ static int tegra_usb_phy_match(struct device *dev, void
*data)
struct tegra_usb_phy *tegra_phy = dev_get_drvdata(dev);
struct device_node *dn = data;
- return (tegra_phy->dev->of_node == dn) ? 1 : 0;
+ return (tegra_phy->u_phy.dev->of_node == dn) ? 1 : 0;
}
struct usb_phy *tegra_usb_get_phy(struct device_node *dn)
diff --git a/include/linux/usb/tegra_usb_phy.h
b/include/linux/usb/tegra_usb_phy.h
index 2b5fa94..c2bc710 100644
--- a/include/linux/usb/tegra_usb_phy.h
+++ b/include/linux/usb/tegra_usb_phy.h
@@ -60,7 +60,6 @@ struct tegra_usb_phy {
void *config;
struct usb_phy *ulpi;
struct usb_phy u_phy;
- struct device *dev;
bool is_legacy_phy;
bool is_ulpi_phy;
int reset_gpio;
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
[PATCH 0/9] Tegra USB cleanup series
Hi, Here's a few cleanup patches for the Tegra USB drivers, to be applied on top of Mikko's two patch sets. It mostly deals with removing all usage of platform data and using standard helpers and enums instead of Tegra-specific ones. Tuomas Tynkkynen (9): usb: phy: tegra: Remove unnecessary 'dev' field usb: host: tegra: Remove leftover code usb: tegra: host: Remove references to plat data ARM: tegra: Remove USB platform data usb: phy: tegra: Register as an USB PHY. usb: host: tegra: Locate a PHY via standard API usb: phy: tegra: Remove custom PHY locating APIs usb: phy: tegra: Use DT helpers for phy_type usb: phy: tegra: Use DT helpers for dr_mode arch/arm/mach-tegra/tegra.c | 38 + drivers/usb/host/ehci-tegra.c | 37 +++-- drivers/usb/phy/phy-tegra-usb.c | 96 - include/linux/platform_data/tegra_usb.h | 32 --- include/linux/usb/tegra_usb_phy.h | 16 +- 5 files changed, 53 insertions(+), 166 deletions(-) delete mode 100644 include/linux/platform_data/tegra_usb.h -- 1.8.1.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: [PATCHv2 4/8] clocksource: sun4i: Fix the next event code
On Fri, 28 Jun 2013, Maxime Ripard wrote:
> On Fri, Jun 28, 2013 at 10:13:08PM +0200, Thomas Gleixner wrote:
> > On Fri, 28 Jun 2013, Maxime Ripard wrote:
> > > @@ -61,9 +62,14 @@ static void sun4i_clkevt_mode(enum clock_event_mode
> > > mode,
> > > static int sun4i_clkevt_next_event(unsigned long evt,
> > > struct clock_event_device *unused)
> > > {
> > > - u32 u = readl(timer_base + TIMER_CTL_REG(0));
> > > - writel(evt, timer_base + TIMER_CNTVAL_REG(0));
> > > - writel(u | TIMER_CTL_ENABLE | TIMER_CTL_AUTORELOAD,
> > > + u32 val = readl(timer_base + TIMER_CTL_REG(0));
> > > + writel(val & ~TIMER_CTL_ENABLE, timer_base + TIMER_CTL_REG(0));
> > > + udelay(1);
> >
> > That udelay() is more than suspicious. Is there really no other way to
> > deal with that hardware?
> >
> > If no, you really need to put a proper explanation for that into the code.
>
> The datasheet states that you have to wait for two ticks of the timer
> clock source (in that case, 24MHz, which makes it around 80-85ns) before
> you can actually enable it back.
>
> I didn't came up with a better solution.
80-85ns is definitely way less than 1us.
Why not reading the counter register and wait for 2 or 3 cycles to
elapse instead of wasting a full microsecond evertime ?
Thanks,
tglx
--
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/
