| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Remove the dead code under NGENE_V4L.
Among others, this removes references to the old videobuf framework
that isn't actually used by this driver.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
Fix an 11-year old bug in ngene_command_config_free_buf() while
addressing the following warnings caught with -Warray-bounds:
arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
The problem is that the original code is trying to copy 6 bytes of
data into a one-byte size member _config_ of the wrong structue
FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a
legitimate compiler warning because memcpy() overruns the length
of &com.cmd.ConfigureBuffers.config. It seems that the right
structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains
6 more members apart from the header _hdr_. Also, the name of
the function ngene_command_config_free_buf() suggests that the actual
intention is to ConfigureFreeBuffers, instead of ConfigureBuffers
(which takes place in the function ngene_command_config_buf(), above).
Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS
into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as
the destination address, instead of &com.cmd.ConfigureBuffers.config,
when calling memcpy().
This also helps with the ongoing efforts to globally enable
-Warray-bounds and get us closer to being able to tighten the
FORTIFY_SOURCE routines on memcpy().
Link: https://github.com/KSPP/linux/issues/109
Fixes: dae52d009fc9 ("V4L/DVB: ngene: Initial check-in")
Cc: stable@vger.kernel.org
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/
|
|
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 only
as published by the free software foundation this program is
distributed in the hope that it will be useful but without any
warranty without even the implied warranty of merchantability or
fitness for a particular purpose see the gnu general public license
for more details to obtain the license point your browser to http
www gnu org copyleft gpl html
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 12 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Enrico Weigelt <info@metux.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081202.028166291@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
A possible hardware bug was discovered when using CA addon hardware
attached to the ngene hardware, in that the TS input buffer much likely
will shift and thus become unaligned to 188 byte blocks (a full TS frame)
when things like CA module initialisation (which happens via differing
communication paths) take place. This causes the TS NULL removal in
tsin_exchange() to fail to detect this previously inserted data and thus
causes userspace applications to receive data they didn't sent beforehand
and ultimately cause troubles.
On driver load with an inserted CAM, buffers are fine at first (note that
the driver has to keep the communication running from/to the card by
inserting TS NULL frames, this is done in tsout_exchange() via
FillTSBuffer() - that data is simply sent back by the hardware):
offset | 0 1 2 3 4 5 .... 188 189 190 191 192 193 .... 376
data | 47 1f ff 10 6f 6f .... 47 1f ff 10 6f 6f .... 47
After a few seconds, the CA module is recognised and initialised, which is
signalled by
dvb_ca_en50221: dvb_ca adapter X: DVB CAM detected and initialised successfully
This is where the first shift happens (this is always four bytes), buffer
becomes like this:
offset | 0 1 2 3 4 5 .... 188 189 190 191 192 193 .... 376
data | 6f 6f 6f 6f 47 1f .... 6f 6f 6f 6f 47 1f .... 6f
Next, VDR, TVHeadend or any other CI aware application is started, buffers
will shift by even more bytes. It is believed this is due to the hardware
not handling control and data bytes properly distinct, and control data
having an influence on the actual data stream, which we cannot properly
detect at the driver level.
Workaround this hardware quirk by adding a detection for the TS sync byte
0x47 before each TS frame copy, scan for a new SYNC byte and a TS NULL
packet if buffers become unaligned, take note of that offset and apply
that when copying data to the DVB ring buffers. The last <188 bytes from
the hardware buffers are stored in a temp buffer (tsin_buffer), for which
the remainder will be in the beginning of the next hardware buffer (next
iteration of tsin_exchange()). That remainder will be appended to the
temp buffer and finally sent to the DVB ring buffer. The resulting TS
stream is perfectly fine, and the TS NULL packets inserted by the driver
which are sent back are properly removed. The resulting offset is being
clamped to 188 byte segments (one TS packet). Though this can result in
a repeated TS packet if the overall offset grows beyond this (and it
will grow only on CA initialisation), this is still way better than
unaligned TS frames and data sent to userspace that just isn't supposed
to be there.
This compensation can be toggled by the ci_tsfix modparam, which defaults
to 1 (enabled). In the case of problems, this can be turned off by setting
the parameter to 0 to restore the old behaviour.
Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Currently, if there's no CXD2099AR attached to any expansion connector of
the ngene hardware, it will complain with this on every module load:
cxd2099 1-0040: No CXD2099AR detected at 0x40
cxd2099: probe of 1-0040 failed with error -5
ngene 0000:02:00.0: CXD2099AR attach failed
This happens due to the logic assuming such hardware is always there and
blindly tries to attach the cxd2099 I2C driver. Rather add a probe
function (in ngene-cards.c with a prototype in ngene.h) to check for
the existence of such hardware before probing, and don't try further if
no CXD2099 was found.
Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Detect and initialise modules equipped with XO2 interfaces (Lattice
MachXO2). This requires a few more I2C transfer functions which this adds
as well. Defines for the different possible (available) module types are
added to ngene.h. The support for the actual tuners contained on these
addon modules is kept separate from this commit and is being added with
the next commits.
The xo2names array is temporarily marked __maybe_unused to silence a
corresponding compiler warning at this stage.
Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Add support for STV0367+TDA18212 based DuoFlex CT addon modules. For this,
add a demod probe function and all necessary demod/tuner attach functions
which use existing auxiliary drivers (stv0367 and tda18212) to support
this hardware. As tda18212 is an I2C client driver, proper cleanup code
is added to the deregistration sequence in ngene-core. To not cause use-
after-free situations when there's a CXD2099 I2C client connected, which
is rather freed in ngene-core.c:cxd_detach(), add i2c_client_fe to struct
ngene_channel to keep track if the i2c_client was allocated by a frontend
driver, rather than the CI code paths. Also move the I2C access functions
to the top of the file and add the required read_regs() function for the
tda18212 ping to work.
This adds autoselection (if MEDIA_SUBDRV_AUTOSELECT) of the STV0367 demod
driver and TDA18212 tuner driver to Kconfig aswell.
Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Make it more clear which demod_type is used for which hardware by having
defines for the possible demod_type values. With that, change the
demod_type evaluation in tuner_attach_probe() to a switch-case instead
of an if() for each possible value.
Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Change the way the cxd2099 hardware is being attached to the new I2C
client interface way.
Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Except for DVB, all media kAPI headers are at include/media.
Move the headers to it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The semaphore 'i2c_switch_mutex' is used as a simple mutex, so
it should be written as one. Semaphores are going away in the future.
Signed-off-by: Binoy Jayan <binoy.jayan@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The semaphore 'stream_mutex' is used as a simple mutex, so
it should be written as one. Also moving the mutex_[lock/unlock]
to the caller as it is anyway locked at the beginning of the
callee thus avoiding repetition.
Signed-off-by: Binoy Jayan <binoy.jayan@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The semaphore 'cmd_mutex' is used as a simple mutex, so
it should be written as one. Also, replace down with
mutex_destroy to ensure sane state when ngene_stop is
called.
Signed-off-by: Binoy Jayan <binoy.jayan@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Drop the FSF's postal address from the source code files that typically
contain mostly the license text. Of the 628 removed instances, 578 are
outdated.
The patch has been created with the following command without manual edits:
git grep -l "675 Mass Ave\|59 Temple Place\|51 Franklin St" -- \
drivers/media/ include/media|while read i; do i=$i perl -e '
open(F,"< $ENV{i}");
$a=join("", <F>);
$a =~ s/[ \t]*\*\n.*You should.*\n.*along with.*\n.*(\n.*USA.*$)?\n//m
&& $a =~ s/(^.*)Or, (point your browser to) /$1To obtain the license, $2\n$1/m;
close(F);
open(F, "> $ENV{i}");
print F $a;
close(F);'; done
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
The DVB API was originally defined using typedefs. This is against
Kernel CodingStyle, and there's no good usage here. While we can't
remove its usage on userspace, we can avoid its usage in Kernelspace.
So, let's do it.
This patch was generated by this shell script:
for j in $(grep typedef include/uapi/linux/dvb/frontend.h |cut -d' ' -f 3); do for i in $(find drivers/media -name '*.[ch]' -type f) $(find drivers/staging/media -name '*.[ch]' -type f); do sed "s,${j}_t,enum $j," <$i >a && mv a $i; done; done
While here, make CodingStyle fixes on the affected lines.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> # for drivers/media/firewire/*
|
|
drivers/media/pci/ngene/ngene-core.c:188:27: warning: incorrect type in argument 1 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:190:25: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:199:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:260:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:263:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:282:32: warning: incorrect type in argument 1 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:283:17: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:284:17: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:285:17: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:286:17: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:287:17: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:288:17: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:292:17: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:293:17: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:294:17: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:295:17: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:296:17: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:297:17: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:303:17: warning: incorrect type in argument 1 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:316:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:368:17: warning: incorrect type in argument 1 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:372:9: warning: incorrect type in argument 1 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1160:28: warning: incorrect type in argument 1 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1199:20: warning: incorrect type in assignment (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1213:30: warning: incorrect type in argument 1 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1214:30: warning: incorrect type in argument 1 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1223:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1225:24: warning: incorrect type in argument 1 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1227:31: warning: incorrect type in argument 1 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1296:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1297:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1298:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1299:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1300:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1301:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1302:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1363:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1365:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1376:17: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1391:17: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-core.c:1596:18: warning: Using plain integer as NULL pointer
drivers/media/pci/ngene/ngene-core.c:1615:9: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-cards.c:699:29: warning: Using plain integer as NULL pointer
drivers/media/pci/ngene/ngene-cards.c:699:32: warning: Using plain integer as NULL pointer
drivers/media/pci/ngene/ngene-cards.c:699:35: warning: Using plain integer as NULL pointer
drivers/media/pci/ngene/ngene-cards.c:699:38: warning: Using plain integer as NULL pointer
drivers/media/pci/ngene/ngene-dvb.c:84:59: warning: incorrect type in argument 2 (different address spaces)
drivers/media/pci/ngene/ngene-dvb.c:93:20: warning: incorrect type in initializer (incompatible argument 2 (different address spaces))
drivers/media/pci/ngene/ngene-dvb.c:94:20: warning: incorrect type in initializer (incompatible argument 2 (different address spaces))
drivers/media/pci/ngene/ngene-dvb.c:100:20: warning: Using plain integer as NULL pointer
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
|
CONFIG_HOTPLUG is going away as an option. As a result, the __dev*
markings need to be removed.
This change removes the use of __devinit, __devexit_p, __devinitdata,
__devinitconst, and __devexit from these drivers.
Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.
Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The remaining dvb drivers are pci, so rename them to match the
bus.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
