Making pdfdocs with sphinx - only select rst targets
I'm excited to see the new documentation format, so I'm changing my documentation in the pending patches I have to use it. I however cannot generate anything other than the main Documentation/output/pdf/Kernel.pdf How can I see in PDF the other documentation? I'm using: make DOCBOOKS="" pdfdocs The Documentation/output/pdf/Kernel.pdf only has a bit of the documentation on how to write docs, nothing else. Using htmldocs as a target works but I am not a fan of that output. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] docs: sphinxify sparse.txt and move to dev-tools
On Tue, 9 Aug 2016 01:31:06 -0700 Christoph Hellwig wrote: > On Tue, Aug 09, 2016 at 10:28:38AM +0200, Daniel Vetter wrote: > > The point is to make the docs more discoverable by being able to > > cross-link them. Old hats like us don't need that, but it definitely > > has value in bringing new folks on board. > > But do that in a way that keeps the old hats happy. The crazy use of > punctuation and the weird quotes is an absolute no-go. As others have noted, the long-term goal is to turn our disorganized documentation hairball into something more approachable, maintainable, and integrated; this is a step in that direction. I take it you object to the ``literal quotes`` which render in a monospace font? That's the bulk of the changes there. I can certainly take them out if you really think "__bitwise" looks better than ``__bitwise``; it will adversely affect the resulting pages, but so be it. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v14 00/14] support "task_isolation" mode
Here is a respin of the task-isolation patch set. This primarily reflects some testing on x86, and a rebase to 4.8. I have been getting email asking me when and where this patch will be upstreamed so folks can start using it. I had been thinking the obvious path was via Frederic Weisbecker to Ingo as a NOHZ kind of thing. But perhaps it touches enough other subsystems that that doesn't really make sense? Andrew, would it make sense to take it directly via your tree? Frederic, Ingo, what do you think? Changes since v13: - Rebased on v4.8-rc1 (and thus uses the standard try_get_task_struct). - Fixes a bug when using the clocksource watchdog; it is now scheduled to run only on the housekeeping cpus [by Christoph Lameter]. - Fixes a bug in x86 syscall_trace_enter() [seen by Francis Giraldeau]. - Includes a selftest. The previous (v13) patch series is here: https://lkml.kernel.org/r/1468529299-27929-1-git-send-email-cmetc...@mellanox.com This version of the patch series has been tested on arm64 and tilegx, and build-tested on x86 (plus some volunteer testing on x86 by Christoph and Francis). It remains true that the 1 Hz tick needs to be disabled for this patch series to be able to achieve its primary goal of enabling truly tick-free operation, but that is ongoing orthogonal work. Frederic, do you have a sense of what is left to be done there? I can certainly try to contribute to that effort as well. The series is available at: git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git dataplane Chris Metcalf (13): vmstat: add quiet_vmstat_sync function vmstat: add vmstat_idle function lru_add_drain_all: factor out lru_add_drain_needed task_isolation: add initial support task_isolation: track asynchronous interrupts arch/x86: enable task isolation functionality arm64: factor work_pending state machine to C arch/arm64: enable task isolation functionality arch/tile: enable task isolation functionality arm, tile: turn off timer tick for oneshot_stopped state task_isolation: support CONFIG_TASK_ISOLATION_ALL task_isolation: add user-settable notification signal task_isolation self test Christoph Lameter (1): clocksource: Do not schedule watchdog on isolated or NOHZ cpus Documentation/kernel-parameters.txt| 16 + arch/arm64/Kconfig | 1 + arch/arm64/include/asm/thread_info.h | 5 +- arch/arm64/kernel/entry.S | 12 +- arch/arm64/kernel/ptrace.c | 15 +- arch/arm64/kernel/signal.c | 42 +- arch/arm64/kernel/smp.c| 2 + arch/arm64/mm/fault.c | 8 +- arch/tile/Kconfig | 1 + arch/tile/include/asm/thread_info.h| 4 +- arch/tile/kernel/process.c | 9 + arch/tile/kernel/ptrace.c | 7 + arch/tile/kernel/single_step.c | 7 + arch/tile/kernel/smp.c | 26 +- arch/tile/kernel/time.c| 1 + arch/tile/kernel/unaligned.c | 4 + arch/tile/mm/fault.c | 13 +- arch/tile/mm/homecache.c | 2 + arch/x86/Kconfig | 1 + arch/x86/entry/common.c| 20 +- arch/x86/include/asm/thread_info.h | 2 + arch/x86/kernel/smp.c | 2 + arch/x86/kernel/traps.c| 3 + arch/x86/mm/fault.c| 5 + drivers/base/cpu.c | 18 + drivers/clocksource/arm_arch_timer.c | 2 + include/linux/context_tracking_state.h | 6 + include/linux/isolation.h | 73 +++ include/linux/sched.h | 3 + include/linux/swap.h | 1 + include/linux/tick.h | 2 + include/linux/vmstat.h | 4 + include/uapi/linux/prctl.h | 10 + init/Kconfig | 37 ++ kernel/Makefile| 1 + kernel/fork.c | 3 + kernel/irq_work.c | 5 +- kernel/isolation.c | 337 +++ kernel/sched/core.c| 14 + kernel/signal.c| 15 + kernel/smp.c | 6 +- kernel/softirq.c | 33 ++ kernel/sys.c | 9 + kernel/time/clocksource.c | 10 +- kernel/time/tick-sched.c | 36 +- mm/swap
[PATCH v14 05/14] task_isolation: track asynchronous interrupts
This commit adds support for tracking asynchronous interrupts
delivered to task-isolation tasks, e.g. IPIs or IRQs. Just
as for exceptions and syscalls, when this occurs we arrange to
deliver a signal to the task so that it knows it has been
interrupted. If the task is interrupted by an NMI, we can't
safely deliver a signal, so we just dump out a console stack.
We also support a new "task_isolation_debug" flag which forces
the console stack to be dumped out regardless. We try to catch
the original source of the interrupt, e.g. if an IPI is dispatched
to a task-isolation task, we dump the backtrace of the remote
core that is sending the IPI, rather than just dumping out a
trace showing the core received an IPI from somewhere.
Calls to task_isolation_debug() can be placed in the
platform-independent code when that results in fewer lines
of code changes, as for example is true of the users of the
arch_send_call_function_*() APIs. Or, they can be placed in the
per-architecture code when there are many callers, as for example
is true of the smp_send_reschedule() call.
A further cleanup might be to create an intermediate layer, so that
for example smp_send_reschedule() is a single generic function that
just calls arch_smp_send_reschedule(), allowing generic code to be
called every time smp_send_reschedule() is invoked. But for now,
we just update either callers or callees as makes most sense.
Signed-off-by: Chris Metcalf
---
Documentation/kernel-parameters.txt| 8
include/linux/context_tracking_state.h | 6 +++
include/linux/isolation.h | 13 ++
kernel/irq_work.c | 5 ++-
kernel/isolation.c | 74 ++
kernel/sched/core.c| 14 +++
kernel/signal.c| 7
kernel/smp.c | 6 ++-
kernel/softirq.c | 33 +++
9 files changed, 164 insertions(+), 2 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 7f1336b50dcc..f172cd310cf4 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3951,6 +3951,14 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
also sets up nohz_full and isolcpus mode for the
listed set of cpus.
+ task_isolation_debug[KNL]
+ In kernels built with CONFIG_TASK_ISOLATION
+ and booted in task_isolation= mode, this
+ setting will generate console backtraces when
+ the kernel is about to interrupt a task that
+ has requested PR_TASK_ISOLATION_ENABLE and is
+ running on a task_isolation core.
+
tcpmhash_entries= [KNL,NET]
Set the number of tcp_metrics_hash slots.
Default value is 8192 or 16384 depending on total
diff --git a/include/linux/context_tracking_state.h
b/include/linux/context_tracking_state.h
index 1d34fe68f48a..4e2c4b900b82 100644
--- a/include/linux/context_tracking_state.h
+++ b/include/linux/context_tracking_state.h
@@ -39,8 +39,14 @@ static inline bool context_tracking_in_user(void)
{
return __this_cpu_read(context_tracking.state) == CONTEXT_USER;
}
+
+static inline bool context_tracking_cpu_in_user(int cpu)
+{
+ return per_cpu(context_tracking.state, cpu) == CONTEXT_USER;
+}
#else
static inline bool context_tracking_in_user(void) { return false; }
+static inline bool context_tracking_cpu_in_user(int cpu) { return false; }
static inline bool context_tracking_active(void) { return false; }
static inline bool context_tracking_is_enabled(void) { return false; }
static inline bool context_tracking_cpu_is_enabled(void) { return false; }
diff --git a/include/linux/isolation.h b/include/linux/isolation.h
index d9288b85b41f..02728b1f8775 100644
--- a/include/linux/isolation.h
+++ b/include/linux/isolation.h
@@ -46,6 +46,17 @@ extern void _task_isolation_quiet_exception(const char *fmt,
...);
_task_isolation_quiet_exception(fmt, ## __VA_ARGS__); \
} while (0)
+extern void _task_isolation_debug(int cpu, const char *type);
+#define task_isolation_debug(cpu, type)
\
+ do {\
+ if (task_isolation_possible(cpu)) \
+ _task_isolation_debug(cpu, type); \
+ } while (0)
+
+extern void task_isolation_debug_cpumask(const struct cpumask *,
+const char *type);
+extern void task_isolation_debug_task(int cpu, struct task_struct *p,
+ const char *type);
#else
static inline void task_isolation_init(void) { }
static inline bool tas
[PATCH v14 13/14] task_isolation: add user-settable notification signal
By default, if a task in task isolation mode re-enters the kernel,
it is terminated with SIGKILL. With this commit, the application
can choose what signal to receive on a task isolation violation
by invoking prctl() with PR_TASK_ISOLATION_ENABLE, or'ing in the
PR_TASK_ISOLATION_USERSIG bit, and setting the specific requested
signal by or'ing in PR_TASK_ISOLATION_SET_SIG(sig).
This mode allows for catching the notification signal; for example,
in a production environment, it might be helpful to log information
to the application logging mechanism before exiting. Or, the
application might choose to re-enable task isolation and return to
continue execution.
As a special case, the user may set the signal to 0, which means
that no signal will be delivered. In this mode, the application
may freely enter the kernel for syscalls and synchronous exceptions
such as page faults, but each time it will be held in the kernel
before returning to userspace until the kernel has quiesced timer
ticks or other potential future interruptions, just like it does
on return from the initial prctl() call. Note that in this mode,
the task can be migrated away from its initial task_isolation core,
and if it is migrated to a non-isolated core it will lose task
isolation until it is migrated back to an isolated core.
In addition, in this mode we no longer require the affinity to
be set correctly on entry (though we warn on the console if it's
not right), and we don't bother to notify the user that the kernel
isn't ready to quiesce either (since we'll presumably be in and
out of the kernel multiple times with task isolation enabled anyway).
The PR_TASK_ISOLATION_NOSIG define is provided as a convenience
wrapper to express this semantic.
Signed-off-by: Chris Metcalf
---
include/uapi/linux/prctl.h | 5
kernel/isolation.c | 62 ++
2 files changed, 56 insertions(+), 11 deletions(-)
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index 2a49d0d2940a..7af6eb51c1dc 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -201,5 +201,10 @@ struct prctl_mm_map {
#define PR_SET_TASK_ISOLATION 48
#define PR_GET_TASK_ISOLATION 49
# define PR_TASK_ISOLATION_ENABLE (1 << 0)
+# define PR_TASK_ISOLATION_USERSIG (1 << 1)
+# define PR_TASK_ISOLATION_SET_SIG(sig)(((sig) & 0x7f) << 8)
+# define PR_TASK_ISOLATION_GET_SIG(bits) (((bits) >> 8) & 0x7f)
+# define PR_TASK_ISOLATION_NOSIG \
+ (PR_TASK_ISOLATION_USERSIG | PR_TASK_ISOLATION_SET_SIG(0))
#endif /* _LINUX_PRCTL_H */
diff --git a/kernel/isolation.c b/kernel/isolation.c
index f8ccf5e67e38..d36cb3943c80 100644
--- a/kernel/isolation.c
+++ b/kernel/isolation.c
@@ -85,6 +85,15 @@ static bool can_stop_my_full_tick_now(void)
return ret;
}
+/* Get the signal number that will be sent for a particular set of flag bits.
*/
+static int task_isolation_sig(int flags)
+{
+ if (flags & PR_TASK_ISOLATION_USERSIG)
+ return PR_TASK_ISOLATION_GET_SIG(flags);
+ else
+ return SIGKILL;
+}
+
/*
* This routine controls whether we can enable task-isolation mode.
* The task must be affinitized to a single task_isolation core, or
@@ -92,16 +101,30 @@ static bool can_stop_my_full_tick_now(void)
* stop the nohz_full tick (e.g., no other schedulable tasks currently
* running, no POSIX cpu timers currently set up, etc.); if not, we
* return EAGAIN.
+ *
+ * If we will not be strictly enforcing kernel re-entry with a signal,
+ * we just generate a warning printk if there is a bad affinity set
+ * on entry (since after all you can always change it again after you
+ * call prctl) and we don't bother failing the prctl with -EAGAIN
+ * since we assume you will go in and out of kernel mode anyway.
*/
int task_isolation_set(unsigned int flags)
{
if (flags != 0) {
+ int sig = task_isolation_sig(flags);
+
if (cpumask_weight(tsk_cpus_allowed(current)) != 1 ||
!task_isolation_possible(raw_smp_processor_id())) {
/* Invalid task affinity setting. */
- return -EINVAL;
+ if (sig)
+ return -EINVAL;
+ else
+ pr_warn("%s/%d: enabling non-signalling task
isolation\n"
+ "and not bound to a single task
isolation core\n",
+ current->comm, current->pid);
}
- if (!can_stop_my_full_tick_now()) {
+
+ if (sig && !can_stop_my_full_tick_now()) {
/* System not yet ready for task isolation. */
return -EAGAIN;
}
@@ -160,11 +183,11 @@ void task_isolation_enter(void)
}
static void task_isolation_deliver_signal(struct task_struct *task,
-
[PATCH v14 04/14] task_isolation: add initial support
The existing nohz_full mode is designed as a "soft" isolation mode that makes tradeoffs to minimize userspace interruptions while still attempting to avoid overheads in the kernel entry/exit path, to provide 100% kernel semantics, etc. However, some applications require a "hard" commitment from the kernel to avoid interruptions, in particular userspace device driver style applications, such as high-speed networking code. This change introduces a framework to allow applications to elect to have the "hard" semantics as needed, specifying prctl(PR_SET_TASK_ISOLATION, PR_TASK_ISOLATION_ENABLE) to do so. Subsequent commits will add additional flags and additional semantics. The kernel must be built with the new TASK_ISOLATION Kconfig flag to enable this mode, and the kernel booted with an appropriate task_isolation=CPULIST boot argument, which enables nohz_full and isolcpus as well. The "task_isolation" state is then indicated by setting a new task struct field, task_isolation_flag, to the value passed by prctl(), and also setting a TIF_TASK_ISOLATION bit in thread_info flags. When task isolation is enabled for a task, and it is returning to userspace on a task isolation core, it calls the new task_isolation_ready() / task_isolation_enter() routines to take additional actions to help the task avoid being interrupted in the future. The task_isolation_ready() call is invoked when TIF_TASK_ISOLATION is set in prepare_exit_to_usermode() or its architectural equivalent, and forces the loop to retry if the system is not ready. It is called with interrupts disabled and inspects the kernel state to determine if it is safe to return into an isolated state. In particular, if it sees that the scheduler tick is still enabled, it reports that it is not yet safe. Each time through the loop of TIF work to do, if TIF_TASK_ISOLATION is set, we call the new task_isolation_enter() routine. This takes any actions that might avoid a future interrupt to the core, such as a worker thread being scheduled that could be quiesced now (e.g. the vmstat worker) or a future IPI to the core to clean up some state that could be cleaned up now (e.g. the mm lru per-cpu cache). In addition, it reqeusts rescheduling if the scheduler dyntick is still running. Once the task has returned to userspace after issuing the prctl(), if it enters the kernel again via system call, page fault, or any of a number of other synchronous traps, the kernel will kill it with SIGKILL. For system calls, this test is performed immediately before the SECCOMP test and causes the syscall to return immediately with ENOSYS. To allow the state to be entered and exited, the syscall checking test ignores the prctl() syscall so that we can clear the bit again later, and ignores exit/exit_group to allow exiting the task without a pointless signal killing you as you try to do so. A new /sys/devices/system/cpu/task_isolation pseudo-file is added, parallel to the comparable nohz_full file. Separate patches that follow provide these changes for x86, tile, and arm64. Signed-off-by: Chris Metcalf --- Documentation/kernel-parameters.txt | 8 ++ drivers/base/cpu.c | 18 +++ include/linux/isolation.h | 60 ++ include/linux/sched.h | 3 + include/linux/tick.h| 2 + include/uapi/linux/prctl.h | 5 + init/Kconfig| 27 + kernel/Makefile | 1 + kernel/fork.c | 3 + kernel/isolation.c | 217 kernel/signal.c | 8 ++ kernel/sys.c| 9 ++ kernel/time/tick-sched.c| 36 +++--- 13 files changed, 384 insertions(+), 13 deletions(-) create mode 100644 include/linux/isolation.h create mode 100644 kernel/isolation.c diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 46c030a49186..7f1336b50dcc 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3943,6 +3943,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted. neutralize any effect of /proc/sys/kernel/sysrq. Useful for debugging. + task_isolation= [KNL] + In kernels built with CONFIG_TASK_ISOLATION=y, set + the specified list of CPUs where cpus will be able + to use prctl(PR_SET_TASK_ISOLATION) to set up task + isolation mode. Setting this boot flag implicitly + also sets up nohz_full and isolcpus mode for the + listed set of cpus. + tcpmhash_entries= [KNL,NET] Set the number of tcp_metrics_hash slots. Default value is 8192 or 16384 depending on total diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c index 691eeea2f1
[PATCH v14 12/14] task_isolation: support CONFIG_TASK_ISOLATION_ALL
This option, similar to NO_HZ_FULL_ALL, simplifies configuring
a system to boot by default with all cores except the boot core
running in task isolation mode.
Signed-off-by: Chris Metcalf
---
init/Kconfig | 10 ++
kernel/isolation.c | 6 ++
2 files changed, 16 insertions(+)
diff --git a/init/Kconfig b/init/Kconfig
index 85a4b6dd26f2..2d49c5b78b93 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -813,6 +813,16 @@ config TASK_ISOLATION
You should say "N" unless you are intending to run a
high-performance userspace driver or similar task.
+config TASK_ISOLATION_ALL
+ bool "Provide task isolation on all CPUs by default (except CPU 0)"
+ depends on TASK_ISOLATION
+ help
+If the user doesn't pass the task_isolation boot option to
+define the range of task isolation CPUs, consider that all
+CPUs in the system are task isolation by default.
+Note the boot CPU will still be kept outside the range to
+handle timekeeping duty, etc.
+
config BUILD_BIN2C
bool
default n
diff --git a/kernel/isolation.c b/kernel/isolation.c
index 7cd57ca95be5..f8ccf5e67e38 100644
--- a/kernel/isolation.c
+++ b/kernel/isolation.c
@@ -43,8 +43,14 @@ int __init task_isolation_init(void)
{
/* For offstack cpumask, ensure we allocate an empty cpumask early. */
if (!saw_boot_arg) {
+#ifdef CONFIG_TASK_ISOLATION_ALL
+ alloc_cpumask_var(&task_isolation_map, GFP_KERNEL);
+ cpumask_copy(task_isolation_map, cpu_possible_mask);
+ cpumask_clear_cpu(smp_processor_id(), task_isolation_map);
+#else
zalloc_cpumask_var(&task_isolation_map, GFP_KERNEL);
return 0;
+#endif
}
/*
--
2.7.2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] doc-rst: more generic way to build only sphinx sub-folders
Am 09.08.2016 um 20:02 schrieb Mauro Carvalho Chehab : > Em Tue, 9 Aug 2016 09:21:08 -0600 > Jonathan Corbet escreveu: > >> On Mon, 8 Aug 2016 15:14:57 +0200 >> Markus Heiser wrote: >> >>> this is my approach for a more generic way to build only sphinx >>> sub-folders, we >>> discussed in [1]. The last patch adds a minimal conf.py to the gpu folder, >>> if >>> you don't want to patch the gpu folder drop it. >> >> I haven't had a chance to really mess with this yet, but it seems like a >> reasonable solution. > > Agreed. > >> Mauro, does it give you what you need? > > Yes. Just tested it here, and it works fine, allowing to build > everything, just one of the books and the media book with the nitpick > configuration. > > Acked-by: Mauro Carvalho Chehab Hi Mauro and Jon, thanks for testing and ack. -- Markus -- -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] doc-rst: more generic way to build only sphinx sub-folders
Em Tue, 9 Aug 2016 09:21:08 -0600 Jonathan Corbet escreveu: > On Mon, 8 Aug 2016 15:14:57 +0200 > Markus Heiser wrote: > > > this is my approach for a more generic way to build only sphinx > > sub-folders, we > > discussed in [1]. The last patch adds a minimal conf.py to the gpu folder, > > if > > you don't want to patch the gpu folder drop it. > > I haven't had a chance to really mess with this yet, but it seems like a > reasonable solution. Agreed. > Mauro, does it give you what you need? Yes. Just tested it here, and it works fine, allowing to build everything, just one of the books and the media book with the nitpick configuration. Acked-by: Mauro Carvalho Chehab Please notice that Markus based his patch on my previous patch series. So, if it is easier for you, you could pull them altogether from my tree: git://linuxtv.org/mchehab/experimental.git docs-next Or otherwise just pick the individual patches, adding my ack on the Markus ones. Thanks, Mauro The following changes since commit a157b3aaa44829998d5a079174df989e5d8c20ff: Merge tag 'pwm/for-4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm (2016-08-06 00:01:33 -0400) are available in the git repository at: docs-next for you to fetch changes up to 78c63a7a941d053a7dfaf787b586ff25a8e2fae9: doc-rst: add stand-alone conf.py to gpu folder (2016-08-09 14:48:01 -0300) Markus Heiser (4): doc-rst: support additional Sphinx build config override doc-rst: generic way to build only sphinx sub-folders doc-rst: add stand-alone conf.py to media folder doc-rst: add stand-alone conf.py to gpu folder Mauro Carvalho Chehab (2): doc-rst: add an option to build media documentation in nitpick mode doc-rst: remove a bogus comment from Documentation/index.rst Documentation/DocBook/Makefile | 2 +- Documentation/Makefile.sphinx | 46 ++ Documentation/conf.py | 9 + Documentation/gpu/conf.py | 3 +++ Documentation/index.rst | 7 +-- Documentation/media/conf.py | 3 +++ Documentation/media/conf_nitpick.py | 91 +++ Documentation/media/index.rst | 12 Documentation/sphinx/load_config.py | 32 9 files changed, 190 insertions(+), 15 deletions(-) create mode 100644 Documentation/gpu/conf.py create mode 100644 Documentation/media/conf.py create mode 100644 Documentation/media/conf_nitpick.py create mode 100644 Documentation/media/index.rst create mode 100644 Documentation/sphinx/load_config.py -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] doc: update block/queue-sysfs.txt entries
Add descriptions for dax, io_poll, and write_same_max_bytes files. Signed-off-by: Joe Lawrence --- Documentation/block/queue-sysfs.txt | 18 ++ 1 file changed, 18 insertions(+) diff --git a/Documentation/block/queue-sysfs.txt b/Documentation/block/queue-sysfs.txt index d515d58962b9..2a3904030dea 100644 --- a/Documentation/block/queue-sysfs.txt +++ b/Documentation/block/queue-sysfs.txt @@ -14,6 +14,12 @@ add_random (RW) This file allows to turn off the disk entropy contribution. Default value of this file is '1'(on). +dax (RO) + +This file indicates whether the device supports Direct Access (DAX), +used by CPU-addressable storage to bypass the pagecache. It shows '1' +if true, '0' if not. + discard_granularity (RO) --- This shows the size of internal allocation of the device in bytes, if @@ -46,6 +52,12 @@ hw_sector_size (RO) --- This is the hardware sector size of the device, in bytes. +io_poll (RW) + +When read, this file shows the total number of block IO polls and how +many returned success. Writing '0' to this file will disable polling +for this device. Writing any non-zero value will enable this feature. + iostats (RW) - This file is used to control (on/off) the iostats accounting of the @@ -151,5 +163,11 @@ device state. This means that it might not be safe to toggle the setting from "write back" to "write through", since that will also eliminate cache flushes issued by the kernel. +write_same_max_bytes (RO) +- +This is the number of bytes the device can write in a single write-same +command. A value of '0' means write-same is not supported by this +device. + Jens Axboe , February 2009 -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] doc-rst: more generic way to build only sphinx sub-folders
On Mon, 8 Aug 2016 15:14:57 +0200 Markus Heiser wrote: > this is my approach for a more generic way to build only sphinx sub-folders, > we > discussed in [1]. The last patch adds a minimal conf.py to the gpu folder, if > you don't want to patch the gpu folder drop it. I haven't had a chance to really mess with this yet, but it seems like a reasonable solution. Mauro, does it give you what you need? Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/3] ARM: dts: Add Arria10 SD/MMC EDAC devicetree entry
From: Thor Thayer
Add the device tree entries needed to support the Altera SD/MMC
FIFO buffer EDAC on the Arria10 chip.
Signed-off-by: Thor Thayer
Acked-by: Dinh Nguyen
---
v2 No change
---
arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts
b/arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts
index 8a7dfa4..040a164 100644
--- a/arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts
+++ b/arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts
@@ -25,3 +25,15 @@
broken-cd;
bus-width = <4>;
};
+
+&eccmgr {
+ sdmmca-ecc@ff8c2c00 {
+ compatible = "altr,socfpga-sdmmc-ecc";
+ reg = <0xff8c2c00 0x400>;
+ altr,ecc-parent = <&mmc>;
+ interrupts = <15 IRQ_TYPE_LEVEL_HIGH>,
+<47 IRQ_TYPE_LEVEL_HIGH>,
+<16 IRQ_TYPE_LEVEL_HIGH>,
+<48 IRQ_TYPE_LEVEL_HIGH>;
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/3] Add SD/MMC EDAC for Altera Arria10
From: Thor Thayer Add the SD/MMC FIFO EDAC module which is a dual-port RAM as opposed to the other Arria10 peripheral's single port RAM FIFOs. Thor Thayer (3): Documentation: dt: socfpga: Add Arria10 SD-MMC EDAC binding EDAC, altera: Add Arria10 SD-MMC EDAC support ARM: dts: Add Arria10 SD/MMC EDAC devicetree entry .../bindings/arm/altera/socfpga-eccmgr.txt | 19 ++ arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts | 12 ++ drivers/edac/Kconfig |7 + drivers/edac/altera_edac.c | 188 +++- drivers/edac/altera_edac.h |5 + 5 files changed, 230 insertions(+), 1 deletion(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/3] EDAC, altera: Add Arria10 SD-MMC EDAC support
From: Thor Thayer
Add Altera Arria10 SD-MMC FIFO memory EDAC support. The SD-MMC
is a dual port RAM implementation which is different than any
of the other peripherals and therefore requires additional code.
Signed-off-by: Thor Thayer
---
v2 Cleanup PortB initialization by moving device tree search to
top of function.
Improve unhandled IRQ message using WARN_ONCE() with IRQ#.
Change KERN_ERR on device tree not found to KERN_WARNING.
---
drivers/edac/Kconfig |7 ++
drivers/edac/altera_edac.c | 188 +++-
drivers/edac/altera_edac.h |5 ++
3 files changed, 199 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 72752f4..394cd16 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -426,6 +426,13 @@ config EDAC_ALTERA_QSPI
Support for error detection and correction on the
Altera QSPI FIFO Memory for Altera SoCs.
+config EDAC_ALTERA_SDMMC
+ bool "Altera SDMMC FIFO ECC"
+ depends on EDAC_ALTERA=y && MMC_DW
+ help
+ Support for error detection and correction on the
+ Altera SDMMC FIFO Memory for Altera SoCs.
+
config EDAC_SYNOPSYS
tristate "Synopsys DDR Memory Controller"
depends on EDAC_MM_EDAC && ARCH_ZYNQ
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 28247f8..289fd81 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1393,6 +1393,188 @@ early_initcall(socfpga_init_qspi_ecc);
#endif /* CONFIG_EDAC_ALTERA_QSPI */
+/* SDMMC Device Functions **/
+
+#ifdef CONFIG_EDAC_ALTERA_SDMMC
+
+static const struct edac_device_prv_data a10_sdmmceccb_data;
+static int altr_portb_setup(struct altr_edac_device_dev *device)
+{
+ struct edac_device_ctl_info *dci;
+ struct altr_edac_device_dev *altdev;
+ char *ecc_name = "sdmmcb-ecc";
+ int edac_idx, rc;
+ struct device_node *np;
+ const struct edac_device_prv_data *prv = &a10_sdmmceccb_data;
+
+ rc = altr_check_ecc_deps(device);
+ if (rc)
+ return rc;
+
+ np = of_find_compatible_node(NULL, NULL, "altr,socfpga-sdmmc-ecc");
+ if (!np) {
+ edac_printk(KERN_WARNING, EDAC_DEVICE, "SDMMC node not
found\n");
+ return -ENODEV;
+ }
+
+ /* Create the PortB EDAC device */
+ edac_idx = edac_device_alloc_index();
+ dci = edac_device_alloc_ctl_info(sizeof(*altdev), ecc_name, 1,
+ecc_name, 1, 0, NULL, 0, edac_idx);
+ if (!dci) {
+ edac_printk(KERN_ERR, EDAC_DEVICE,
+ "%s: Unable to allocate PortB EDAC device\n",
+ ecc_name);
+ return -ENOMEM;
+ }
+
+ /* Initialize the PortB EDAC device structure from PortA structure */
+ altdev = dci->pvt_info;
+ *altdev = *device;
+
+ if (!devres_open_group(&altdev->ddev, altr_portb_setup, GFP_KERNEL))
+ return -ENOMEM;
+
+ /* Update PortB specific values */
+ altdev->edac_dev_name = ecc_name;
+ altdev->edac_idx = edac_idx;
+ altdev->edac_dev = dci;
+ altdev->data = prv;
+ dci->dev = &altdev->ddev;
+ dci->ctl_name = "Altera ECC Manager";
+ dci->mod_name = ecc_name;
+ dci->dev_name = ecc_name;
+
+ /* Update the IRQs for PortB */
+ altdev->sb_irq = irq_of_parse_and_map(np, 2);
+ if (!altdev->sb_irq) {
+ edac_printk(KERN_ERR, EDAC_DEVICE, "Error PortB SBIRQ alloc\n");
+ rc = -ENODEV;
+ goto err_release_group_1;
+ }
+ rc = devm_request_irq(&altdev->ddev, altdev->sb_irq,
+ prv->ecc_irq_handler,
+ IRQF_SHARED, ecc_name, altdev);
+ if (rc) {
+ edac_printk(KERN_ERR, EDAC_DEVICE, "PortB SBERR IRQ error\n");
+ goto err_release_group_1;
+ }
+
+ altdev->db_irq = irq_of_parse_and_map(np, 3);
+ if (!altdev->db_irq) {
+ edac_printk(KERN_ERR, EDAC_DEVICE, "Error PortB DBIRQ alloc\n");
+ rc = -ENODEV;
+ goto err_release_group_1;
+ }
+ rc = devm_request_irq(&altdev->ddev, altdev->db_irq,
+ prv->ecc_irq_handler,
+ IRQF_SHARED, ecc_name, altdev);
+ if (rc) {
+ edac_printk(KERN_ERR, EDAC_DEVICE, "PortB DBERR IRQ error\n");
+ goto err_release_group_1;
+ }
+
+ rc = edac_device_add_device(dci);
+ if (rc) {
+ edac_printk(KERN_ERR, EDAC_DEVICE,
+ "edac_device_add_device portB failed\n");
+ rc = -ENOMEM;
+ goto err_release_group_1;
+ }
+ altr_create_edacdev_dbgfs(dci, prv);
+
+ list_add(&altdev->next, &altdev->edac->a10_ecc_devices);
[PATCHv2 1/3] Documentation: dt: socfpga: Add Arria10 SD-MMC EDAC binding
From: Thor Thayer
Add the device tree bindings needed to support the Altera SD-MMC
FIFO buffers EDAC on the Arria10 chip.
Signed-off-by: Thor Thayer
Acked-by: Rob Herring
---
v2 No change
---
.../bindings/arm/altera/socfpga-eccmgr.txt | 19 +++
1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
index ee66df0..4a1714f 100644
--- a/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
@@ -122,6 +122,15 @@ Required Properties:
- interrupts : Should be single bit error interrupt, then double bit error
interrupt, in this order.
+SDMMC FIFO ECC
+Required Properties:
+- compatible : Should be "altr,socfpga-sdmmc-ecc"
+- reg : Address and size for ECC block registers.
+- altr,ecc-parent : phandle to parent SD/MMC node.
+- interrupts : Should be single bit error interrupt, then double bit error
+ interrupt, in this order for port A, and then single bit error
interrupt,
+ then double bit error interrupt in this order for port B.
+
Example:
eccmgr: eccmgr@ffd06000 {
@@ -211,4 +220,14 @@ Example:
interrupts = <14 IRQ_TYPE_LEVEL_HIGH>,
<46 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ sdmmc-ecc@ff8c2c00 {
+ compatible = "altr,socfpga-sdmmc-ecc";
+ reg = <0xff8c2c00 0x400>;
+ altr,ecc-parent = <&mmc>;
+ interrupts = <15 IRQ_TYPE_LEVEL_HIGH>,
+<47 IRQ_TYPE_LEVEL_HIGH>,
+<16 IRQ_TYPE_LEVEL_HIGH>,
+<48 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] vgaarbiter: rst-ifiy and polish kerneldoc
Move the documentation into Documentation/gpu, link it up and pull in
the kernel doc.
No actual text changes except that I did polish the kerneldoc a bit,
especially for vga_client_register().
v2: Remove some rst from vga-switcheroo.rst that I don't understand,
but which seems to be the reason why the new vgaarbiter.rst sometimes
drops out of the sidebar index.
v3: Drop one level of headings and clarify the vgaarb one a bit.
Cc: Jonathan Corbet
Cc: linux-doc@vger.kernel.org
Signed-off-by: Daniel Vetter
---
Documentation/gpu/index.rst | 1 +
Documentation/gpu/vga-switcheroo.rst | 2 -
Documentation/gpu/vgaarbiter.rst | 191 ++
Documentation/vgaarbiter.txt | 192 ---
drivers/gpu/vga/vgaarb.c | 103 ++-
include/linux/vgaarb.h | 128 +++
6 files changed, 309 insertions(+), 308 deletions(-)
create mode 100644 Documentation/gpu/vgaarbiter.rst
delete mode 100644 Documentation/vgaarbiter.txt
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index fcac0fa72056..ba92f45abb76 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -12,3 +12,4 @@ Linux GPU Driver Developer's Guide
drm-uapi
i915
vga-switcheroo
+ vgaarbiter
diff --git a/Documentation/gpu/vga-switcheroo.rst
b/Documentation/gpu/vga-switcheroo.rst
index cbbdb994f1dd..463a74fc40d1 100644
--- a/Documentation/gpu/vga-switcheroo.rst
+++ b/Documentation/gpu/vga-switcheroo.rst
@@ -1,5 +1,3 @@
-.. _vga_switcheroo:
-
==
VGA Switcheroo
==
diff --git a/Documentation/gpu/vgaarbiter.rst b/Documentation/gpu/vgaarbiter.rst
new file mode 100644
index ..0b41b051d021
--- /dev/null
+++ b/Documentation/gpu/vgaarbiter.rst
@@ -0,0 +1,191 @@
+===
+VGA Arbiter
+===
+
+Graphic devices are accessed through ranges in I/O or memory space. While most
+modern devices allow relocation of such ranges, some "Legacy" VGA devices
+implemented on PCI will typically have the same "hard-decoded" addresses as
+they did on ISA. For more details see "PCI Bus Binding to IEEE Std 1275-1994
+Standard for Boot (Initialization Configuration) Firmware Revision 2.1"
+Section 7, Legacy Devices.
+
+The Resource Access Control (RAC) module inside the X server [0] existed for
+the legacy VGA arbitration task (besides other bus management tasks) when more
+than one legacy device co-exists on the same machine. But the problem happens
+when these devices are trying to be accessed by different userspace clients
+(e.g. two server in parallel). Their address assignments conflict. Moreover,
+ideally, being a userspace application, it is not the role of the X server to
+control bus resources. Therefore an arbitration scheme outside of the X server
+is needed to control the sharing of these resources. This document introduces
+the operation of the VGA arbiter implemented for the Linux kernel.
+
+vgaarb kernel/userspace ABI
+---
+
+The vgaarb is a module of the Linux Kernel. When it is initially loaded, it
+scans all PCI devices and adds the VGA ones inside the arbitration. The
+arbiter then enables/disables the decoding on different devices of the VGA
+legacy instructions. Devices which do not want/need to use the arbiter may
+explicitly tell it by calling vga_set_legacy_decoding().
+
+The kernel exports a char device interface (/dev/vga_arbiter) to the clients,
+which has the following semantics:
+
+open
+Opens a user instance of the arbiter. By default, it's attached to the
+default VGA device of the system.
+
+close
+Close a user instance. Release locks made by the user
+
+read
+Return a string indicating the status of the target like:
+
+",decodes=,owns=,locks= (ic,mc)"
+
+An IO state string is of the form {io,mem,io+mem,none}, mc and
+ic are respectively mem and io lock counts (for debugging/
+diagnostic only). "decodes" indicate what the card currently
+decodes, "owns" indicates what is currently enabled on it, and
+"locks" indicates what is locked by this card. If the card is
+unplugged, we get "invalid" then for card_ID and an -ENODEV
+error is returned for any command until a new card is targeted.
+
+
+write
+Write a command to the arbiter. List of commands:
+
+target
+switch target to card (see below)
+lock
+acquires locks on target ("none" is an invalid io_state)
+trylock
+non-blocking acquire locks on target (returns EBUSY if
+unsuccessful)
+unlock
+release locks on target
+unlock all
+release all locks on target held by this user (not implemented
+yet)
+decodes
+set the legacy decoding attributes for the card
+
+poll
+
Re: [PATCH 02/10] docs: sphinxify coccinelle.txt and add it to dev-tools
Le 09/08/16 à 01:34, Jonathan Corbet a écrit :
No textual changes have been made, but the formatting has obviously been
tweaked.
Cc: Michal Marek
Cc: Gilles Muller
Cc: Nicolas Palix
Cc: Julia Lawall
Signed-off-by: Jonathan Corbet
Acked-by: Nicolas Palix
---
.../{coccinelle.txt => dev-tools/coccinelle.rst} | 359 +++--
Documentation/dev-tools/tools.rst | 1 +
MAINTAINERS| 2 +-
3 files changed, 192 insertions(+), 170 deletions(-)
rename Documentation/{coccinelle.txt => dev-tools/coccinelle.rst} (56%)
diff --git a/Documentation/coccinelle.txt
b/Documentation/dev-tools/coccinelle.rst
similarity index 56%
rename from Documentation/coccinelle.txt
rename to Documentation/dev-tools/coccinelle.rst
index 01fb1da..4a64b4c 100644
--- a/Documentation/coccinelle.txt
+++ b/Documentation/dev-tools/coccinelle.rst
@@ -1,10 +1,18 @@
-Copyright 2010 Nicolas Palix
-Copyright 2010 Julia Lawall
-Copyright 2010 Gilles Muller
+.. Copyright 2010 Nicolas Palix
+.. Copyright 2010 Julia Lawall
+.. Copyright 2010 Gilles Muller
+.. highlight:: none
- Getting Coccinelle
-
+Coccinelle
+==
+
+Coccinelle is a tool for pattern matching and text transformation that has
+many uses in kernel development, including the application of complex,
+tree-wide patches and detection of problematic programming patterns.
+
+Getting Coccinelle
+---
The semantic patches included in the kernel use features and options
which are provided by Coccinelle version 1.0.0-rc11 and above.
@@ -22,24 +30,23 @@ of many distributions, e.g. :
- NetBSD
- FreeBSD
-
You can get the latest version released from the Coccinelle homepage at
http://coccinelle.lip6.fr/
Information and tips about Coccinelle are also provided on the wiki
pages at http://cocci.ekstranet.diku.dk/wiki/doku.php
-Once you have it, run the following command:
+Once you have it, run the following command::
./configure
make
-as a regular user, and install it with
+as a regular user, and install it with::
sudo make install
- Supplemental documentation
-
+Supplemental documentation
+---
For supplemental documentation refer to the wiki:
@@ -47,49 +54,52 @@ https://bottest.wiki.kernel.org/coccicheck
The wiki documentation always refers to the linux-next version of the script.
- Using Coccinelle on the Linux kernel
-~~
+Using Coccinelle on the Linux kernel
+
A Coccinelle-specific target is defined in the top level
-Makefile. This target is named 'coccicheck' and calls the 'coccicheck'
-front-end in the 'scripts' directory.
+Makefile. This target is named ``coccicheck`` and calls the ``coccicheck``
+front-end in the ``scripts`` directory.
-Four basic modes are defined: patch, report, context, and org. The mode to
-use is specified by setting the MODE variable with 'MODE='.
+Four basic modes are defined: ``patch``, ``report``, ``context``, and
+``org``. The mode to use is specified by setting the MODE variable with
+``MODE=``.
-'patch' proposes a fix, when possible.
+- ``patch`` proposes a fix, when possible.
-'report' generates a list in the following format:
+- ``report`` generates a list in the following format:
file:line:column-column: message
-'context' highlights lines of interest and their context in a
-diff-like style.Lines of interest are indicated with '-'.
+- ``context`` highlights lines of interest and their context in a
+ diff-like style.Lines of interest are indicated with ``-``.
-'org' generates a report in the Org mode format of Emacs.
+- ``org`` generates a report in the Org mode format of Emacs.
Note that not all semantic patches implement all modes. For easy use
of Coccinelle, the default mode is "report".
Two other modes provide some common combinations of these modes.
-'chain' tries the previous modes in the order above until one succeeds.
+- ``chain`` tries the previous modes in the order above until one succeeds.
+
+- ``rep+ctxt`` runs successively the report mode and the context mode.
+ It should be used with the C option (described later)
+ which checks the code on a file basis.
-'rep+ctxt' runs successively the report mode and the context mode.
- It should be used with the C option (described later)
- which checks the code on a file basis.
+Examples
+
-Examples:
- To make a report for every semantic patch, run the following command:
+To make a report for every semantic patch, run the following command::
make coccicheck MODE=report
- To produce patches, run:
+To produce patches, run::
make coccicheck MODE=patch
The coccicheck target applies every semantic patch available in the
-sub-directories of 'scripts/coccinelle' to the entire Linux kernel.
+sub-directories of ``scripts/coc
[PATCH 20/20] vgaarbiter: rst-ifiy and polish kerneldoc
Move the documentation into Documentation/gpu, link it up and pull in
the kernel doc.
No actual text changes except that I did polish the kerneldoc a bit,
especially for vga_client_register().
v2: Remove some rst from vga-switcheroo.rst that I don't understand,
but which seems to be the reason why the new vgaarbiter.rst sometimes
drops out of the sidebar index.
Cc: Jonathan Corbet
Cc: linux-doc@vger.kernel.org
Signed-off-by: Daniel Vetter
---
Documentation/gpu/index.rst | 1 +
Documentation/gpu/vga-switcheroo.rst | 2 -
Documentation/gpu/vgaarbiter.rst | 194 +++
Documentation/vgaarbiter.txt | 192 --
drivers/gpu/vga/vgaarb.c | 103 ++-
include/linux/vgaarb.h | 128 +++
6 files changed, 312 insertions(+), 308 deletions(-)
create mode 100644 Documentation/gpu/vgaarbiter.rst
delete mode 100644 Documentation/vgaarbiter.txt
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index fcac0fa72056..ba92f45abb76 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -12,3 +12,4 @@ Linux GPU Driver Developer's Guide
drm-uapi
i915
vga-switcheroo
+ vgaarbiter
diff --git a/Documentation/gpu/vga-switcheroo.rst
b/Documentation/gpu/vga-switcheroo.rst
index cbbdb994f1dd..463a74fc40d1 100644
--- a/Documentation/gpu/vga-switcheroo.rst
+++ b/Documentation/gpu/vga-switcheroo.rst
@@ -1,5 +1,3 @@
-.. _vga_switcheroo:
-
==
VGA Switcheroo
==
diff --git a/Documentation/gpu/vgaarbiter.rst b/Documentation/gpu/vgaarbiter.rst
new file mode 100644
index ..abab2f488338
--- /dev/null
+++ b/Documentation/gpu/vgaarbiter.rst
@@ -0,0 +1,194 @@
+===
+VGA Arbiter
+===
+
+Graphic devices are accessed through ranges in I/O or memory space. While most
+modern devices allow relocation of such ranges, some "Legacy" VGA devices
+implemented on PCI will typically have the same "hard-decoded" addresses as
+they did on ISA. For more details see "PCI Bus Binding to IEEE Std 1275-1994
+Standard for Boot (Initialization Configuration) Firmware Revision 2.1"
+Section 7, Legacy Devices.
+
+The Resource Access Control (RAC) module inside the X server [0] existed for
+the legacy VGA arbitration task (besides other bus management tasks) when more
+than one legacy device co-exists on the same machine. But the problem happens
+when these devices are trying to be accessed by different userspace clients
+(e.g. two server in parallel). Their address assignments conflict. Moreover,
+ideally, being a userspace application, it is not the role of the X server to
+control bus resources. Therefore an arbitration scheme outside of the X server
+is needed to control the sharing of these resources. This document introduces
+the operation of the VGA arbiter implemented for the Linux kernel.
+
+Details and Theory of Operation
+===
+
+vgaarb
+--
+
+The vgaarb is a module of the Linux Kernel. When it is initially loaded, it
+scans all PCI devices and adds the VGA ones inside the arbitration. The
+arbiter then enables/disables the decoding on different devices of the VGA
+legacy instructions. Devices which do not want/need to use the arbiter may
+explicitly tell it by calling vga_set_legacy_decoding().
+
+The kernel exports a char device interface (/dev/vga_arbiter) to the clients,
+which has the following semantics:
+
+open
+Opens a user instance of the arbiter. By default, it's attached to the
+default VGA device of the system.
+
+close
+Close a user instance. Release locks made by the user
+
+read
+Return a string indicating the status of the target like:
+
+",decodes=,owns=,locks= (ic,mc)"
+
+An IO state string is of the form {io,mem,io+mem,none}, mc and
+ic are respectively mem and io lock counts (for debugging/
+diagnostic only). "decodes" indicate what the card currently
+decodes, "owns" indicates what is currently enabled on it, and
+"locks" indicates what is locked by this card. If the card is
+unplugged, we get "invalid" then for card_ID and an -ENODEV
+error is returned for any command until a new card is targeted.
+
+
+write
+Write a command to the arbiter. List of commands:
+
+target
+switch target to card (see below)
+lock
+acquires locks on target ("none" is an invalid io_state)
+trylock
+non-blocking acquire locks on target (returns EBUSY if
+unsuccessful)
+unlock
+release locks on target
+unlock all
+release all locks on target held by this user (not implemented
+yet)
+decodes
+set the legacy decoding attributes for the card
+
+poll
+event if something changes
[PATCH 01/20] drm/doc: Fix more kerneldoc/sphinx warnings
These are the leftovers I could only track down using keep_warnings =
True. For some of them we might want to update our style guide on how
to reference structures and constants, not sure ...
Cc: Markus Heiser
Cc: Jonathan Corbet
Cc: linux-doc@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 4 ++--
drivers/gpu/drm/drm_fb_helper.c | 2 +-
drivers/gpu/drm/drm_irq.c | 8 +++
drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
drivers/gpu/drm/i915/i915_vgpu.c| 42 -
drivers/gpu/drm/i915/intel_audio.c | 6 ++---
drivers/gpu/drm/i915/intel_guc_fwif.h | 5 ++--
include/drm/drm_crtc.h | 8 +++
include/drm/drm_gem.h | 4 ++--
9 files changed, 41 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3d03eb1e3b63..ad38a8a31898 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1272,7 +1272,7 @@ static unsigned int drm_num_planes(struct drm_device *dev)
* @plane: plane object to init
* @possible_crtcs: bitmask of possible CRTCs
* @funcs: callbacks for the new plane
- * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @formats: array of supported formats (DRM_FORMAT\_\*)
* @format_count: number of elements in @formats
* @type: type of plane (overlay, primary, cursor)
* @name: printf style format string for the plane name, or NULL for default
name
@@ -1387,7 +1387,7 @@ static void drm_plane_unregister_all(struct drm_device
*dev)
* @plane: plane object to init
* @possible_crtcs: bitmask of possible CRTCs
* @funcs: callbacks for the new plane
- * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @formats: array of supported formats (DRM_FORMAT\_\*)
* @format_count: number of elements in @formats
* @is_primary: plane type (primary vs overlay)
*
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ce54e985d91b..95f405e04f5f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2194,7 +2194,7 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
* @fb_helper: the drm_fb_helper
*
* Scan the connectors attached to the fb_helper and try to put together a
- * setup after *notification of a change in output configuration.
+ * setup after notification of a change in output configuration.
*
* Called at runtime, takes the mode config locks to be able to check/change
the
* modeset configuration. Must be run from process context (which usually means
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 9bdce1cb6c5c..10611a936059 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -713,10 +713,10 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
* Negative value on error, failure or if not supported in current
* video mode:
*
- * -EINVAL - Invalid CRTC.
- * -EAGAIN - Temporary unavailable, e.g., called before initial modeset.
- * -ENOTSUPP - Function not supported in current display mode.
- * -EIO - Failed, e.g., due to failed scanout position query.
+ * -EINVALInvalid CRTC.
+ * -EAGAINTemporary unavailable, e.g., called before initial modeset.
+ * -ENOTSUPP Function not supported in current display mode.
+ * -EIO Failed, e.g., due to failed scanout position query.
*
* Returns or'ed positive status flags on success:
*
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 0db36d27e90b..4e1de31f072b 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -152,7 +152,7 @@ static const struct drm_plane_funcs
drm_simple_kms_plane_funcs = {
* @dev: DRM device
* @pipe: simple display pipe object to initialize
* @funcs: callbacks for the display pipe (optional)
- * @formats: array of supported formats (%DRM_FORMAT_*)
+ * @formats: array of supported formats (DRM_FORMAT\_\*)
* @format_count: number of elements in @formats
* @connector: connector to attach and register
*
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 142bac976919..ca2e91259948 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -156,27 +156,27 @@ static int vgt_balloon_space(struct drm_mm *mm,
* host point of view, the graphic address space is partitioned by multiple
* vGPUs in different VMs. ::
*
- *vGPU1 view Host view
- * 0 --> +---+ +---+
- * ^ |###| | vGPU3 |
- * | |###| +---+
- * | |###| | vGPU2 |
- * | +---+ +---+
- *mappable GM| available | ==> | vGPU1 |
- * | +---+ +---+
- *
[PATCH 00/20] more drm doc work
First part is just a bit of rst fallout to make drm doc builds warning free. But then I started to split out parts of drm_crtc into their own files. framebuffers and connectors are done, next up on my plans are encoders, and then the base stuff around drm_mode_object, properties and blobs. I think I'll leave untangle the plane and crtc mess (including their properties) for last. Getting this out since the extraction patches are quite a pain to rebase ;-) I've mentioned that the new toolchain is awesime, right? Cheers, Daniel Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Daniel Vetter (20): drm/doc: Fix more kerneldoc/sphinx warnings drm/doc: Light drm-kms-helper.rst cleanup drm/kms-helpers: Extract drm_modeset_helper.[hc] drm/doc: Reorg drm-mm.rst drm/doc: Reorg for drm-kms.rst drm/etnaviv: Don't set drm_device->platformdev drm/hisilicon: Don't set drm_device->platformdev drm/doc: Remove outdated FIXME for the page_flip callback drm/kms: Nuke dirty_info property drm/doc: Include drm_atomic.h drm: Extract drm_framebuffer.[hc] drm/doc: Update drm_framebuffer docs drm: Export drm_property_replace_global_blob drm: Extract drm_connector.[hc] drm/doc: Include new drm_blend.c drm: Don't export dp-aux devnode functions drm: Update connector documentation drm: Remove display_info->min/max_(h|v)max drm: docume drm_display_info vgaarbiter: rst-ifiy and polish kerneldoc Documentation/gpu/drm-kms-helpers.rst | 211 +- Documentation/gpu/drm-kms.rst | 270 +-- Documentation/gpu/drm-mm.rst| 58 +- Documentation/gpu/index.rst |1 + Documentation/gpu/vga-switcheroo.rst|2 - Documentation/gpu/vgaarbiter.rst| 194 ++ Documentation/vgaarbiter.txt| 192 -- drivers/gpu/drm/Makefile|5 +- drivers/gpu/drm/drm_atomic_helper.c |2 +- drivers/gpu/drm/drm_blend.c |8 +- drivers/gpu/drm/drm_connector.c | 1123 +++ drivers/gpu/drm/drm_crtc.c | 2372 ++- drivers/gpu/drm/drm_crtc_helper.c | 56 - drivers/gpu/drm/drm_crtc_helper_internal.h | 58 + drivers/gpu/drm/drm_crtc_internal.h | 70 +- drivers/gpu/drm/drm_dp_aux_dev.c| 19 +- drivers/gpu/drm/drm_dp_helper.c |3 +- drivers/gpu/drm/drm_edid.c | 23 +- drivers/gpu/drm/drm_fb_helper.c |2 +- drivers/gpu/drm/drm_framebuffer.c | 862 drivers/gpu/drm/drm_irq.c |8 +- drivers/gpu/drm/drm_kms_helper_common.c |3 +- drivers/gpu/drm/drm_modeset_helper.c| 153 ++ drivers/gpu/drm/drm_plane_helper.c | 66 - drivers/gpu/drm/drm_simple_kms_helper.c |2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c |2 - drivers/gpu/drm/gma500/cdv_intel_lvds.c |8 - drivers/gpu/drm/gma500/mdfld_dsi_output.c |5 - drivers/gpu/drm/gma500/psb_intel_lvds.c |9 - drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 10 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |6 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |4 +- drivers/gpu/drm/i915/i915_vgpu.c| 42 +- drivers/gpu/drm/i915/intel_audio.c |6 +- drivers/gpu/drm/i915/intel_guc_fwif.h |5 +- drivers/gpu/drm/i915/intel_lvds.c | 11 - drivers/gpu/drm/udl/udl_connector.c |3 - drivers/gpu/drm/udl/udl_modeset.c |2 - drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |9 - drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 11 - drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|7 - drivers/gpu/vga/vgaarb.c| 103 +- include/drm/drm_atomic_helper.h |2 + include/drm/drm_connector.h | 747 +++ include/drm/drm_crtc.h | 792 +--- include/drm/drm_crtc_helper.h |6 +- include/drm/drm_dp_aux_dev.h| 62 - include/drm/drm_fb_helper.h |1 - include/drm/drm_framebuffer.h | 238 +++ include/drm/drm_gem.h |4 +- include/drm/drm_modes.h | 18 +- include/drm/drm_modeset.h | 70 + include/drm/drm_modeset_helper.h| 36 + include/drm/drm_plane_helper.h |4 +- include/linux/vgaarb.h | 128 +- 55 files changed, 4131 insertions(+), 3983 deletions(-) create mode 100644 Documentation/gpu/vgaarbiter.rst delete mode 100644 Documentation/vgaarbiter.txt create mode 100644 drivers/gpu/drm/drm_connector.c create mode 100644 drivers/gpu/drm/drm_crtc_helper_internal.h create mode 100644
Re: [PATCH 03/10] docs: sphinxify sparse.txt and move to dev-tools
On Tue, Aug 9, 2016 at 10:31 AM, Christoph Hellwig wrote: > On Tue, Aug 09, 2016 at 10:28:38AM +0200, Daniel Vetter wrote: >> The point is to make the docs more discoverable by being able to >> cross-link them. Old hats like us don't need that, but it definitely >> has value in bringing new folks on board. > > But do that in a way that keeps the old hats happy. The crazy use of > punctuation and the weird quotes is an absolute no-go. We've been bikeshedding on the exact kind of light markup since over a year now. Current one is rst, with pretty much uniform support among the folks who cared that it's the least offensive of the bunch. I think it can be made slightly less invasive by trading in a bit of the noise in the sourc for warnings from the html generators (and less pretty html output), but that's pretty close to nothing already. The only other option with less markup is markdown, but the only reason it's less invasive is that I can't really do anything at all. Definitely no sensible way to pull in things like kernel-doc or the uapi headers media needs. Jon, can you please try to respin the patch with fewer changes, but (probably) more rst warnings? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/10] docs: sphinxify kasan.txt and move to dev-tools
On Tue, Aug 9, 2016 at 1:34 AM, Jonathan Corbet wrote: > No textual changes beyond formatting. > > Cc: Andrey Ryabinin > Cc: Alexander Potapenko > Cc: Dmitry Vyukov > Signed-off-by: Jonathan Corbet Acked-by: Alexander Potapenko > --- > Documentation/dev-tools/kasan.rst | 173 > ++ > Documentation/dev-tools/tools.rst | 1 + > Documentation/kasan.txt | 171 - > MAINTAINERS | 2 +- > 4 files changed, 175 insertions(+), 172 deletions(-) > create mode 100644 Documentation/dev-tools/kasan.rst > delete mode 100644 Documentation/kasan.txt > > diff --git a/Documentation/dev-tools/kasan.rst > b/Documentation/dev-tools/kasan.rst > new file mode 100644 > index 000..948d243 > --- /dev/null > +++ b/Documentation/dev-tools/kasan.rst > @@ -0,0 +1,173 @@ > +The Kernel Address Sanitizer (KASAN) > + > + > +Overview > + > + > +KernelAddressSANitizer (KASAN) is a dynamic memory error detector. It > provides > +a fast and comprehensive solution for finding use-after-free and > out-of-bounds > +bugs. > + > +KASAN uses compile-time instrumentation for checking every memory access, > +therefore you will need a GCC version 4.9.2 or later. GCC 5.0 or later is > +required for detection of out-of-bounds accesses to stack or global > variables. > + > +Currently KASAN is supported only for x86_64 architecture. > + > +Usage > +- > + > +To enable KASAN configure kernel with:: > + > + CONFIG_KASAN = y > + > +and choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE. Outline and > +inline are compiler instrumentation types. The former produces smaller binary > +the latter is 1.1 - 2 times faster. Inline instrumentation requires a GCC > +version 5.0 or later. > + > +KASAN works with both SLUB and SLAB memory allocators. > +For better bug detection and nicer reporting, enable CONFIG_STACKTRACE. > + > +To disable instrumentation for specific files or directories, add a line > +similar to the following to the respective kernel Makefile: > + > +- For a single file (e.g. main.o):: > + > +KASAN_SANITIZE_main.o := n > + > +- For all files in one directory:: > + > +KASAN_SANITIZE := n > + > +Error reports > +~ > + > +A typical out of bounds access report looks like this:: > + > +== > +BUG: AddressSanitizer: out of bounds access in > kmalloc_oob_right+0x65/0x75 [test_kasan] at addr 8800693bc5d3 > +Write of size 1 by task modprobe/1689 > + > = > +BUG kmalloc-128 (Not tainted): kasan error > + > - > + > +Disabling lock debugging due to kernel taint > +INFO: Allocated in kmalloc_oob_right+0x3d/0x75 [test_kasan] age=0 cpu=0 > pid=1689 > + __slab_alloc+0x4b4/0x4f0 > + kmem_cache_alloc_trace+0x10b/0x190 > + kmalloc_oob_right+0x3d/0x75 [test_kasan] > + init_module+0x9/0x47 [test_kasan] > + do_one_initcall+0x99/0x200 > + load_module+0x2cb3/0x3b20 > + SyS_finit_module+0x76/0x80 > + system_call_fastpath+0x12/0x17 > +INFO: Slab 0xea0001a4ef00 objects=17 used=7 fp=0x8800693bd728 > flags=0x1004080 > +INFO: Object 0x8800693bc558 @offset=1368 fp=0x8800693bc720 > + > +Bytes b4 8800693bc548: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a > 5a > +Object 8800693bc558: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > +Object 8800693bc568: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > +Object 8800693bc578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > +Object 8800693bc588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > +Object 8800693bc598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > +Object 8800693bc5a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > +Object 8800693bc5b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > > +Object 8800693bc5c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 > kkk. > +Redzone 8800693bc5d8: cc cc cc cc cc cc cc cc > > +Padding 8800693bc718: 5a 5a 5a 5a 5a 5a 5a 5a > > +CPU: 0 PID: 1689 Comm: modprobe Tainted: GB 3.18.0-rc1-mm1+ > #98 > +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 > + 8800693bc000 8800693bc558 88006923bb78 > + 81cc68ae 00f3 88006d407600 88006923bba8 > + 811fd848 8800
Re: [PATCH 00/10] [RFC] Sphinxify and coalesce development-tool documents
On Tue, 09 Aug 2016, Jonathan Corbet wrote: > This series of patches collects a number of documents related to kernel > development tools, converts them to the Sphinx format, and puts them > together into the dev-tools directory. The resulting formatted > documentation can be seen at: > > http://static.lwn.net/kerneldoc/dev-tools/tools.html > > I've not made any textual changes, so this is far from having created a > truly coherent document, but it is a step in the right direction and shows > the sort of change I have in mind for the documentation directory in > general. FWIW, the whole series is wholeheartedly Acked-by: Jani Nikula -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] docs: sphinxify sparse.txt and move to dev-tools
On Tue, Aug 09, 2016 at 10:28:38AM +0200, Daniel Vetter wrote: > The point is to make the docs more discoverable by being able to > cross-link them. Old hats like us don't need that, but it definitely > has value in bringing new folks on board. But do that in a way that keeps the old hats happy. The crazy use of punctuation and the weird quotes is an absolute no-go. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] docs: sphinxify sparse.txt and move to dev-tools
On Tue, Aug 9, 2016 at 10:22 AM, Christoph Hellwig wrote: > On Tue, Aug 09, 2016 at 11:19:50AM +0300, Jani Nikula wrote: >> On Tue, 09 Aug 2016, Christoph Hellwig wrote: >> > The ugly format is a major regression over a proper simple text >> > file. What's the point? >> >> Major regression? Please be reasonable. >> >> I think the changes are rather small, and it's a fair compromise between >> a simple text file and one that can be used to generate pretty >> documentation [1]. > > It's a lot less pretty to read - it look like a cat threw up to be > specific. The point of the Document is to read it quickly in the kernel > tree. If you want fancy websites write a separate document. > >> [1] http://static.lwn.net/kerneldoc/dev-tools/sparse.html > > And I wouldn't exactly call that pretty. There is no value add > over a simple text file here, and it requires a browser to not look > ugly instead of a text editor, which is a giant usablity regression. The point is to make the docs more discoverable by being able to cross-link them. Old hats like us don't need that, but it definitely has value in bringing new folks on board. And yes I want that, at least for everything that's at least half-relevant to drm/gpu/i915 topics. And given that we just started on a large-scale effort to roll out rcu in our driver (besides all the other bits we're using) that's pretty much everything. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] docs: sphinxify sparse.txt and move to dev-tools
On Tue, Aug 09, 2016 at 11:19:50AM +0300, Jani Nikula wrote: > On Tue, 09 Aug 2016, Christoph Hellwig wrote: > > The ugly format is a major regression over a proper simple text > > file. What's the point? > > Major regression? Please be reasonable. > > I think the changes are rather small, and it's a fair compromise between > a simple text file and one that can be used to generate pretty > documentation [1]. It's a lot less pretty to read - it look like a cat threw up to be specific. The point of the Document is to read it quickly in the kernel tree. If you want fancy websites write a separate document. > [1] http://static.lwn.net/kerneldoc/dev-tools/sparse.html And I wouldn't exactly call that pretty. There is no value add over a simple text file here, and it requires a browser to not look ugly instead of a text editor, which is a giant usablity regression. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] docs: sphinxify sparse.txt and move to dev-tools
On Tue, 09 Aug 2016, Christoph Hellwig wrote: > The ugly format is a major regression over a proper simple text > file. What's the point? Major regression? Please be reasonable. I think the changes are rather small, and it's a fair compromise between a simple text file and one that can be used to generate pretty documentation [1]. BR, Jani. [1] http://static.lwn.net/kerneldoc/dev-tools/sparse.html -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] docs: sphinxify sparse.txt and move to dev-tools
The ugly format is a major regression over a proper simple text file. What's the point? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] docs: sphinxify kmemcheck.txt and move to dev-tools
Hi, On 9 August 2016 at 01:35, Jonathan Corbet wrote: > +The shadow bytemap dump legend is as follows: > + > +- i: initialized > +- u: uninitialized > +- a: unallocated (memory has been allocated by the slab layer, but has not > + yet been handed off to anybody) > +- f: freed (memory has been allocated by the slab layer, but has been freed > + by the previous owner) Maybe you want ``i``, ``u``, etc. here? The rest looks good to me. Thanks! Although I'm not sure how relevant kmemcheck is anymore with KASAN being able to do almost all (if not all) that kmemcheck does, and better. Oh well, I thought the doc wasn't bad in any case ;-) Vegard -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
