We get a new link error in allmodconfig kernels after ftgmac100
started using the ncsi helpers:
ERROR: "ncsi_vlan_rx_kill_vid" [drivers/net/ethernet/faraday/ftgmac100.ko] undefined!
ERROR: "ncsi_vlan_rx_add_vid" [drivers/net/ethernet/faraday/ftgmac100.ko] undefined!
Related to that, we get another error when CONFIG_NET_NCSI is disabled:
drivers/net/ethernet/faraday/ftgmac100.c:1626:25: error: 'ncsi_vlan_rx_add_vid' undeclared here (not in a function); did you mean 'ncsi_start_dev'?
drivers/net/ethernet/faraday/ftgmac100.c:1627:26: error: 'ncsi_vlan_rx_kill_vid' undeclared here (not in a function); did you mean 'ncsi_vlan_rx_add_vid'?
This fixes both problems at once, using a 'static inline' stub helper
for the disabled case, and exporting the functions when they are present.
Fixes: 51564585d8 ("ftgmac100: Support NCSI VLAN filtering when available")
Fixes: 21acf63013 ("net/ncsi: Configure VLAN tag filter")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
When disabling one trace event, the RECORDED_TGID flag in the event
file is not correctly cleared. It's clearing RECORDED_CMD flag when
it should clear RECORDED_TGID flag.
Link: http://lkml.kernel.org/r/1504589806-8425-1-git-send-email-chuhu@redhat.com
Cc: Joel Fernandes <joelaf@google.com>
Cc: stable@vger.kernel.org
Fixes: d914ba37d7 ("tracing: Add support for recording tgid of tasks")
Signed-off-by: Chunyu Hu <chuhu@redhat.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
trace_printk() uses 4 buffers, one for each context (normal, softirq, irq
and NMI), such that it does not need to worry about one context preempting
the other. There's a nesting counter that gets incremented to figure out
which buffer to use. If the context gets preempted by another context which
calls trace_printk() it will increment the counter and use the next buffer,
and restore the counter when it is finished.
The problem is that gcc may optimize the modification of the buffer nesting
counter and it may not be incremented in memory before the buffer is used.
If this happens, and the context gets interrupted by another context, it
could pick the same buffer and corrupt the one that is being used.
Compiler barriers need to be added after the nesting variable is incremented
and before it is decremented to prevent usage of the context buffers by more
than one context at the same time.
Cc: Andy Lutomirski <luto@kernel.org>
Cc: stable@vger.kernel.org
Fixes: e2ace00117 ("tracing: Choose static tp_printk buffer by explicit nesting count")
Hat-tip-to: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
When migrating guests around we need to know the active priorities to
ensure functional virtual interrupt prioritization by the GIC.
This commit clarifies the API and how active priorities of interrupts in
different groups are represented, and implements the accessor functions
for the uaccess register range.
We live with a slight layering violation in accessing GICv3 data
structures from vgic-mmio-v2.c, because anything else just adds too much
complexity for us to deal with (it's not like there's a benefit
elsewhere in the code of an intermediate representation as is the case
with the VMCR). We accept this, because while doing v3 processing from
a file named something-v2.c can look strange at first, this really is
specific to dealing with the user space interface for something that
looks like a GICv2.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
As we are about to access the APRs from the GICv2 uaccess interface,
make this logic generally available.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
For unknown reasons, the its_ite data structure carries an "lpi" field
which contains the intid of the LPI. This is an obvious duplication
of the vgic_irq->intid field, so let's fix the only user and remove
the now useless field.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
vgic_debug_seq_ops and file_operations are not supposed to change
at runtime and none of the structures is modified.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
The ARM-ARM has two bits in the ESR/HSR relevant to external aborts.
A range of {I,D}FSC values (of which bit 5 is always set) and bit 9 'EA'
which provides:
> an IMPLEMENTATION DEFINED classification of External Aborts.
This bit is in addition to the {I,D}FSC range, and has an implementation
defined meaning. KVM should always ignore this bit when handling external
aborts from a guest.
Remove the ESR_ELx_EA definition and rewrite its helper
kvm_vcpu_dabt_isextabt() to check the {I,D}FSC range. This merges
kvm_vcpu_dabt_isextabt() and the recently added is_abort_sea() helper.
CC: Tyler Baicar <tbaicar@codeaurora.org>
Reported-by: gengdongjiu <gengdj.1984@gmail.com>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
Tweak a small number of status "ok" lines in a single file under
/drivers/of/ to use the proper DTSpec 0.1 spelling of "okay".
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Rob Herring <robh@kernel.org>
Pretty much any node can have a status property, so it doesn't need to
be in examples.
Converted with the following command and removed examples with SoC and
board specific splits:
git grep -l -E 'status.*=.*' Documentation/devicetree/ | xargs sed -i -E '/\sstatus.*=.*"(disabled|ok|okay)/d'
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
There are no HT/VHT capabilities in cfg80211_ap_settings::beacon_ies,
these should be looked for in beacon's tail instead.
Fixes: 66cd794e3c ("nl80211: add HT/VHT capabilities to AP parameters")
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When HW ROC is supported it is possible that after the HW notified
that the ROC has started, the ROC was cancelled and another ROC was
added while the hw_roc_start worker is waiting on the mutex (since
cancelling the ROC and adding another one also holds the same mutex).
As a result, the hw_roc_start worker will continue to run after the
new ROC is added but before it is actually started by the HW.
This may result in notifying userspace that the ROC has started before
it actually does, or in case of management tx ROC, in an attempt to
tx while not on the right channel.
In addition, when the driver will notify mac80211 that the second ROC
has started, mac80211 will warn that this ROC has already been
notified.
Fix this by flushing the hw_roc_start work before cancelling an ROC.
Cc: stable@vger.kernel.org
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since drv_wake_tx_queue() is normally called in the TX path, which
is already in an RCU critical section, we should call it the same
way in the aggregation code path, so if the driver expects to be
able to use RCU, it'll already be protected without having to enter
a nested critical section.
Additionally, disable soft-IRQs, since not doing so could cause
issues in a driver that relies on them already being disabled like
in the other path.
Fixes: ba8c3d6f16 ("mac80211: add an intermediate software queue implementation")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In the process of normalizing audit log messages, it was noticed that the AVC
initialization code registered an audit log KERNEL record that didn't fit the
standard format. In the process of attempting to normalize it it was
determined that this record was not even necessary. Remove it.
Ref: http://marc.info/?l=selinux&m=149614868525826&w=2
See: https://github.com/linux-audit/audit-kernel/issues/48
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: Steve Grubb <sgrubb@redhat.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Commit 2115bb250f ("audit: Use timespec64 to represent audit timestamps")
noted that audit timestamps were not y2038 safe and used a 64-bit
timestamp. In itself, this makes sense but the conversion was from
CURRENT_TIME to ktime_get_real_ts64() which is a heavier call to record
an accurate timestamp which is required in some, but not all, cases. The
impact is that when auditd is running without any rules that all syscalls
have higher overhead. This is visible in the sysbench-thread benchmark as
a 11.5% performance hit. That benchmark is dumb as rocks but it's also
visible in redis as an 8-10% hit on all operations which is of greater
concern. It is somewhat stupid of audit to track syscalls without any
rules related to syscalls but that is how it behaves.
The overhead can be directly measured with perf comparing 4.9 with 4.12
4.9
7.76% sysbench [kernel.vmlinux] [k] __schedule
7.62% sysbench [kernel.vmlinux] [k] _raw_spin_lock
7.37% sysbench libpthread-2.22.so [.] __lll_lock_elision
7.29% sysbench [kernel.vmlinux] [.] syscall_return_via_sysret
6.59% sysbench [kernel.vmlinux] [k] native_sched_clock
5.21% sysbench libc-2.22.so [.] __sched_yield
4.38% sysbench [kernel.vmlinux] [k] entry_SYSCALL_64
4.28% sysbench [kernel.vmlinux] [k] do_syscall_64
3.49% sysbench libpthread-2.22.so [.] __lll_unlock_elision
3.13% sysbench [kernel.vmlinux] [k] __audit_syscall_exit
2.87% sysbench [kernel.vmlinux] [k] update_curr
2.73% sysbench [kernel.vmlinux] [k] pick_next_task_fair
2.31% sysbench [kernel.vmlinux] [k] syscall_trace_enter
2.20% sysbench [kernel.vmlinux] [k] __audit_syscall_entry
.....
0.00% swapper [kernel.vmlinux] [k] read_tsc
4.12
7.84% sysbench [kernel.vmlinux] [k] __schedule
7.05% sysbench [kernel.vmlinux] [k] _raw_spin_lock
6.57% sysbench libpthread-2.22.so [.] __lll_lock_elision
6.50% sysbench [kernel.vmlinux] [.] syscall_return_via_sysret
5.95% sysbench [kernel.vmlinux] [k] read_tsc
5.71% sysbench [kernel.vmlinux] [k] native_sched_clock
4.78% sysbench libc-2.22.so [.] __sched_yield
4.30% sysbench [kernel.vmlinux] [k] entry_SYSCALL_64
3.94% sysbench [kernel.vmlinux] [k] do_syscall_64
3.37% sysbench libpthread-2.22.so [.] __lll_unlock_elision
3.32% sysbench [kernel.vmlinux] [k] __audit_syscall_exit
2.91% sysbench [kernel.vmlinux] [k] __getnstimeofday64
Note the additional overhead from read_tsc which goes from 0% to 5.95%.
This is on a single-socket E3-1230 but similar overheads have been measured
on an older machine which the patch also eliminates.
The patch in question has no explanation as to why a fully-accurate timestamp
is required and is likely an oversight. Using a coarser, but monotically
increasing, timestamp the overhead can be eliminated. While it can be
worked around by configuring or disabling audit, it's tricky enough to
detect that a kernel fix is justified. With this patch, we see the following;
sysbenchthread
4.9.0 4.12.0 4.12.0
vanilla vanilla coarse-v1r1
Amean 1 1.49 ( 0.00%) 1.66 ( -11.42%) 1.51 ( -1.34%)
Amean 3 1.48 ( 0.00%) 1.65 ( -11.45%) 1.50 ( -0.96%)
Amean 5 1.49 ( 0.00%) 1.67 ( -12.31%) 1.51 ( -1.83%)
Amean 7 1.49 ( 0.00%) 1.66 ( -11.72%) 1.50 ( -0.67%)
Amean 12 1.48 ( 0.00%) 1.65 ( -11.57%) 1.52 ( -2.89%)
Amean 16 1.49 ( 0.00%) 1.65 ( -11.13%) 1.51 ( -1.73%)
The benchmark is reporting the time required for different thread counts to
lock/unlock a private mutex which, while dense, demonstrates the syscall
overhead. This is showing that 4.12 took a 11-12% hit but the overhead is
almost eliminated by the patch. While the variance is not reported here,
it's well within the noise with the patch applied.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Deepa Dinamani <deepa.kernel@gmail.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Ralf Baechle recently merged a change to stop explicitly handling this
case on mips, as the case is impossible. Unfortunately when the code
in force_fcr31_sig to not use siginfo but a simple interger variable gcc
starts warning about an unitialized variable.
So add a return statement so gcc knows the code never attempts to use
the impossible value.
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Commit 0a94efb5ac ("workqueue: implicit ordered attribute should be
overridable") introduced a __WQ_ORDERED_EXPLICIT flag but gave it the
same value as __WQ_LEGACY. I don't believe these were intended to
mean the same thing, so renumber __WQ_ORDERED_EXPLICIT.
Fixes: 0a94efb5ac ("workqueue: implicit ordered attribute should be ...")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: stable@vger.kernel.org # v4.13
Signed-off-by: Tejun Heo <tj@kernel.org>
The VIOS LTH17 Cherry Trail bases netbook has its LCD panel mounted
rotated 90 degrees, add a DMI quirk for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: Daniel Drake <drake@endlessm.com>
[b.zolnierkie: ported over fbcon changes]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Those two ioctls were never used within the Kernel. Still, there
used to have compat32 code there (and an if #0 block at the core).
Get rid of them.
Fixes: 286fe1ca3f ("media: dmx.h: get rid of DMX_GET_CAPS")
Fixes: 13adefbe9e ("media: dmx.h: get rid of DMX_SET_SOURCE")
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Without CONFIG_BLK_DEV_BSGLIB, we get a link error here:
drivers/scsi/scsi_transport_sas.o: In function `sas_bsg_initialize':
scsi_transport_sas.c:(.text+0xcc0): undefined reference to `bsg_setup_queue'
scsi_transport_sas.c:(.text+0xd10): undefined reference to `bsg_setup_queue'
drivers/scsi/scsi_transport_sas.o: In function `sas_smp_dispatch':
scsi_transport_sas.c:(.text+0xe8c): undefined reference to `bsg_job_done'
This modifies the Kconfig 'select' statement accordingly, and matching
what we do for the other two scsi_transport implementations that use
bsglib.
Fixes: 651a013649 ("scsi: scsi_transport_sas: switch to bsg-lib for SMP passthrough")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
A patch I wrote myself several years ago removed SCSI target support
from the code under drivers/scsi. That patch removed the code that sets
uspace_req_q to a non-NULL value. Hence also remove the code that
depends on uspace_req_q != NULL.
References: commit 0664652513 ("tgt: removal")
Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This reverts commit d2180e0cf7.
The commit was flawed in that if the device_node pointers are different,
then in fact a different device is present and the device node could be
different in ways other than full_name.
As Frank Rowand explained:
"When an overlay (1) is removed, all uses and references to the nodes and
properties in that overlay are no longer valid. Any driver that uses any
information from the overlay _must_ stop using any data from the overlay.
Any driver that is bound to a new node in the overlay _must_ unbind. Any
driver that became bound to a pre-existing node that was modified by the
overlay (became bound after the overlay was applied) _must_ adjust itself
to account for any changes to that node when the overlay is removed. One
way to do this is to unbind when notified that the overlay is about to
be removed, then to re-bind after the overlay is completely removed.
If an overlay (2) is subsequently applied, a node with the same
full_name as from overlay (1) may exist. There is no guarantee
that overlay (1) and overlay (2) are the same overlay, even if
that node has the same full_name in both cases."
Also, there's not sufficient overlay support in mainline to actually
remove and re-apply an overlay to hit this condition as overlays can
only be applied from in kernel APIs.
Fixes: d2180e0cf7 ("[media] v4l: async: make v4l2 coexist with devicetree nodes in a dt overlay")
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Frank Rowand <frowand.list@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Javi Merino <javi.merino@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The calloc function returns either a null pointer or a pointer to the
allocated space. Add the second case that is missed.
Fixes: da22013f7d ("atomisp: remove indirection from sh_css_malloc")
Signed-off-by: Sergei A. Trusov <sergei.a.trusov@ya.ru>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This reverts commit 5be2b76a9c.
Only when the lirc device is freed, should we drop our reference to
rc_dev, else we the rc_dev is freed to early. If userspace has
a file descriptor open during unplug, it goes bang.
==================================================================
BUG: KASAN: use-after-free in __lock_acquire+0x7bb/0x1e10
Read of size 8 at addr ffff8801d7d61ed0 by task ir-rec/2609
-snip-
mutex_lock_nested+0x1b/0x20
? mutex_lock_nested+0x1b/0x20
rc_close.part.6+0x20/0x60 [rc_core]
rc_close+0x13/0x20 [rc_core]
lirc_dev_fop_close+0x62/0xd0 [lirc_dev]
__fput+0x236/0x410
? fput+0xb0/0xb0
? do_raw_spin_trylock+0x110/0x110
? set_rq_offline.part.70+0xa0/0xa0
____fput+0xe/0x10
task_work_run+0x116/0x180
? task_work_cancel+0x170/0x170
? _raw_spin_unlock+0x27/0x40
? switch_task_namespaces+0x5f/0x90
do_exit+0x68b/0xe80
Cc: stable@vger.kernel.org # For Kernel 4.13
Fixes: 5be2b76a9c ("[media] lirc_dev: remove superfluous get/put_device() calls")
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Avoid this warning:
/devel/v4l/docs/Documentation/media/v4l-drivers/qcom_camss.rst:: WARNING: document isn't included in any toctree
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
A recent change interprets the return code of dma_init_coherent_memory
as an error value, but it is instead a boolean, where 'true' indicates
success. This leads causes the caller to always do the wrong thing,
and also triggers a compile-time warning about it:
drivers/base/dma-coherent.c: In function 'dma_declare_coherent_memory':
drivers/base/dma-coherent.c:99:15: error: 'mem' may be used uninitialized in this function [-Werror=maybe-uninitialized]
I ended up changing the code a little more, to give use the usual
error handling, as this seemed the best way to fix up the warning
and make the code look reasonable at the same time.
Fixes: 2436bdcda5 ("dma-coherent: remove the DMA_MEMORY_MAP and DMA_MEMORY_IO flags")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Adjust dvb ca.h, dmx.h and frontend.h in order to make
checkpatch happier. Now, it only complains about the typedefs,
and those are there just to provide backward userspace
compatibility.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
There's a chapter for the legacy APIs. Move the frontend DVBv3
API to it, and update the chapter's introduction accordingly.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Problem with ioctl() is that it's a file operation, yet often used as an
inode operation (i.e. modify the inode despite the file being opened for
read-only).
mnt_want_write_file() is used by filesystems in such cases to get write
access on an arbitrary open file.
Since overlayfs lets filesystems do all file operations, including ioctl,
this can lead to mnt_want_write_file() returning OK for a lower file and
modification of that lower file.
This patch prevents modification by checking if the file is from an
overlayfs lower layer and returning EPERM in that case.
Need to introduce a mnt_want_write_file_path() variant that still does the
old thing for inode operations that can do the copy up + modification
correctly in such cases (fchown, fsetxattr, fremovexattr).
This does not address the correctness of such ioctls on overlayfs (the
correct way would be to copy up and attempt to perform ioctl on upper
file).
In theory this could be a regression. We very much hope that nobody is
relying on such a hack in any sane setup.
While this patch meddles in VFS code, it has no effect on non-overlayfs
filesystems.
Reported-by: "zhangyi (F)" <yi.zhang@huawei.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Need to treat non-regular overlayfs files the same as regular files when
checking for an atime update.
Add a d_real() flag to make it return the upper dentry for all file types.
Reported-by: "zhangyi (F)" <yi.zhang@huawei.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Adjust the table to be better displayed on PDF output.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
There appears to be an issue in using \small in certain cases on Sphinx
1.4 and 1.5. Other format documents don't use \small either, remove it
from here as well.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
[mchehab@s-opensource.com: kept tabularcolumns - readjusted - and
add a few blank lines for it to display better]
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Right now, Sphinx unconditionally creates a blank page with
just "Contents:" on it, on PDF output. While this makes sense
for html, it doesn't o PDF, as LaTeX does what's required
automatically.
Fix it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
On several tables, the color sample location table preamble is
written as:
Color Sample Location..
Instead of:
Color Sample Location:
I suspect that the repetition of such pattern was due to some
copy-and-paste (or perhaps some error during DocBook conversion).
Anyway, fix it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
While doing a visual inspection with Sphinx 1.5, I noticed that
one of the columns was smaller than the text written there.
As this is the only thing I noticed with Sphinx 1.5, I suspect
that this was also a problem with Sphinx 1.4. Yet, I opted to
touch it in a way that wouldn't cause backward issues.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
On all vivid parameters, there's an space after the parameter,
except for "DV Timings Signal Mode". That makes this single one
to be written in bold, and, at PDF output, at the same line as
its description.
Use the same convention as the other parameters, in order to
adjust its output.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
It doesn't make any sense having a driver programming's chapter
at the uAPI book, as this is related to kernel API. Also,
we now have such kAPI book where V4L2 driver programming is covered.
So, get rid of this left-over.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
There's an important note there, but it is not using the
ReST markup. So, it doesn't get any visual highlight on
the output.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Most tables there don't fit on 80 columns. Some are very big.
While those tables are actually generated via scripts, every
time a new board is added, the entire table could be reformatted.
>From the diffstat PoV, that's bad, as it is hard to see what
happened.
One such example is at changeset 4868f6e1fce6 ("media:
em28xx-cardlist.rst: update to reflect last changes"):
The USB ID for "Plextor ConvertX PX-AV100U" was added to card
number 9, with caused the entire table to be reformatted.
So, instead, use flat-tables. While here, fix PDF output,
by adding tablecolumns to the tables that need it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The tables there don't quite fit on PDF output.
Adjust it by adding a tabularcolumns macro.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The "Table of Contents" of a PDF file is generated only once,
at the beginning fo the output. It doesn't produce it on
each part.
So, don't output this text on each part of the document.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Several tables at this media book chapter have issues
when PDF is produced. Adjust them.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
A literal box provides a better visual when pdf and html output
is generated for things like the output of a sysfs devnode.
It alsod matches other conventions used within the media book.
So, use it.
While here, use literals for protocol names.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Commit 70b074df4e ("media: fix pdf build with Spinx 1.6") caused
a regression at Sphinx 1.4 PDF build: although it produces a full
document in batch mode, it returns errors on interactive mode:
[63]
Runaway argument?
{\relax
! Paragraph ended before \multicolumn was complete.
<to be read again>
\par
l.7703 \hline\end{tabulary}
The error seems to be due to some bug at Sphinx PDF output:
when multicolumns is used, it doesn't accept an empty string.
Just removing the :cpan:`1` and replacing by two empty
columns fix the issue.
Fixes: 70b074df4e ("media: fix pdf build with Spinx 1.6")
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
