The header file has some private static structures that
are used only by the C file. Move those structures to the C file,
in order to shut up gcc 6.1 warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The header file has some private static structures that
are used only by the C file. Move those structures to the C file,
in order to shut up gcc 6.1 warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The header file has some private static structures that
are used only by the C file. Move those structures to the C file,
in order to shut up gcc 6.1 warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The header file has some private static structures that
are used only by the C file. Move those structures to the C file,
in order to shut up gcc 6.1 warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The mc5602_s5k4aa.h has some private static structures that
are used only by the C file. Move those structures to the C file,
in order to shut up gcc 6.1 warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The mc5602_brigde.h is included at m5602 submodules. This
causes Gcc 6.1 to complain:
drivers/media/usb/gspca/m5602/m5602_bridge.h:124:28: warning: 'sensor_urb_skeleton' defined but not used [-Wunused-const-variable=]
static const unsigned char sensor_urb_skeleton[] = {
^~~~~~~~~~~~~~~~~~~
drivers/media/usb/gspca/m5602/m5602_bridge.h:119:28: warning: 'bridge_urb_skeleton' defined but not used [-Wunused-const-variable=]
static const unsigned char bridge_urb_skeleton[] = {
^~~~~~~~~~~~~~~~~~~
Let's shut up gcc 6.1 warnings by moving those data structures
to the core, as they're used only there.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Gcc 6.1 now complains about unused vars:
drivers/media/pci/cx18/cx18-driver.h:497:18: warning: 'vbi_hblank_samples_50Hz' defined but not used [-Wunused-const-variable=]
static const u32 vbi_hblank_samples_50Hz = 284; /* 4 byte EAV + 280 anc/fill */
^~~~~~~~~~~~~~~~~~~~~~~
drivers/media/pci/cx18/cx18-driver.h:496:18: warning: 'vbi_hblank_samples_60Hz' defined but not used [-Wunused-const-variable=]
static const u32 vbi_hblank_samples_60Hz = 272; /* 4 byte EAV + 268 anc/fill */
^~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/media/pci/cx18/cx18-cards.c:25:0:
drivers/media/pci/cx18/cx18-driver.h:497:18: warning: 'vbi_hblank_samples_50Hz' defined but not used [-Wunused-const-variable=]
static const u32 vbi_hblank_samples_50Hz = 284; /* 4 byte EAV + 280 anc/fill */
^~~~~~~~~~~~~~~~~~~~~~~
drivers/media/pci/cx18/cx18-driver.h:496:18: warning: 'vbi_hblank_samples_60Hz' defined but not used [-Wunused-const-variable=]
static const u32 vbi_hblank_samples_60Hz = 272; /* 4 byte EAV + 268 anc/fill */
^~~~~~~~~~~~~~~~~~~~~~~
drivers/media/pci/cx18/cx18-driver.h:495:18: warning: 'vbi_active_samples' defined but not used [-Wunused-const-variable=]
static const u32 vbi_active_samples = 1444; /* 4 byte SAV + 720 Y + 720 U/V */
^~~~~~~~~~~~~~~~~~
In this specific case, this is somewhat intentional, as those
values are actually used in parts of the driver. The code assumes
that gcc optimizer it and not actually create any var, but convert
it to immediate access at the routines.
Yet, as we want to shut up gcc warnings, let's use #define, with
is the standard way to store values that will use assembler's
immediate access code.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Gcc 6.1 warns about some unused vars and functions. Remove them:
drivers/media/platform/exynos4-is/mipi-csis.c:665:46: warning: 's5pcsis_sd_internal_ops' defined but not used [-Wunused-const-variable=]
static const struct v4l2_subdev_internal_ops s5pcsis_sd_internal_ops = {
^~~~~~~~~~~~~~~~~~~~~~~
drivers/media/platform/exynos4-is/mipi-csis.c:652:12: warning: 's5pcsis_open' defined but not used [-Wunused-function]
static int s5pcsis_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
^~~~~~~~~~~~
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Gcc 6.1 warns about some unused vars. Remove them:
drivers/media/usb/usbvision/usbvision-core.c:94:18: warning: 'min_imgheight' defined but not used [-Wunused-const-variable=]
static const int min_imgheight = MIN_FRAME_HEIGHT;
^~~~~~~~~~~~~
drivers/media/usb/usbvision/usbvision-core.c:93:18: warning: 'min_imgwidth' defined but not used [-Wunused-const-variable=]
static const int min_imgwidth = MIN_FRAME_WIDTH;
^~~~~~~~~~~~
drivers/media/usb/usbvision/usbvision-core.c:92:18: warning: 'max_imgheight' defined but not used [-Wunused-const-variable=]
static const int max_imgheight = MAX_FRAME_HEIGHT;
^~~~~~~~~~~~~
drivers/media/usb/usbvision/usbvision-core.c:91:18: warning: 'max_imgwidth' defined but not used [-Wunused-const-variable=]
static const int max_imgwidth = MAX_FRAME_WIDTH;
^~~~~~~~~~~~
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
In the current Documentation/md.txt, the lower limit value of
stripe_cache_size is 16 and the default value is 128, but when
I update kernel to the latest mainline version and RAID5 array
is created by mdadm, then execute the following commands, it
shows an error and a difference respectively.
1) set stripe_cache_size to 16
[root@localhost ~]# echo 16 > /sys/block/md0/md/stripe_cache_size
bash: echo: write error: Invalid argument
2) read the default value of stripe_cache_size
[root@localhost ~]# cat /sys/block/md0/md/stripe_cache_size
256
I read drivers/md/raid5.c and find the following related code:
1) in function 'raid5_set_cache_size':
if (size <= 16 || size > 32768)
return -EINVAL;
2) #define NR_STRIPES 256
So the lower limit value of stripe_cache_size should be 17 and
the default value should be 256.
Signed-off-by: Tiezhu Yang <kernelpatch@126.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Bcache documentation updates:
- Added new HOWTO/COOKBOOK section
- fixed a few typos
- /sys/block/bcache0/cache_mode is /sys/block/bcache0/bcache/cache_mode
Signed-off-by: Marc MERLIN <marc@merlins.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
While there's slight overlap with the DocBook help now, this can stay
intact when the DocBook help goes away.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Document the new HDMI CEC framework.
[k.debski@samsung.com: add DocBook documentation by Hans Verkuil, with
Signed-off-by: Kamil Debski <kamil@wypas.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Add handling of remote control events coming from the HDMI CEC bus
and the new protocol required for that.
Signed-off-by: Kamil Debski <kamil@wypas.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Inputs can come in over the HDMI CEC bus, so add a new type for this.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Two parameters were documented with a wrong name, and a struct
device pointer description was missing.
That caused the following warnings, when building documentation:
include/media/media-devnode.h:102: warning: No description found for parameter 'media_dev'
include/media/media-devnode.h:126: warning: No description found for parameter 'mdev'
include/media/media-devnode.h:126: warning: Excess function parameter 'media_dev' description in 'media_devnode_register'
Rename the description, to match the function parameter and fix
Documentation.
No funcional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
drivers/media/platform/rcar-vin/rcar-core.c: In function 'rvin_graph_notify_complete':
drivers/media/platform/rcar-vin/rcar-core.c:65:22: warning: variable 'sd' set but not used [-Wunused-but-set-variable]
struct v4l2_subdev *sd;
^
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
A V4L2 driver for Renesas R-Car VIN driver that do not depend on
soc_camera. The driver is heavily based on its predecessor and aims to
replace it.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
When a buffer is being dequeued using VIDIOC_DQBUF IOCTL, the exact buffer
which will be dequeued is not known until the buffer has been removed from
the queue. The number of planes is specific to a buffer, not to the queue.
This does lead to the situation where multi-plane buffers may be requested
and queued with n planes, but VIDIOC_DQBUF IOCTL may be passed an argument
struct with fewer planes.
__fill_v4l2_buffer() however uses the number of planes from the dequeued
videobuf2 buffer, overwriting kernel memory (the m.planes array allocated
in video_usercopy() in v4l2-ioctl.c) if the user provided fewer
planes than the dequeued buffer had. Oops!
Fixes: b0e0e1f83d ("[media] media: videobuf2: Prepare to divide videobuf2")
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Cc: stable@vger.kernel.org # for v4.4 and later
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
An earlier patch fixing an input validation issue introduced another
issue: vb2_core_dqbuf() is called with pb argument value NULL in some
cases, causing a NULL pointer dereference. Fix this by skipping the
verification as there's nothing to verify.
Fixes: e7e0c3e265 ("[media] videobuf2-core: Check user space planes array in dqbuf")
Signed-off-by: David R <david@unsolicited.net>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Cc: stable@vger.kernel.org # for v4.4 and later
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Media devnode open/ioctl could be in progress when media device unregister
is initiated. System calls and ioctls check media device registered status
at the beginning, however, there is a window where unregister could be in
progress without changing the media devnode status to unregistered.
process 1 process 2
fd = open(/dev/media0)
media_devnode_is_registered()
(returns true here)
media_device_unregister()
(unregister is in progress
and devnode isn't
unregistered yet)
...
ioctl(fd, ...)
__media_ioctl()
media_devnode_is_registered()
(returns true here)
...
media_devnode_unregister()
...
(driver releases the media device
memory)
media_device_ioctl()
(By this point
devnode->media_dev does not
point to allocated memory.
use-after free in in mutex_lock_nested)
BUG: KASAN: use-after-free in mutex_lock_nested+0x79c/0x800 at addr
ffff8801ebe914f0
Fix it by clearing register bit when unregister starts to avoid the race.
process 1 process 2
fd = open(/dev/media0)
media_devnode_is_registered()
(could return true here)
media_device_unregister()
(clear the register bit,
then start unregister.)
...
ioctl(fd, ...)
__media_ioctl()
media_devnode_is_registered()
(return false here, ioctl
returns I/O error, and
will not access media
device memory)
...
media_devnode_unregister()
...
(driver releases the media device
memory)
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reported-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Tested-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
When driver unbinds while media_ioctl is in progress, cdev_put() fails with
when app exits after driver unbinds.
Add devnode struct device kobj as the cdev parent kobject. cdev_add() gets
a reference to it and releases it in cdev_del() ensuring that the devnode
is not deallocated as long as the application has the device file open.
media_devnode_register() initializes the struct device kobj before calling
cdev_add(). media_devnode_unregister() does cdev_del() and then deletes the
device. devnode is released when the last reference to the struct device is
gone.
This problem is found on uvcvideo, em28xx, and au0828 drivers and fix has
been tested on all three.
kernel: [ 193.599736] BUG: KASAN: use-after-free in cdev_put+0x4e/0x50
kernel: [ 193.599745] Read of size 8 by task media_device_te/1851
kernel: [ 193.599792] INFO: Allocated in __media_device_register+0x54
kernel: [ 193.599951] INFO: Freed in media_devnode_release+0xa4/0xc0
kernel: [ 193.601083] Call Trace:
kernel: [ 193.601093] [<ffffffff81aecac3>] dump_stack+0x67/0x94
kernel: [ 193.601102] [<ffffffff815359b2>] print_trailer+0x112/0x1a0
kernel: [ 193.601111] [<ffffffff8153b5e4>] object_err+0x34/0x40
kernel: [ 193.601119] [<ffffffff8153d9d4>] kasan_report_error+0x224/0x530
kernel: [ 193.601128] [<ffffffff814a2c3d>] ? kzfree+0x2d/0x40
kernel: [ 193.601137] [<ffffffff81539d72>] ? kfree+0x1d2/0x1f0
kernel: [ 193.601154] [<ffffffff8157ca7e>] ? cdev_put+0x4e/0x50
kernel: [ 193.601162] [<ffffffff8157ca7e>] cdev_put+0x4e/0x50
kernel: [ 193.601170] [<ffffffff815767eb>] __fput+0x52b/0x6c0
kernel: [ 193.601179] [<ffffffff8117743a>] ? switch_task_namespaces+0x2a
kernel: [ 193.601188] [<ffffffff815769ee>] ____fput+0xe/0x10
kernel: [ 193.601196] [<ffffffff81170023>] task_work_run+0x133/0x1f0
kernel: [ 193.601204] [<ffffffff8117746e>] ? switch_task_namespaces+0x5e
kernel: [ 193.601213] [<ffffffff8111b50c>] do_exit+0x72c/0x2c20
kernel: [ 193.601224] [<ffffffff8111ade0>] ? release_task+0x1250/0x1250
-
-
-
kernel: [ 193.601360] [<ffffffff81003587>] ? exit_to_usermode_loop+0xe7
kernel: [ 193.601368] [<ffffffff810035c0>] exit_to_usermode_loop+0x120
kernel: [ 193.601376] [<ffffffff810061da>] syscall_return_slowpath+0x16a
kernel: [ 193.601386] [<ffffffff82848b33>] entry_SYSCALL_64_fastpath+0xa6
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Tested-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
struct media_devnode is currently embedded at struct media_device.
While this works fine during normal usage, it leads to a race
condition during devnode unregister. the problem is that drivers
assume that, after calling media_device_unregister(), the struct
that contains media_device can be freed. This is not true, as it
can't be freed until userspace closes all opened /dev/media devnodes.
In other words, if the media devnode is still open, and media_device
gets freed, any call to an ioctl will make the core to try to access
struct media_device, with will cause an use-after-free and even GPF.
Fix this by dynamically allocating the struct media_devnode and only
freeing it when it is safe.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Along all media controller code, "mdev" is used to represent
a pointer to struct media_device, and "devnode" for a pointer
to struct media_devnode.
However, inside media-devnode.[ch], "mdev" is used to represent
a pointer to struct media_devnode.
This is very confusing and may lead to development errors.
So, let's change all occurrences at media-devnode.[ch] to
also use "devnode" for such pointers.
This patch doesn't make any functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
For the third time in three years, I'm changing my e-mail at
Samsung. That's bad, as it may stop communications with me for
a while. So, this time, I'll also the mchehab@kernel.org e-mail,
as it remains stable since ever.
Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Let the user specify file patterns where to look for the EXPORT_SYMBOLs
in addition to the file with kernel-doc comments. This is directly based
on the -export-file FILE option added to kernel-doc in "kernel-doc: add
support for specifying extra files for EXPORT_SYMBOLs", but we extend
that with globbing patterns in the Sphinx extension.
The file patterns are added as options to the :export: and :internal:
arguments of the kernel-doc directive. For example, to extract the
documentation of exported functions from include/net/mac80211.h:
.. kernel-doc:: include/net/mac80211.h
:export: net/mac80211/*.c
Without the file pattern, no exported functions would be found, as the
EXPORT_SYMBOLs are placed in the various source files under
net/mac80211.
The matched files are also added as dependencies on the document in
Sphinx, as they may affect the output. This is one of the reasons to do
the globbing in the Sphinx extension instead of in scripts/kernel-doc.
The file pattern remains optional, and is not needed if the kernel-doc
comments and EXPORT_SYMBOLs are placed in the source file passed in as
the main argument to the kernel-doc directive. This is the most common
case across the kernel source tree.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
status is not initialized so it can contain garbage. The
check for status containing the FE_HAS_LOCK bit may randomly pass
or fail if the read of register 0x8c fails to set status after 25
read attempts. Fix this by initializing status to 0.
Issue found with CoverityScan, CID#986738
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The code is checking for negative returns but it should be checking for
zero.
Fixes: aab3125c43 ('[media] em28xx: add support for registering multiple i2c buses')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Scan all input files for EXPORT_SYMBOLs along with the explicitly
specified export files before actually parsing anything.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
If the kernel-doc comments for functions are not in the same file as the
EXPORT_SYMBOL statements, the -export and -internal output selections do
not work as expected. This is typically the case when the kernel-doc
comments are in header files next to the function declarations and the
EXPORT_SYMBOL statements are next to the function definitions in the
source files.
Let the user specify additional source files in which to look for the
EXPORT_SYMBOLs using the new -export-file FILE option, which may be
given multiple times.
The pathological example for this is include/net/mac80211.h, which has
all the kernel-doc documentation for the exported functions defined in a
plethora of source files net/mac80211/*.c.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Since
commit 32217761ee
Author: Jani Nikula <jani.nikula@intel.com>
Date: Sun May 29 09:40:44 2016 +0300
kernel-doc: concatenate contents of colliding sections
we started getting (more) errors on duplicate section names, especially
on the default section name "Description":
include/net/mac80211.h:3174: warning: duplicate section name 'Description'
This is usually caused by a slightly unorthodox placement of parameter
descriptions, like in the above case, and kernel-doc resetting back to
the default section more than once within a kernel-doc comment.
Ignore warnings on the duplicate section name automatically assigned by
kernel-doc, and only consider explicitly user assigned duplicate section
names an issue.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Lots of kerneldoc entries use "example:" or "note:" as section headers.
Until such a time as we can make them use proper markup, make them work as
intended.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
The meaning of "leak" can be both "untracked resource allocation" and
"memory content disclosure". This document's use was entirely of the
latter meaning, so avoid the confusion by using the Common Weakness
Enumeration name for this: Information Exposure (CWE-200). Additionally
adds a section on structure randomization.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Jani Nikula says:
Jon, this is v2 of [1] and [2], with a considerable amount of polish and
fixes added. We started dogfooding this within drm-intel, and Daniel has
reviewed the lot and contributed a number of fixes, most notably
accurate file and line number references from Sphinx build
errors/warnings to the kernel-doc comments in source code.
We believe this is now in good shape for merging for v4.8. It's all in
my sphinx-for-docs-next branch that you've already looked at; pull
details below.
When this lands in docs-next and we can backmerge to drm, we'll plunge
ahead and convert gpu.tmpl to rst, and have that ready for v4.8. We
think it's best to contribute that via the drm tree, as it'll involve
splitting up the documentation and likely numerous updates to kernel-doc
comments.
I plan to update Documentation/kernel-doc-nano-HOWTO.txt for Sphinx and
rst, obviously converting it to rst while at it.
The rtl2832 demod has 2 sets of PID filters. This patch enables
the filter support when using a slave demod.
Signed-off-by: Benjamin Larsson <benjamin@southpole.se>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Remove __func__ and KBUILD_MODNAME from logging formatters and pass
USB interface device instead, so logging can be done correctly.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The MXL5007T tuner will lock-up on some devices after an I2C read
transaction. This patch works around this issue by inhibiting such
operations and emulating a 0x00 response. The workaround is only
applied to USB devices known to exhibit this flaw.
Signed-off-by: Alessandro Radicati <alessandro@radicati.net>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This patch will modify the af9035 driver to use the register address
fields of the I2C read command for the combined write/read transaction
case. Without this change, the firmware issues just a I2C read
transaction without the preceding write transaction to select the
register.
Signed-off-by: Alessandro Radicati <alessandro@radicati.net>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Change return value back to -ENODEV when no region is defined for given
device. This restores old behavior of this function, as some drivers rely
on such error code.
Fixes: 59ce403972 ("of: reserved_mem: add support for using more than
one region for given device")
Reported-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Sumit Semwal <sumit.semwal@linaro.org>
