* [PATCH 2/8] kernel/signal.c: fix typos and coding style
2011-04-04 21:58 [PATCH 1/8] Documentation: update kmemleak arch. info Randy Dunlap
@ 2011-04-04 21:59 ` Randy Dunlap
2011-04-04 22:00 ` [PATCH 3/8] kernel/signal.c: add kernel-doc notation to syscalls Randy Dunlap
` (5 subsequent siblings)
6 siblings, 0 replies; 14+ messages in thread
From: Randy Dunlap @ 2011-04-04 21:59 UTC (permalink / raw)
To: lkml; +Cc: torvalds
From: Randy Dunlap <randy.dunlap@oracle.com>
General coding style and comment fixes; no code changes:
- Use multi-line-comment coding style.
- Put some function signatures completely on one line.
- Hyphenate some words.
- Spell Posix as POSIX.
- Correct typos & spellos in some comments.
- Drop trailing whitespace.
- End sentences with periods.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
kernel/signal.c | 90 ++++++++++++++++++++++++----------------------
1 file changed, 48 insertions(+), 42 deletions(-)
--- linux-2.6.38-git18.orig/kernel/signal.c
+++ linux-2.6.38-git18/kernel/signal.c
@@ -226,7 +226,7 @@ static inline void print_dropped_signal(
/*
* allocate a new signal queue record
* - this may be called without locks if and only if t == current, otherwise an
- * appopriate lock must be held to stop the target task from exiting
+ * appropriate lock must be held to stop the target task from exiting
*/
static struct sigqueue *
__sigqueue_alloc(int sig, struct task_struct *t, gfp_t flags, int override_rlimit)
@@ -375,15 +375,15 @@ int unhandled_signal(struct task_struct
return !tracehook_consider_fatal_signal(tsk, sig);
}
-
-/* Notify the system that a driver wants to block all signals for this
+/*
+ * Notify the system that a driver wants to block all signals for this
* process, and wants to be notified if any signals at all were to be
* sent/acted upon. If the notifier routine returns non-zero, then the
* signal will be acted upon after all. If the notifier routine returns 0,
* then then signal will be blocked. Only one block per process is
* allowed. priv is a pointer to private data that the notifier routine
- * can use to determine if the signal should be blocked or not. */
-
+ * can use to determine if the signal should be blocked or not.
+ */
void
block_all_signals(int (*notifier)(void *priv), void *priv, sigset_t *mask)
{
@@ -434,9 +434,10 @@ still_pending:
copy_siginfo(info, &first->info);
__sigqueue_free(first);
} else {
- /* Ok, it wasn't in the queue. This must be
- a fast-pathed signal or we must have been
- out of queue space. So zero out the info.
+ /*
+ * Ok, it wasn't in the queue. This must be
+ * a fast-pathed signal or we must have been
+ * out of queue space. So zero out the info.
*/
info->si_signo = sig;
info->si_errno = 0;
@@ -468,7 +469,7 @@ static int __dequeue_signal(struct sigpe
}
/*
- * Dequeue a signal and return the element to the caller, which is
+ * Dequeue a signal and return the element to the caller, which is
* expected to free it.
*
* All callers have to hold the siglock.
@@ -490,7 +491,7 @@ int dequeue_signal(struct task_struct *t
* itimers are process shared and we restart periodic
* itimers in the signal delivery path to prevent DoS
* attacks in the high resolution timer case. This is
- * compliant with the old way of self restarting
+ * compliant with the old way of self-restarting
* itimers, as the SIGALRM is a legacy signal and only
* queued once. Changing the restart behaviour to
* restart the timer in the signal dequeue path is
@@ -923,14 +924,15 @@ static int __send_signal(int sig, struct
if (info == SEND_SIG_FORCED)
goto out_set;
- /* Real-time signals must be queued if sent by sigqueue, or
- some other real-time mechanism. It is implementation
- defined whether kill() does so. We attempt to do so, on
- the principle of least surprise, but since kill is not
- allowed to fail with EAGAIN when low on memory we just
- make sure at least one signal gets delivered and don't
- pass on the info struct. */
-
+ /*
+ * Real-time signals must be queued if sent by sigqueue, or
+ * some other real-time mechanism. It is implementation
+ * defined whether kill() does so. We attempt to do so, on
+ * the principle of least surprise, but since kill is not
+ * allowed to fail with EAGAIN when low on memory we just
+ * make sure at least one signal gets delivered and don't
+ * pass on the info struct.
+ */
if (sig < SIGRTMIN)
override_rlimit = (is_si_special(info) || info->si_code >= 0);
else
@@ -1201,8 +1203,7 @@ retry:
return error;
}
-int
-kill_proc_info(int sig, struct siginfo *info, pid_t pid)
+int kill_proc_info(int sig, struct siginfo *info, pid_t pid)
{
int error;
rcu_read_lock();
@@ -1299,8 +1300,7 @@ static int kill_something_info(int sig,
* These are for backward compatibility with the rest of the kernel source.
*/
-int
-send_sig_info(int sig, struct siginfo *info, struct task_struct *p)
+int send_sig_info(int sig, struct siginfo *info, struct task_struct *p)
{
/*
* Make sure legacy kernel users don't send in bad values
@@ -1368,7 +1368,7 @@ EXPORT_SYMBOL(kill_pid);
* These functions support sending signals using preallocated sigqueue
* structures. This is needed "because realtime applications cannot
* afford to lose notifications of asynchronous events, like timer
- * expirations or I/O completions". In the case of Posix Timers
+ * expirations or I/O completions". In the case of POSIX Timers
* we allocate the sigqueue structure from the timer_create. If this
* allocation fails we are able to report the failure to the application
* with an EAGAIN error.
@@ -1553,7 +1553,7 @@ static void do_notify_parent_cldstop(str
info.si_signo = SIGCHLD;
info.si_errno = 0;
/*
- * see comment in do_notify_parent() abot the following 3 lines
+ * see comment in do_notify_parent() about the following 4 lines
*/
rcu_read_lock();
info.si_pid = task_pid_nr_ns(tsk, parent->nsproxy->pid_ns);
@@ -1611,7 +1611,7 @@ static inline int may_ptrace_stop(void)
}
/*
- * Return nonzero if there is a SIGKILL that should be waking us up.
+ * Return non-zero if there is a SIGKILL that should be waking us up.
* Called with the siglock held.
*/
static int sigkill_pending(struct task_struct *tsk)
@@ -1735,7 +1735,7 @@ void ptrace_notify(int exit_code)
/*
* This performs the stopping for SIGSTOP and other stop signals.
* We have to stop all threads in the thread group.
- * Returns nonzero if we've actually stopped and released the siglock.
+ * Returns non-zero if we've actually stopped and released the siglock.
* Returns zero if we didn't stop and still hold the siglock.
*/
static int do_signal_stop(int signr)
@@ -1823,10 +1823,12 @@ static int ptrace_signal(int signr, sigi
current->exit_code = 0;
- /* Update the siginfo structure if the signal has
- changed. If the debugger wanted something
- specific in the siginfo structure then it should
- have updated *info via PTRACE_SETSIGINFO. */
+ /*
+ * Update the siginfo structure if the signal has
+ * changed. If the debugger wanted something
+ * specific in the siginfo structure then it should
+ * have updated *info via PTRACE_SETSIGINFO.
+ */
if (signr != info->si_signo) {
info->si_signo = signr;
info->si_errno = 0;
@@ -2034,7 +2036,8 @@ void exit_signals(struct task_struct *ts
if (!signal_pending(tsk))
goto out;
- /* It could be that __group_complete_signal() choose us to
+ /*
+ * It could be that __group_complete_signal() choose us to
* notify about group-wide signal. Another thread should be
* woken now to take the signal since we will not.
*/
@@ -2183,7 +2186,7 @@ long do_sigpending(void __user *set, uns
out:
return error;
-}
+}
SYSCALL_DEFINE2(rt_sigpending, sigset_t __user *, set, size_t, sigsetsize)
{
@@ -2233,9 +2236,9 @@ int copy_siginfo_to_user(siginfo_t __use
err |= __put_user(from->si_trapno, &to->si_trapno);
#endif
#ifdef BUS_MCEERR_AO
- /*
+ /*
* Other callers might not initialize the si_lsb field,
- * so check explicitely for the right codes here.
+ * so check explicitly for the right codes here.
*/
if (from->si_code == BUS_MCEERR_AR || from->si_code == BUS_MCEERR_AO)
err |= __put_user(from->si_addr_lsb, &to->si_addr_lsb);
@@ -2280,7 +2283,7 @@ SYSCALL_DEFINE4(rt_sigtimedwait, const s
if (copy_from_user(&these, uthese, sizeof(these)))
return -EFAULT;
-
+
/*
* Invert the set of allowed signals to get those we
* want to block.
@@ -2305,9 +2308,11 @@ SYSCALL_DEFINE4(rt_sigtimedwait, const s
+ (ts.tv_sec || ts.tv_nsec));
if (timeout) {
- /* None ready -- temporarily unblock those we're
+ /*
+ * None ready -- temporarily unblock those we're
* interested while we are sleeping in so that we'll
- * be awakened when they arrive. */
+ * be awakened when they arrive.
+ */
current->real_blocked = current->blocked;
sigandsets(¤t->blocked, ¤t->blocked, &these);
recalc_sigpending();
@@ -2553,12 +2558,11 @@ do_sigaltstack (const stack_t __user *us
error = -EINVAL;
/*
- *
- * Note - this code used to test ss_flags incorrectly
+ * Note - this code used to test ss_flags incorrectly:
* old code may have been written using ss_flags==0
* to mean ss_flags==SS_ONSTACK (as this was the only
* way that worked) - this fix preserves that older
- * mechanism
+ * mechanism.
*/
if (ss_flags != SS_DISABLE && ss_flags != SS_ONSTACK && ss_flags != 0)
goto out;
@@ -2600,8 +2604,10 @@ SYSCALL_DEFINE1(sigpending, old_sigset_t
#endif
#ifdef __ARCH_WANT_SYS_SIGPROCMASK
-/* Some platforms have their own version with special arguments others
- support only sys_rt_sigprocmask. */
+/*
+ * Some platforms have their own version with special arguments;
+ * others support only sys_rt_sigprocmask.
+ */
SYSCALL_DEFINE3(sigprocmask, int, how, old_sigset_t __user *, set,
old_sigset_t __user *, oset)
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH 3/8] kernel/signal.c: add kernel-doc notation to syscalls
2011-04-04 21:58 [PATCH 1/8] Documentation: update kmemleak arch. info Randy Dunlap
2011-04-04 21:59 ` [PATCH 2/8] kernel/signal.c: fix typos and coding style Randy Dunlap
@ 2011-04-04 22:00 ` Randy Dunlap
2011-04-05 8:32 ` Matt Fleming
2011-04-04 22:02 ` [PATCH 4/8] Documentation: update panic parameter info Randy Dunlap
` (4 subsequent siblings)
6 siblings, 1 reply; 14+ messages in thread
From: Randy Dunlap @ 2011-04-04 22:00 UTC (permalink / raw)
To: lkml; +Cc: torvalds
From: Randy Dunlap <randy.dunlap@oracle.com>
Add kernel-doc to syscalls in signal.c.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
kernel/signal.c | 65 ++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 63 insertions(+), 2 deletions(-)
--- linux-2.6.38-git18.orig/kernel/signal.c
+++ linux-2.6.38-git18/kernel/signal.c
@@ -2075,6 +2075,9 @@ EXPORT_SYMBOL(unblock_all_signals);
* System call entry points.
*/
+/**
+ * sys_restart_syscall - restart a system call
+ */
SYSCALL_DEFINE0(restart_syscall)
{
struct restart_block *restart = ¤t_thread_info()->restart_block;
@@ -2128,6 +2131,13 @@ int sigprocmask(int how, sigset_t *set,
return error;
}
+/**
+ * sys_rt_sigprocmask - change the list of currently blocked signals
+ * @how: whether to add, remove, or set signals
+ * @set: stores pending signals
+ * @oset: previous value of signal mask if non-null
+ * @sigsetsize: size of sigset_t type
+ */
SYSCALL_DEFINE4(rt_sigprocmask, int, how, sigset_t __user *, set,
sigset_t __user *, oset, size_t, sigsetsize)
{
@@ -2188,6 +2198,12 @@ out:
return error;
}
+/**
+ * sys_rt_sigpending - examine a pending signal that has been raised
+ * while blocked
+ * @set: stores pending signals
+ * @sigsetsize: size of sigset_t type or larger
+ */
SYSCALL_DEFINE2(rt_sigpending, sigset_t __user *, set, size_t, sigsetsize)
{
return do_sigpending(set, sigsetsize);
@@ -2267,6 +2283,14 @@ int copy_siginfo_to_user(siginfo_t __use
#endif
+/**
+ * sys_rt_sigtimedwait - synchronously wait for queued signals specified
+ * in @uthese
+ * @uthese: queued signals to wait for
+ * @uinfo: if non-null, the signal's siginfo is returned here
+ * @uts: upper bound on process time suspension
+ * @sigsetsize: size of sigset_t type
+ */
SYSCALL_DEFINE4(rt_sigtimedwait, const sigset_t __user *, uthese,
siginfo_t __user *, uinfo, const struct timespec __user *, uts,
size_t, sigsetsize)
@@ -2344,6 +2368,11 @@ SYSCALL_DEFINE4(rt_sigtimedwait, const s
return ret;
}
+/**
+ * sys_kill - send a signal to a process
+ * @pid: the PID of the process
+ * @sig: signal to be sent
+ */
SYSCALL_DEFINE2(kill, pid_t, pid, int, sig)
{
struct siginfo info;
@@ -2419,7 +2448,11 @@ SYSCALL_DEFINE3(tgkill, pid_t, tgid, pid
return do_tkill(tgid, pid, sig);
}
-/*
+/**
+ * sys_tkill - send signal to one specific task
+ * @pid: the PID of the task
+ * @sig: signal to be sent
+ *
* Send a signal to only one task, even if it's a CLONE_THREAD task.
*/
SYSCALL_DEFINE2(tkill, pid_t, pid, int, sig)
@@ -2431,6 +2464,12 @@ SYSCALL_DEFINE2(tkill, pid_t, pid, int,
return do_tkill(0, pid, sig);
}
+/**
+ * sys_rt_sigqueueinfo - send signal information to a signal
+ * @pid: the PID of the thread
+ * @sig: signal to be sent
+ * @uinfo: signal info to be sent
+ */
SYSCALL_DEFINE3(rt_sigqueueinfo, pid_t, pid, int, sig,
siginfo_t __user *, uinfo)
{
@@ -2596,6 +2635,10 @@ out:
#ifdef __ARCH_WANT_SYS_SIGPENDING
+/**
+ * sys_sigpending - examine pending signals
+ * @set: where mask of pending signal is returned
+ */
SYSCALL_DEFINE1(sigpending, old_sigset_t __user *, set)
{
return do_sigpending(set, sizeof(*set));
@@ -2604,7 +2647,12 @@ SYSCALL_DEFINE1(sigpending, old_sigset_t
#endif
#ifdef __ARCH_WANT_SYS_SIGPROCMASK
-/*
+/**
+ * sys_sigprocmask - examine and change blocked signals
+ * @how: whether to add, remove, or set signals
+ * @set: signals to add or remove (if non-null)
+ * @oset: previous value of signal mask if non-null
+ *
* Some platforms have their own version with special arguments;
* others support only sys_rt_sigprocmask.
*/
@@ -2660,6 +2708,13 @@ out:
#endif /* __ARCH_WANT_SYS_SIGPROCMASK */
#ifdef __ARCH_WANT_SYS_RT_SIGACTION
+/**
+ * sys_rt_sigaction - alter an action taken by a process
+ * @sig: signal to be sent
+ * @act: the thread group ID of the thread
+ * @oact: the PID of the thread
+ * @sigsetsize: size of sigset_t type
+ */
SYSCALL_DEFINE4(rt_sigaction, int, sig,
const struct sigaction __user *, act,
struct sigaction __user *, oact,
@@ -2746,6 +2801,12 @@ SYSCALL_DEFINE0(pause)
#endif
#ifdef __ARCH_WANT_SYS_RT_SIGSUSPEND
+/**
+ * sys_rt_sigsuspend - replace the signal mask for a value with the
+ * @unewset value until a signal is received
+ * @unewset: new signal mask value
+ * @sigsetsize: size of sigset_t type
+ */
SYSCALL_DEFINE2(rt_sigsuspend, sigset_t __user *, unewset, size_t, sigsetsize)
{
sigset_t newset;
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 3/8] kernel/signal.c: add kernel-doc notation to syscalls
2011-04-04 22:00 ` [PATCH 3/8] kernel/signal.c: add kernel-doc notation to syscalls Randy Dunlap
@ 2011-04-05 8:32 ` Matt Fleming
2011-04-08 17:41 ` Randy Dunlap
2011-04-08 17:53 ` [PATCH] signal.c: fix erroneous syscall kernel-doc Randy Dunlap
0 siblings, 2 replies; 14+ messages in thread
From: Matt Fleming @ 2011-04-05 8:32 UTC (permalink / raw)
To: Randy Dunlap; +Cc: lkml, torvalds
On Mon, 4 Apr 2011 15:00:26 -0700
Randy Dunlap <rdunlap@xenotime.net> wrote:
> @@ -2660,6 +2708,13 @@ out:
> #endif /* __ARCH_WANT_SYS_SIGPROCMASK */
>
> #ifdef __ARCH_WANT_SYS_RT_SIGACTION
> +/**
> + * sys_rt_sigaction - alter an action taken by a process
> + * @sig: signal to be sent
> + * @act: the thread group ID of the thread
> + * @oact: the PID of the thread
> + * @sigsetsize: size of sigset_t type
> + */
> SYSCALL_DEFINE4(rt_sigaction, int, sig,
> const struct sigaction __user *, act,
> struct sigaction __user *, oact,
This isn't right. @act and @oct are the new and old actions for @sig.
--
Matt Fleming, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 3/8] kernel/signal.c: add kernel-doc notation to syscalls
2011-04-05 8:32 ` Matt Fleming
@ 2011-04-08 17:41 ` Randy Dunlap
2011-04-08 17:53 ` [PATCH] signal.c: fix erroneous syscall kernel-doc Randy Dunlap
1 sibling, 0 replies; 14+ messages in thread
From: Randy Dunlap @ 2011-04-08 17:41 UTC (permalink / raw)
To: Matt Fleming; +Cc: lkml, torvalds
On Tue, 5 Apr 2011 09:32:14 +0100 Matt Fleming wrote:
> On Mon, 4 Apr 2011 15:00:26 -0700
> Randy Dunlap <rdunlap@xenotime.net> wrote:
>
> > @@ -2660,6 +2708,13 @@ out:
> > #endif /* __ARCH_WANT_SYS_SIGPROCMASK */
> >
> > #ifdef __ARCH_WANT_SYS_RT_SIGACTION
> > +/**
> > + * sys_rt_sigaction - alter an action taken by a process
> > + * @sig: signal to be sent
> > + * @act: the thread group ID of the thread
> > + * @oact: the PID of the thread
> > + * @sigsetsize: size of sigset_t type
> > + */
> > SYSCALL_DEFINE4(rt_sigaction, int, sig,
> > const struct sigaction __user *, act,
> > struct sigaction __user *, oact,
>
> This isn't right. @act and @oct are the new and old actions for @sig.
Thanks. I don't know how I did that.
I'll send a correction for it.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] signal.c: fix erroneous syscall kernel-doc
2011-04-05 8:32 ` Matt Fleming
2011-04-08 17:41 ` Randy Dunlap
@ 2011-04-08 17:53 ` Randy Dunlap
2011-04-08 20:13 ` Matt Fleming
1 sibling, 1 reply; 14+ messages in thread
From: Randy Dunlap @ 2011-04-08 17:53 UTC (permalink / raw)
To: Matt Fleming; +Cc: lkml, torvalds
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix erroneous syscall kernel-doc comments in kernel/signal.c.
Reported-by: Matt Fleming <matt@console-pimps.org>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
kernel/signal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.39-rc2.orig/kernel/signal.c
+++ linux-2.6.39-rc2/kernel/signal.c
@@ -2711,8 +2711,8 @@ out:
/**
* sys_rt_sigaction - alter an action taken by a process
* @sig: signal to be sent
- * @act: the thread group ID of the thread
- * @oact: the PID of the thread
+ * @act: new sigaction
+ * @oact: used to save the previous sigaction
* @sigsetsize: size of sigset_t type
*/
SYSCALL_DEFINE4(rt_sigaction, int, sig,
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 4/8] Documentation: update panic parameter info
2011-04-04 21:58 [PATCH 1/8] Documentation: update kmemleak arch. info Randy Dunlap
2011-04-04 21:59 ` [PATCH 2/8] kernel/signal.c: fix typos and coding style Randy Dunlap
2011-04-04 22:00 ` [PATCH 3/8] kernel/signal.c: add kernel-doc notation to syscalls Randy Dunlap
@ 2011-04-04 22:02 ` Randy Dunlap
2011-04-04 22:04 ` [PATCH 5/8] Documentation: fix minor typos/spelling Randy Dunlap
` (3 subsequent siblings)
6 siblings, 0 replies; 14+ messages in thread
From: Randy Dunlap @ 2011-04-04 22:02 UTC (permalink / raw)
To: lkml; +Cc: torvalds, Jesper Juhl
From: Randy Dunlap <randy.dunlap@oracle.com>
Add a little more info for some of the panic-related kernel parameters.
Fix "oops=panic" to fit in 80 columns.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Reviewed-by: Jesper Juhl <jj@chaosbits.net>
---
Documentation/kernel-parameters.txt | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- linux-2.6.38-git18.orig/Documentation/kernel-parameters.txt
+++ linux-2.6.38-git18/Documentation/kernel-parameters.txt
@@ -1832,15 +1832,17 @@ bytes respectively. Such letter suffixes
perfmon on Intel CPUs instead of the
CPU specific event set.
- oops=panic Always panic on oopses. Default is to just kill the process,
- but there is a small probability of deadlocking the machine.
+ oops=panic Always panic on oopses. Default is to just kill the
+ process, but there is a small probability of
+ deadlocking the machine.
This will also cause panics on machine check exceptions.
Useful together with panic=30 to trigger a reboot.
OSS [HW,OSS]
See Documentation/sound/oss/oss-parameters.txt
- panic= [KNL] Kernel behaviour on panic
+ panic= [KNL] Kernel behaviour on panic: delay <timeout>
+ seconds before rebooting
Format: <timeout>
parkbd.port= [HW] Parallel port number the keyboard adapter is
@@ -2343,6 +2345,7 @@ bytes respectively. Such letter suffixes
softlockup_panic=
[KNL] Should the soft-lockup detector generate panics.
+ Format: <integer>
sonypi.*= [HW] Sony Programmable I/O Control Device driver
See Documentation/sonypi.txt
@@ -2529,8 +2532,7 @@ bytes respectively. Such letter suffixes
reported either.
unknown_nmi_panic
- [X86]
- Set unknown_nmi_panic=1 early on boot.
+ [X86] Cause panic on unknown NMI.
usbcore.autosuspend=
[USB] The autosuspend time delay (in seconds) used
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH 5/8] Documentation: fix minor typos/spelling
2011-04-04 21:58 [PATCH 1/8] Documentation: update kmemleak arch. info Randy Dunlap
` (2 preceding siblings ...)
2011-04-04 22:02 ` [PATCH 4/8] Documentation: update panic parameter info Randy Dunlap
@ 2011-04-04 22:04 ` Randy Dunlap
2011-04-04 22:06 ` [PATCH 6/8] kemleak-test: build as module only Randy Dunlap
` (2 subsequent siblings)
6 siblings, 0 replies; 14+ messages in thread
From: Randy Dunlap @ 2011-04-04 22:04 UTC (permalink / raw)
To: lkml, Sylvestre Ledru; +Cc: torvalds, gregkh, Benjamin Herrenschmidt
From: Sylvestre Ledru <sylvestre.ledru@scilab.org>
Fix some minor typos:
* informations => information
* there own => their own
* these => this
Signed-off-by: Sylvestre Ledru <sylvestre.ledru@scilab.org>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
Documentation/ABI/testing/sysfs-driver-hid-roccat-kone | 2 +-
Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus | 8 ++++----
Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus | 8 ++++----
Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra | 8 ++++----
Documentation/ABI/testing/sysfs-platform-asus-laptop | 2 +-
Documentation/devicetree/booting-without-of.txt | 6 +++---
Documentation/dvb/udev.txt | 2 +-
Documentation/edac.txt | 2 +-
Documentation/kernel-parameters.txt | 4 ++--
Documentation/laptops/asus-laptop.txt | 4 ++--
Documentation/networking/batman-adv.txt | 2 +-
Documentation/s390/Debugging390.txt | 2 +-
Documentation/scsi/sym53c8xx_2.txt | 2 +-
Documentation/sound/alsa/ALSA-Configuration.txt | 2 +-
Documentation/sound/oss/AudioExcelDSP16 | 6 +++---
Documentation/sound/oss/README.ymfsb | 2 +-
Documentation/video4linux/bttv/Insmod-options | 2 +-
Documentation/video4linux/bttv/Sound-FAQ | 2 +-
Documentation/video4linux/et61x251.txt | 4 ++--
Documentation/video4linux/sn9c102.txt | 4 ++--
Documentation/video4linux/w9968cf.txt | 2 +-
Documentation/video4linux/zc0301.txt | 6 +++---
arch/powerpc/mm/tlb_low_64e.S | 2 +-
arch/powerpc/platforms/Kconfig | 2 +-
24 files changed, 43 insertions(+), 43 deletions(-)
--- linux-2.6.38-git18.orig/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone
+++ linux-2.6.38-git18/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone
@@ -40,7 +40,7 @@ What: /sys/bus/usb/devices/<busnum>-<de
Date: March 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
- press of a button. A profile holds informations like button
+ press of a button. A profile holds information like button
mappings, sensitivity, the colors of the 5 leds and light
effects.
When read, these files return the respective profile. The
--- linux-2.6.38-git18.orig/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
+++ linux-2.6.38-git18/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
@@ -33,7 +33,7 @@ Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
- profile_buttons holds informations about button layout.
+ profile_buttons holds information about button layout.
When written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 77 bytes long.
The mouse will reject invalid data.
@@ -47,7 +47,7 @@ Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
- profile_buttons holds informations about button layout.
+ profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 77 bytes in size.
This file is readonly.
@@ -58,7 +58,7 @@ Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
- profile_settings holds informations like resolution, sensitivity
+ profile_settings holds information like resolution, sensitivity
and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 43 bytes long.
@@ -73,7 +73,7 @@ Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
- profile_settings holds informations like resolution, sensitivity
+ profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 43 bytes in size.
--- linux-2.6.38-git18.orig/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus
+++ linux-2.6.38-git18/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus
@@ -52,7 +52,7 @@ Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
- profile_buttons holds informations about button layout.
+ profile_buttons holds information about button layout.
When written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 23 bytes long.
The mouse will reject invalid data.
@@ -66,7 +66,7 @@ Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
- profile_buttons holds informations about button layout.
+ profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 23 bytes in size.
This file is readonly.
@@ -77,7 +77,7 @@ Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
- profile_settings holds informations like resolution, sensitivity
+ profile_settings holds information like resolution, sensitivity
and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 16 bytes long.
@@ -92,7 +92,7 @@ Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
- profile_settings holds informations like resolution, sensitivity
+ profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 16 bytes in size.
--- linux-2.6.38-git18.orig/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra
+++ linux-2.6.38-git18/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra
@@ -39,7 +39,7 @@ Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
- profile_settings holds informations like resolution, sensitivity
+ profile_settings holds information like resolution, sensitivity
and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 13 bytes long.
@@ -54,7 +54,7 @@ Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
- profile_settings holds informations like resolution, sensitivity
+ profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 13 bytes in size.
@@ -66,7 +66,7 @@ Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
- profile_buttons holds informations about button layout.
+ profile_buttons holds information about button layout.
When written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 19 bytes long.
The mouse will reject invalid data.
@@ -80,7 +80,7 @@ Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
- profile_buttons holds informations about button layout.
+ profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 19 bytes in size.
This file is readonly.
--- linux-2.6.38-git18.orig/Documentation/ABI/testing/sysfs-platform-asus-laptop
+++ linux-2.6.38-git18/Documentation/ABI/testing/sysfs-platform-asus-laptop
@@ -27,7 +27,7 @@ KernelVersion: 2.6.20
Contact: "Corentin Chary" <corentincj@iksaif.net>
Description:
Some models like the W1N have a LED display that can be
- used to display several informations.
+ used to display several items of information.
To control the LED display, use the following :
echo 0x0T000DDD > /sys/devices/platform/asus_laptop/
where T control the 3 letters display, and DDD the 3 digits display.
--- linux-2.6.38-git18.orig/Documentation/devicetree/booting-without-of.txt
+++ linux-2.6.38-git18/Documentation/devicetree/booting-without-of.txt
@@ -138,7 +138,7 @@ and properties to be present. This will
section III, but, for example, the kernel does not require you to
create a node for every PCI device in the system. It is a requirement
to have a node for PCI host bridges in order to provide interrupt
-routing informations and memory/IO ranges, among others. It is also
+routing information and memory/IO ranges, among others. It is also
recommended to define nodes for on chip devices and other buses that
don't specifically fit in an existing OF specification. This creates a
great flexibility in the way the kernel can then probe those and match
@@ -385,7 +385,7 @@ struct boot_param_header {
among others, by kexec. If you are on an SMP system, this value
should match the content of the "reg" property of the CPU node in
the device-tree corresponding to the CPU calling the kernel entry
- point (see further chapters for more informations on the required
+ point (see further chapters for more information on the required
device-tree contents)
- size_dt_strings
@@ -553,7 +553,7 @@ looks like in practice.
This tree is almost a minimal tree. It pretty much contains the
minimal set of required nodes and properties to boot a linux kernel;
-that is, some basic model informations at the root, the CPUs, and the
+that is, some basic model information at the root, the CPUs, and the
physical memory layout. It also includes misc information passed
through /chosen, like in this example, the platform type (mandatory)
and the kernel command line arguments (optional).
--- linux-2.6.38-git18.orig/Documentation/dvb/udev.txt
+++ linux-2.6.38-git18/Documentation/dvb/udev.txt
@@ -1,7 +1,7 @@
The DVB subsystem currently registers to the sysfs subsystem using the
"class_simple" interface.
-This means that only the basic informations like module loading parameters
+This means that only the basic information like module loading parameters
are presented through sysfs. Other things that might be interesting are
currently *not* available.
--- linux-2.6.38-git18.orig/Documentation/edac.txt
+++ linux-2.6.38-git18/Documentation/edac.txt
@@ -311,7 +311,7 @@ Total Correctable Errors count attribute
'ce_noinfo_count'
This attribute file displays the number of CEs that
- have occurred wherewith no informations as to which DIMM slot
+ have occurred wherewith no information as to which DIMM slot
is having errors. Memory is handicapped, but operational,
yet no information is available to indicate which slot
the failing memory is in. This count field should be also
--- linux-2.6.38-git18.orig/Documentation/kernel-parameters.txt
+++ linux-2.6.38-git18/Documentation/kernel-parameters.txt
@@ -2478,8 +2478,8 @@ bytes respectively. Such letter suffixes
topology= [S390]
Format: {off | on}
Specify if the kernel should make use of the cpu
- topology informations if the hardware supports these.
- The scheduler will make use of these informations and
+ topology information if the hardware supports this.
+ The scheduler will make use of this information and
e.g. base its process migration decisions on it.
Default is on.
--- linux-2.6.38-git18.orig/Documentation/laptops/asus-laptop.txt
+++ linux-2.6.38-git18/Documentation/laptops/asus-laptop.txt
@@ -61,7 +61,7 @@ Usage
Hotkeys are also reported as input keys (like keyboards) you can check
which key are supported using "xev" under X11.
- You can get informations on the version of your DSDT table by reading the
+ You can get information on the version of your DSDT table by reading the
/sys/devices/platform/asus-laptop/infos entry. If you have a question or a
bug report to do, please include the output of this entry.
@@ -178,7 +178,7 @@ LED display
-----------
Some models like the W1N have a LED display that can be used to display
- several informations.
+ several items of information.
LED display works for the following models:
W1000N
--- linux-2.6.38-git18.orig/Documentation/networking/batman-adv.txt
+++ linux-2.6.38-git18/Documentation/networking/batman-adv.txt
@@ -72,7 +72,7 @@ folder:
# fragmentation gw_sel_class vis_mode
-There is a special folder for debugging informations:
+There is a special folder for debugging information:
# ls /sys/kernel/debug/batman_adv/bat0/
# gateways socket transtable_global vis_data
--- linux-2.6.38-git18.orig/Documentation/s390/Debugging390.txt
+++ linux-2.6.38-git18/Documentation/s390/Debugging390.txt
@@ -2273,7 +2273,7 @@ IP forwarding is on.
There is a lot of useful info in here best found by going in & having a look around,
so I'll take you through some entries I consider important.
-All the processes running on the machine have there own entry defined by
+All the processes running on the machine have their own entry defined by
/proc/<pid>
So lets have a look at the init process
cd /proc/1
--- linux-2.6.38-git18.orig/Documentation/scsi/sym53c8xx_2.txt
+++ linux-2.6.38-git18/Documentation/scsi/sym53c8xx_2.txt
@@ -285,7 +285,7 @@ from the driver.
7. Profiling information
-This driver does not provide profiling informations as did its predecessors.
+This driver does not provide profiling information as did its predecessors.
This feature was not this useful and added complexity to the code.
As the driver code got more complex, I have decided to remove everything
that didn't seem actually useful.
--- linux-2.6.38-git18.orig/Documentation/sound/alsa/ALSA-Configuration.txt
+++ linux-2.6.38-git18/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -2229,7 +2229,7 @@ Proc interfaces (/proc/asound)
/proc/asound/card#/pcm#[cp]/oss
-------------------------------
- String "erase" - erase all additional informations about OSS applications
+ String "erase" - erase all additional information about OSS applications
String "<app_name> <fragments> <fragment_size> [<options>]"
<app_name> - name of application with (higher priority) or without path
--- linux-2.6.38-git18.orig/Documentation/sound/oss/AudioExcelDSP16
+++ linux-2.6.38-git18/Documentation/sound/oss/AudioExcelDSP16
@@ -1,10 +1,10 @@
Driver
------
-Informations about Audio Excel DSP 16 driver can be found in the source
+Information about Audio Excel DSP 16 driver can be found in the source
file aedsp16.c
Please, read the head of the source before using it. It contain useful
-informations.
+information.
Configuration
-------------
@@ -68,7 +68,7 @@ Sound cards supported
This driver supports the SC-6000 and SC-6600 based Gallant's sound card.
It don't support the Audio Excel DSP 16 III (try the SC-6600 code).
I'm working on the III version of the card: if someone have useful
-informations about it, please let me know.
+information about it, please let me know.
For all the non-supported audio cards, you have to boot MS-DOS (or WIN95)
activating the audio card with the MS-DOS device driver, then you have to
<ctrl>-<alt>-<del> and boot Linux.
--- linux-2.6.38-git18.orig/Documentation/sound/oss/README.ymfsb
+++ linux-2.6.38-git18/Documentation/sound/oss/README.ymfsb
@@ -5,7 +5,7 @@ FIRST OF ALL
============
This code references YAMAHA's sample codes and data sheets.
- I respect and thank for all people they made open the informations
+ I respect and thank for all people they made open the information
about YMF7xx cards.
And this codes heavily based on Jeff Garzik <jgarzik@pobox.com>'s
--- linux-2.6.38-git18.orig/Documentation/video4linux/bttv/Insmod-options
+++ linux-2.6.38-git18/Documentation/video4linux/bttv/Insmod-options
@@ -1,5 +1,5 @@
-Note: "modinfo <module>" prints various informations about a kernel
+Note: "modinfo <module>" prints various information about a kernel
module, among them a complete and up-to-date list of insmod options.
This list tends to be outdated because it is updated manually ...
--- linux-2.6.38-git18.orig/Documentation/video4linux/bttv/Sound-FAQ
+++ linux-2.6.38-git18/Documentation/video4linux/bttv/Sound-FAQ
@@ -8,7 +8,7 @@ completely by the bt8xx chip, which is c
sound is handled in slightly different ways on each board.
To handle the grabber boards correctly, there is a array tvcards[] in
-bttv-cards.c, which holds the informations required for each board.
+bttv-cards.c, which holds the information required for each board.
Sound will work only, if the correct entry is used (for video it often
makes no difference). The bttv driver prints a line to the kernel
log, telling which card type is used. Like this one:
--- linux-2.6.38-git18.orig/Documentation/video4linux/et61x251.txt
+++ linux-2.6.38-git18/Documentation/video4linux/et61x251.txt
@@ -191,10 +191,10 @@ Syntax: <n>
Description: Debugging information level, from 0 to 3:
0 = none (use carefully)
1 = critical errors
- 2 = significant informations
+ 2 = significant information
3 = more verbose messages
Level 3 is useful for testing only, when only one device
- is used at the same time. It also shows some more informations
+ is used at the same time. It also shows some more information
about the hardware being detected. This module parameter can be
changed at runtime thanks to the /sys filesystem interface.
Default: 2
--- linux-2.6.38-git18.orig/Documentation/video4linux/sn9c102.txt
+++ linux-2.6.38-git18/Documentation/video4linux/sn9c102.txt
@@ -214,10 +214,10 @@ Syntax: <n>
Description: Debugging information level, from 0 to 3:
0 = none (use carefully)
1 = critical errors
- 2 = significant informations
+ 2 = significant information
3 = more verbose messages
Level 3 is useful for testing only. It also shows some more
- informations about the hardware being detected.
+ information about the hardware being detected.
This parameter can be changed at runtime thanks to the /sys
filesystem interface.
Default: 2
--- linux-2.6.38-git18.orig/Documentation/video4linux/w9968cf.txt
+++ linux-2.6.38-git18/Documentation/video4linux/w9968cf.txt
@@ -413,7 +413,7 @@ Syntax: <n>
Description: Debugging information level, from 0 to 6:
0 = none (use carefully)
1 = critical errors
- 2 = significant informations
+ 2 = significant information
3 = configuration or general messages
4 = warnings
5 = called functions
--- linux-2.6.38-git18.orig/Documentation/video4linux/zc0301.txt
+++ linux-2.6.38-git18/Documentation/video4linux/zc0301.txt
@@ -181,10 +181,10 @@ Syntax: <n>
Description: Debugging information level, from 0 to 3:
0 = none (use carefully)
1 = critical errors
- 2 = significant informations
+ 2 = significant information
3 = more verbose messages
Level 3 is useful for testing only, when only one device
- is used at the same time. It also shows some more informations
+ is used at the same time. It also shows some information
about the hardware being detected. This module parameter can be
changed at runtime thanks to the /sys filesystem interface.
Default: 2
@@ -261,7 +261,7 @@ the fingerprint is: '88E8 F32F 7244 68BA
11. Credits
===========
-- Informations about the chip internals needed to enable the I2C protocol have
+- Information about the chip internals needed to enable the I2C protocol have
been taken from the documentation of the ZC030x Video4Linux1 driver written
by Andrew Birkett <andy@nobugs.org>;
- The initialization values of the ZC0301 controller connected to the PAS202BCB
--- linux-2.6.38-git18.orig/arch/powerpc/mm/tlb_low_64e.S
+++ linux-2.6.38-git18/arch/powerpc/mm/tlb_low_64e.S
@@ -431,7 +431,7 @@ virt_page_table_tlb_miss_fault:
* The thing is, we know that in normal circumstances, this is
* always called as a second level tlb miss for SW load or as a first
* level TLB miss for HW load, so we should be able to peek at the
- * relevant informations in the first exception frame in the PACA.
+ * relevant information in the first exception frame in the PACA.
*
* However, we do need to double check that, because we may just hit
* a stray kernel pointer or a userland attack trying to hit those
--- linux-2.6.38-git18.orig/arch/powerpc/platforms/Kconfig
+++ linux-2.6.38-git18/arch/powerpc/platforms/Kconfig
@@ -46,7 +46,7 @@ config PPC_OF_BOOT_TRAMPOLINE
help
Support from booting from Open Firmware or yaboot using an
Open Firmware client interface. This enables the kernel to
- communicate with open firmware to retrieve system informations
+ communicate with open firmware to retrieve system information
such as the device tree.
In case of doubt, say Y
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH 6/8] kemleak-test: build as module only
2011-04-04 21:58 [PATCH 1/8] Documentation: update kmemleak arch. info Randy Dunlap
` (3 preceding siblings ...)
2011-04-04 22:04 ` [PATCH 5/8] Documentation: fix minor typos/spelling Randy Dunlap
@ 2011-04-04 22:06 ` Randy Dunlap
2011-04-04 22:08 ` [PATCH 7/8] Documentation: consolidate leds files to leds/ subdir Randy Dunlap
2011-04-04 22:10 ` [PATCH 8/8] Documentation: update cgroups info user groups names Randy Dunlap
6 siblings, 0 replies; 14+ messages in thread
From: Randy Dunlap @ 2011-04-04 22:06 UTC (permalink / raw)
To: lkml, Daniel Baluta; +Cc: torvalds, Pekka Enberg, Catalin Marinas
From: Daniel Baluta <dbaluta@ixiacom.com>
mm/kmemleak-test.c is used to provide an example of how kmemleak
tool works.
Memory is leaked at module unload-time, so building the test
in kernel (Y) makes the leaks impossible and the test useless.
Qualify DEBUG_KMEMLEAK_TEST config symbol with "depends on m",
to restrict module-only building.
Signed-off-by: Daniel Baluta <dbaluta@ixiacom.com>
Acked-by: Pekka Enberg <penberg@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
lib/Kconfig.debug | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- linux-2.6.38-git18.orig/lib/Kconfig.debug
+++ linux-2.6.38-git18/lib/Kconfig.debug
@@ -434,11 +434,9 @@ config DEBUG_KMEMLEAK_EARLY_LOG_SIZE
config DEBUG_KMEMLEAK_TEST
tristate "Simple test for the kernel memory leak detector"
- depends on DEBUG_KMEMLEAK
+ depends on DEBUG_KMEMLEAK && m
help
- Say Y or M here to build a test for the kernel memory leak
- detector. This option enables a module that explicitly leaks
- memory.
+ This option enables a module that explicitly leaks memory.
If unsure, say N.
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH 7/8] Documentation: consolidate leds files to leds/ subdir
2011-04-04 21:58 [PATCH 1/8] Documentation: update kmemleak arch. info Randy Dunlap
` (4 preceding siblings ...)
2011-04-04 22:06 ` [PATCH 6/8] kemleak-test: build as module only Randy Dunlap
@ 2011-04-04 22:08 ` Randy Dunlap
2011-04-05 0:54 ` Linus Torvalds
2011-04-04 22:10 ` [PATCH 8/8] Documentation: update cgroups info user groups names Randy Dunlap
6 siblings, 1 reply; 14+ messages in thread
From: Randy Dunlap @ 2011-04-04 22:08 UTC (permalink / raw)
To: lkml, Antonio Ospite, akpm; +Cc: torvalds, Richard Purdie
From: Antonio Ospite <ospite@studenti.unina.it>
leds: move leds-class documentation under the leds/ subdir.
Add also a leds/00-INDEX file describing the files under leds/
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Acked-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
Changes since v2:
- list leds/ dir in Documentation/00-INDEX, not leds/leds-class.txt
- add a leds/00-INDEX file describing the files under leds/
Changes since v1:
- don't use git renames
- Cc Andrew Morton
Thanks,
Antonio Ospite
http://ao2.it
Documentation/00-INDEX | 4 -
Documentation/leds-class.txt | 98 ---------------------------
Documentation/leds-lp3944.txt | 50 -------------
Documentation/leds/00-INDEX | 8 ++
Documentation/leds/leds-class.txt | 98 +++++++++++++++++++++++++++
Documentation/leds/leds-lp3944.txt | 50 +++++++++++++
6 files changed, 158 insertions(+), 150 deletions(-)
create mode 100644 Documentation/leds/00-INDEX
delete mode 100644 Documentation/leds-class.txt
delete mode 100644 Documentation/leds-lp3944.txt
create mode 100644 Documentation/leds/leds-class.txt
create mode 100644 Documentation/leds/leds-lp3944.txt
--- linux-2.6.38-git18.orig/Documentation/00-INDEX
+++ linux-2.6.38-git18/Documentation/00-INDEX
@@ -206,8 +206,8 @@ laptops/
- directory with laptop related info and laptop driver documentation.
ldm.txt
- a brief description of LDM (Windows Dynamic Disks).
-leds-class.txt
- - documents LED handling under Linux.
+leds/
+ - directory with info about LED handling under Linux.
local_ops.txt
- semantics and behavior of local atomic operations.
lockdep-design.txt
--- /dev/null
+++ linux-2.6.38-git18/Documentation/leds/00-INDEX
@@ -0,0 +1,8 @@
+leds-class.txt
+ - documents LED handling under Linux.
+leds-lp3944.txt
+ - notes on how to use the leds-lp3944 driver.
+leds-lp5521.txt
+ - notes on how to use the leds-lp5521 driver.
+leds-lp5523.txt
+ - notes on how to use the leds-lp5523 driver.
--- linux-2.6.38-git18.orig/Documentation/leds-class.txt
+++ /dev/null
@@ -1,98 +0,0 @@
-
-LED handling under Linux
-========================
-
-If you're reading this and thinking about keyboard leds, these are
-handled by the input subsystem and the led class is *not* needed.
-
-In its simplest form, the LED class just allows control of LEDs from
-userspace. LEDs appear in /sys/class/leds/. The maximum brightness of the
-LED is defined in max_brightness file. The brightness file will set the brightness
-of the LED (taking a value 0-max_brightness). Most LEDs don't have hardware
-brightness support so will just be turned on for non-zero brightness settings.
-
-The class also introduces the optional concept of an LED trigger. A trigger
-is a kernel based source of led events. Triggers can either be simple or
-complex. A simple trigger isn't configurable and is designed to slot into
-existing subsystems with minimal additional code. Examples are the ide-disk,
-nand-disk and sharpsl-charge triggers. With led triggers disabled, the code
-optimises away.
-
-Complex triggers whilst available to all LEDs have LED specific
-parameters and work on a per LED basis. The timer trigger is an example.
-The timer trigger will periodically change the LED brightness between
-LED_OFF and the current brightness setting. The "on" and "off" time can
-be specified via /sys/class/leds/<device>/delay_{on,off} in milliseconds.
-You can change the brightness value of a LED independently of the timer
-trigger. However, if you set the brightness value to LED_OFF it will
-also disable the timer trigger.
-
-You can change triggers in a similar manner to the way an IO scheduler
-is chosen (via /sys/class/leds/<device>/trigger). Trigger specific
-parameters can appear in /sys/class/leds/<device> once a given trigger is
-selected.
-
-
-Design Philosophy
-=================
-
-The underlying design philosophy is simplicity. LEDs are simple devices
-and the aim is to keep a small amount of code giving as much functionality
-as possible. Please keep this in mind when suggesting enhancements.
-
-
-LED Device Naming
-=================
-
-Is currently of the form:
-
-"devicename:colour:function"
-
-There have been calls for LED properties such as colour to be exported as
-individual led class attributes. As a solution which doesn't incur as much
-overhead, I suggest these become part of the device name. The naming scheme
-above leaves scope for further attributes should they be needed. If sections
-of the name don't apply, just leave that section blank.
-
-
-Hardware accelerated blink of LEDs
-==================================
-
-Some LEDs can be programmed to blink without any CPU interaction. To
-support this feature, a LED driver can optionally implement the
-blink_set() function (see <linux/leds.h>). To set an LED to blinking,
-however, it is better to use use the API function led_blink_set(),
-as it will check and implement software fallback if necessary.
-
-To turn off blinking again, use the API function led_brightness_set()
-as that will not just set the LED brightness but also stop any software
-timers that may have been required for blinking.
-
-The blink_set() function should choose a user friendly blinking value
-if it is called with *delay_on==0 && *delay_off==0 parameters. In this
-case the driver should give back the chosen value through delay_on and
-delay_off parameters to the leds subsystem.
-
-Setting the brightness to zero with brightness_set() callback function
-should completely turn off the LED and cancel the previously programmed
-hardware blinking function, if any.
-
-
-Known Issues
-============
-
-The LED Trigger core cannot be a module as the simple trigger functions
-would cause nightmare dependency issues. I see this as a minor issue
-compared to the benefits the simple trigger functionality brings. The
-rest of the LED subsystem can be modular.
-
-
-Future Development
-==================
-
-At the moment, a trigger can't be created specifically for a single LED.
-There are a number of cases where a trigger might only be mappable to a
-particular LED (ACPI?). The addition of triggers provided by the LED driver
-should cover this option and be possible to add without breaking the
-current interface.
-
--- linux-2.6.38-git18.orig/Documentation/leds-lp3944.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Kernel driver lp3944
-====================
-
- * National Semiconductor LP3944 Fun-light Chip
- Prefix: 'lp3944'
- Addresses scanned: None (see the Notes section below)
- Datasheet: Publicly available at the National Semiconductor website
- http://www.national.com/pf/LP/LP3944.html
-
-Authors:
- Antonio Ospite <ospite@studenti.unina.it>
-
-
-Description
------------
-The LP3944 is a helper chip that can drive up to 8 leds, with two programmable
-DIM modes; it could even be used as a gpio expander but this driver assumes it
-is used as a led controller.
-
-The DIM modes are used to set _blink_ patterns for leds, the pattern is
-specified supplying two parameters:
- - period: from 0s to 1.6s
- - duty cycle: percentage of the period the led is on, from 0 to 100
-
-Setting a led in DIM0 or DIM1 mode makes it blink according to the pattern.
-See the datasheet for details.
-
-LP3944 can be found on Motorola A910 smartphone, where it drives the rgb
-leds, the camera flash light and the lcds power.
-
-
-Notes
------
-The chip is used mainly in embedded contexts, so this driver expects it is
-registered using the i2c_board_info mechanism.
-
-To register the chip at address 0x60 on adapter 0, set the platform data
-according to include/linux/leds-lp3944.h, set the i2c board info:
-
- static struct i2c_board_info __initdata a910_i2c_board_info[] = {
- {
- I2C_BOARD_INFO("lp3944", 0x60),
- .platform_data = &a910_lp3944_leds,
- },
- };
-
-and register it in the platform init function
-
- i2c_register_board_info(0, a910_i2c_board_info,
- ARRAY_SIZE(a910_i2c_board_info));
--- /dev/null
+++ linux-2.6.38-git18/Documentation/leds/leds-class.txt
@@ -0,0 +1,98 @@
+
+LED handling under Linux
+========================
+
+If you're reading this and thinking about keyboard leds, these are
+handled by the input subsystem and the led class is *not* needed.
+
+In its simplest form, the LED class just allows control of LEDs from
+userspace. LEDs appear in /sys/class/leds/. The maximum brightness of the
+LED is defined in max_brightness file. The brightness file will set the brightness
+of the LED (taking a value 0-max_brightness). Most LEDs don't have hardware
+brightness support so will just be turned on for non-zero brightness settings.
+
+The class also introduces the optional concept of an LED trigger. A trigger
+is a kernel based source of led events. Triggers can either be simple or
+complex. A simple trigger isn't configurable and is designed to slot into
+existing subsystems with minimal additional code. Examples are the ide-disk,
+nand-disk and sharpsl-charge triggers. With led triggers disabled, the code
+optimises away.
+
+Complex triggers whilst available to all LEDs have LED specific
+parameters and work on a per LED basis. The timer trigger is an example.
+The timer trigger will periodically change the LED brightness between
+LED_OFF and the current brightness setting. The "on" and "off" time can
+be specified via /sys/class/leds/<device>/delay_{on,off} in milliseconds.
+You can change the brightness value of a LED independently of the timer
+trigger. However, if you set the brightness value to LED_OFF it will
+also disable the timer trigger.
+
+You can change triggers in a similar manner to the way an IO scheduler
+is chosen (via /sys/class/leds/<device>/trigger). Trigger specific
+parameters can appear in /sys/class/leds/<device> once a given trigger is
+selected.
+
+
+Design Philosophy
+=================
+
+The underlying design philosophy is simplicity. LEDs are simple devices
+and the aim is to keep a small amount of code giving as much functionality
+as possible. Please keep this in mind when suggesting enhancements.
+
+
+LED Device Naming
+=================
+
+Is currently of the form:
+
+"devicename:colour:function"
+
+There have been calls for LED properties such as colour to be exported as
+individual led class attributes. As a solution which doesn't incur as much
+overhead, I suggest these become part of the device name. The naming scheme
+above leaves scope for further attributes should they be needed. If sections
+of the name don't apply, just leave that section blank.
+
+
+Hardware accelerated blink of LEDs
+==================================
+
+Some LEDs can be programmed to blink without any CPU interaction. To
+support this feature, a LED driver can optionally implement the
+blink_set() function (see <linux/leds.h>). To set an LED to blinking,
+however, it is better to use use the API function led_blink_set(),
+as it will check and implement software fallback if necessary.
+
+To turn off blinking again, use the API function led_brightness_set()
+as that will not just set the LED brightness but also stop any software
+timers that may have been required for blinking.
+
+The blink_set() function should choose a user friendly blinking value
+if it is called with *delay_on==0 && *delay_off==0 parameters. In this
+case the driver should give back the chosen value through delay_on and
+delay_off parameters to the leds subsystem.
+
+Setting the brightness to zero with brightness_set() callback function
+should completely turn off the LED and cancel the previously programmed
+hardware blinking function, if any.
+
+
+Known Issues
+============
+
+The LED Trigger core cannot be a module as the simple trigger functions
+would cause nightmare dependency issues. I see this as a minor issue
+compared to the benefits the simple trigger functionality brings. The
+rest of the LED subsystem can be modular.
+
+
+Future Development
+==================
+
+At the moment, a trigger can't be created specifically for a single LED.
+There are a number of cases where a trigger might only be mappable to a
+particular LED (ACPI?). The addition of triggers provided by the LED driver
+should cover this option and be possible to add without breaking the
+current interface.
+
--- /dev/null
+++ linux-2.6.38-git18/Documentation/leds/leds-lp3944.txt
@@ -0,0 +1,50 @@
+Kernel driver lp3944
+====================
+
+ * National Semiconductor LP3944 Fun-light Chip
+ Prefix: 'lp3944'
+ Addresses scanned: None (see the Notes section below)
+ Datasheet: Publicly available at the National Semiconductor website
+ http://www.national.com/pf/LP/LP3944.html
+
+Authors:
+ Antonio Ospite <ospite@studenti.unina.it>
+
+
+Description
+-----------
+The LP3944 is a helper chip that can drive up to 8 leds, with two programmable
+DIM modes; it could even be used as a gpio expander but this driver assumes it
+is used as a led controller.
+
+The DIM modes are used to set _blink_ patterns for leds, the pattern is
+specified supplying two parameters:
+ - period: from 0s to 1.6s
+ - duty cycle: percentage of the period the led is on, from 0 to 100
+
+Setting a led in DIM0 or DIM1 mode makes it blink according to the pattern.
+See the datasheet for details.
+
+LP3944 can be found on Motorola A910 smartphone, where it drives the rgb
+leds, the camera flash light and the lcds power.
+
+
+Notes
+-----
+The chip is used mainly in embedded contexts, so this driver expects it is
+registered using the i2c_board_info mechanism.
+
+To register the chip at address 0x60 on adapter 0, set the platform data
+according to include/linux/leds-lp3944.h, set the i2c board info:
+
+ static struct i2c_board_info __initdata a910_i2c_board_info[] = {
+ {
+ I2C_BOARD_INFO("lp3944", 0x60),
+ .platform_data = &a910_lp3944_leds,
+ },
+ };
+
+and register it in the platform init function
+
+ i2c_register_board_info(0, a910_i2c_board_info,
+ ARRAY_SIZE(a910_i2c_board_info));
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 7/8] Documentation: consolidate leds files to leds/ subdir
2011-04-04 22:08 ` [PATCH 7/8] Documentation: consolidate leds files to leds/ subdir Randy Dunlap
@ 2011-04-05 0:54 ` Linus Torvalds
2011-04-05 8:25 ` Antonio Ospite
0 siblings, 1 reply; 14+ messages in thread
From: Linus Torvalds @ 2011-04-05 0:54 UTC (permalink / raw)
To: Randy Dunlap; +Cc: lkml, Antonio Ospite, akpm, Richard Purdie
On Mon, Apr 4, 2011 at 3:08 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>
> Changes since v1:
> - don't use git renames
Actually, I think it would make it much easier to validate the patches
if you used git rename patches for things like this.
As a traditional patch, it's impossible to see that "yes, it's a
rename". There might be tons of changes hiding in the add/remove pair.
Linus
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 7/8] Documentation: consolidate leds files to leds/ subdir
2011-04-05 0:54 ` Linus Torvalds
@ 2011-04-05 8:25 ` Antonio Ospite
0 siblings, 0 replies; 14+ messages in thread
From: Antonio Ospite @ 2011-04-05 8:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randy Dunlap, lkml, akpm, Richard Purdie
[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]
On Mon, 4 Apr 2011 17:54:04 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, Apr 4, 2011 at 3:08 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> >
> > Changes since v1:
> > - don't use git renames
>
> Actually, I think it would make it much easier to validate the patches
> if you used git rename patches for things like this.
>
I agree, and I did that for the first review round.
Initially the patch was meant to be handled by Andrew Morton, maybe I
misunderstood one of his comments from
http://www.spinics.net/lists/linux-doc/msg02562.html :
"hm, these look like funky git renames. patch(1) doesn't
handle those."
and though he wanted me to change that.
> As a traditional patch, it's impossible to see that "yes, it's a
> rename". There might be tons of changes hiding in the add/remove pair.
>
> Linus
>
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 8/8] Documentation: update cgroups info user groups names
2011-04-04 21:58 [PATCH 1/8] Documentation: update kmemleak arch. info Randy Dunlap
` (5 preceding siblings ...)
2011-04-04 22:08 ` [PATCH 7/8] Documentation: consolidate leds files to leds/ subdir Randy Dunlap
@ 2011-04-04 22:10 ` Randy Dunlap
6 siblings, 0 replies; 14+ messages in thread
From: Randy Dunlap @ 2011-04-04 22:10 UTC (permalink / raw)
To: lkml; +Cc: torvalds, Geunsik Lim, Paul Menage
From: Geunsik Lim <geunsik.lim@samsung.com>
Update suitable words to explain / understand cgroups contents.
Signed-off-by: Geunsik Lim <geunsik.lim@samsung.com>
Cc: Paul Menage <menage@google.com>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
Documentation/cgroups/cgroups.txt | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- linux-2.6.38-git18.orig/Documentation/cgroups/cgroups.txt
+++ linux-2.6.38-git18/Documentation/cgroups/cgroups.txt
@@ -110,22 +110,22 @@ university server with various users - s
tasks etc. The resource planning for this server could be along the
following lines:
- CPU : Top cpuset
+ CPU : "Top cpuset"
/ \
CPUSet1 CPUSet2
- | |
- (Profs) (Students)
+ | |
+ (Professors) (Students)
In addition (system tasks) are attached to topcpuset (so
that they can run anywhere) with a limit of 20%
- Memory : Professors (50%), students (30%), system (20%)
+ Memory : Professors (50%), Students (30%), system (20%)
- Disk : Prof (50%), students (30%), system (20%)
+ Disk : Professors (50%), Students (30%), system (20%)
Network : WWW browsing (20%), Network File System (60%), others (20%)
/ \
- Prof (15%) students (5%)
+ Professors (15%) students (5%)
Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go
into NFS network class.
^ permalink raw reply [flat|nested] 14+ messages in thread