Re: [[PATCH v3]] videobuf2: Add missing lock held on vb2_fop_relase
Hello Sylwester
Thanks for your comments. There is a new patch: v4! :)
On Fri, Nov 1, 2013 at 11:36 PM, Sylwester Nawrocki
sylvester.nawro...@gmail.com wrote:
Hi Ricardo,
On 10/31/2013 09:54 PM, Ricardo Ribalda Delgado wrote:
From: Ricardo Ribaldaricardo.riba...@gmail.com
vb2_fop_relase does not held the lock although it is modifying the
queue-owner field.
This could lead to race conditions on the vb2_perform_io function
when multiple applications are accessing the video device via
read/write API:
[...]
v2: Add bug found by Sylvester Nawrocki
v2: Add fix for a bug found... ? :)
In Spanish it makes sense. it is fixed now, thanks
fimc-capture and fimc-lite where calling vb2_fop_release with the lock
held.
Therefore a new __vb2_fop_release function has been created to be used by
drivers that overload the release function.
v3: Comments by Sylvester Nawrocki and Mauro Carvalho Chehab
Use vb2_fop_release_locked instead of __vb2_fop_release
Such notes normally go after the scissors line (---) after Signed-off-by
lines.
Fixed, thanks!
Signed-off-by: Ricardo Ribaldaricardo.riba...@gmail.com
Signed-off-by: Ricardo Ribalda Delgadoricardo.riba...@gmail.com
Is this duplication really needed ?
I have different slightly different git configuration in 2 computers. Fixed now
---
drivers/media/platform/exynos4-is/fimc-capture.c | 2 +-
drivers/media/platform/exynos4-is/fimc-lite.c| 2 +-
drivers/media/v4l2-core/videobuf2-core.c | 24
+++-
include/media/videobuf2-core.h | 1 +
4 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c
b/drivers/media/platform/exynos4-is/fimc-capture.c
index fb27ff7..c3c3b3b 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -549,7 +549,7 @@ static int fimc_capture_release(struct file *file)
vc-streaming = false;
}
- ret = vb2_fop_release(file);
+ ret = vb2_fop_release_locked(file);
I'm personally not happy with such a change. It is still not obvious
if locked means that this function takes the lock internally or it
should be called with the lock held. How about sticking to the common
practice and instead naming it __vb2_fop_release() ?
I like the locked prefix, but it is a lost war :P. New version is named as __
if (close) {
clear_bit(ST_CAPT_BUSY,fimc-state);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
b/drivers/media/platform/exynos4-is/fimc-lite.c
index e5798f7..b8d417f 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -546,7 +546,7 @@ static int fimc_lite_release(struct file *file)
mutex_unlock(entity-parent-graph_mutex);
}
- vb2_fop_release(file);
+ vb2_fop_release_locked(file);
pm_runtime_put(fimc-pdev-dev);
clear_bit(ST_FLITE_SUSPENDED,fimc-state);
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 594c75e..06e6dbd 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2619,18 +2619,40 @@ int vb2_fop_mmap(struct file *file, struct
vm_area_struct *vma)
}
EXPORT_SYMBOL_GPL(vb2_fop_mmap);
-int vb2_fop_release(struct file *file)
+int __vb2_fop_release(struct file *file, bool lock_is_held)
{
struct video_device *vdev = video_devdata(file);
+ struct mutex *lock;
if (file-private_data == vdev-queue-owner) {
+ if (lock_is_held)
+ lock = NULL;
+ else
+ lock = vdev-queue-lock ?
+ vdev-queue-lock : vdev-lock;
+ if (lock)
+ mutex_lock(lock);
vb2_queue_release(vdev-queue);
vdev-queue-owner = NULL;
+ if (lock)
+ mutex_unlock(lock);
}
return v4l2_fh_release(file);
}
+EXPORT_SYMBOL_GPL(__vb2_fop_release);
We don't need to export this function, do we ?
Not really. Fixed
+int vb2_fop_release(struct file *file)
+{
+ return __vb2_fop_release(file, false);
+}
EXPORT_SYMBOL_GPL(vb2_fop_release);
+int vb2_fop_release_locked(struct file *file)
+{
+ return __vb2_fop_release(file, true);
+}
+EXPORT_SYMBOL_GPL(vb2_fop_release_locked);
--
Thanks,
Sylwester
Thanks!
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] videobuf2: Add missing lock held on vb2_fop_relase
From: Ricardo Ribalda ricardo.riba...@gmail.com
vb2_fop_relase does not held the lock although it is modifying the
queue-owner field.
This could lead to race conditions on the vb2_perform_io function
when multiple applications are accessing the video device via
read/write API:
[ 308.297741] BUG: unable to handle kernel NULL pointer dereference at
0260
[ 308.297759] IP: [a07a9fd2] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.297794] PGD 159719067 PUD 158119067 PMD 0
[ 308.297812] Oops: #1 SMP
[ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg
qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core
qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO)
spi_xilinx spi_bitbang qt5023
[ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1
[ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS
PM_2.1.0.309 X64 05/23/2013
[ 308.297952] task: 8801564e1690 ti: 88014dc02000 task.ti:
88014dc02000
[ 308.297962] RIP: 0010:[a07a9fd2] [a07a9fd2]
vb2_perform_fileio+0x372/0x610 [videobuf2_core]
[ 308.297985] RSP: 0018:88014dc03df8 EFLAGS: 00010202
[ 308.297995] RAX: RBX: 880158a23000 RCX: dead00100100
[ 308.298003] RDX: RSI: dead00200200 RDI:
[ 308.298012] RBP: 88014dc03e58 R08: R09: 0001
[ 308.298020] R10: ea00051e8380 R11: 88014dc03fd8 R12: 880158a23070
[ 308.298029] R13: 8801549040b8 R14: 00198000 R15: 01887e60
[ 308.298040] FS: 7f65130d5700() GS:88015ed0()
knlGS:
[ 308.298049] CS: 0010 DS: ES: CR0: 80050033
[ 308.298057] CR2: 0260 CR3: 00015963 CR4: 07e0
[ 308.298064] Stack:
[ 308.298071] 880156416c00 00198000
88010001
[ 308.298087] 88014dc03f50 810a79ca 00020001
880154904718
[ 308.298101] 880156416c00 00198000 880154904338
88014dc03f50
[ 308.298116] Call Trace:
[ 308.298143] [a07aa3c4] vb2_read+0x14/0x20 [videobuf2_core]
[ 308.298198] [a07aa494] vb2_fop_read+0xc4/0x120 [videobuf2_core]
[ 308.298252] [8154ee9e] v4l2_read+0x7e/0xc0
[ 308.298296] [8116e639] vfs_read+0xa9/0x160
[ 308.298312] [8116e882] SyS_read+0x52/0xb0
[ 308.298328] [81784179] tracesys+0xd0/0xd5
[ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0
44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b
44 c5 48 8b 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41
89
[ 308.298487] RIP [a07a9fd2] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.298507] RSP 88014dc03df8
[ 308.298514] CR2: 0260
[ 308.298526] ---[ end trace e8f01717c96d1e41 ]---
Signed-off-by: Ricardo Ribalda ricardo.riba...@gmail.com
---
v2: Comments by Sylvester Nawrocki
fimc-capture and fimc-lite where calling vb2_fop_release with the lock held.
Therefore a new __vb2_fop_release function has been created to be used by
drivers that overload the release function.
v3: Comments by Sylvester Nawrocki and Mauro Carvalho Chehab
Use vb2_fop_release_locked instead of __vb2_fop_release
v4: Comments by Sylvester Nawrocki
Rename vb2_fop_release_locked to __vb2_fop_release and fix patch format
drivers/media/platform/exynos4-is/fimc-capture.c | 2 +-
drivers/media/platform/exynos4-is/fimc-lite.c| 2 +-
drivers/media/v4l2-core/videobuf2-core.c | 23 ++-
include/media/videobuf2-core.h | 1 +
4 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c
b/drivers/media/platform/exynos4-is/fimc-capture.c
index fb27ff7..8192fe0 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -549,7 +549,7 @@ static int fimc_capture_release(struct file *file)
vc-streaming = false;
}
- ret = vb2_fop_release(file);
+ ret = __vb2_fop_release(file);
if (close) {
clear_bit(ST_CAPT_BUSY, fimc-state);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
b/drivers/media/platform/exynos4-is/fimc-lite.c
index e5798f7..cbe51cd 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -546,7 +546,7 @@ static int fimc_lite_release(struct file *file)
mutex_unlock(entity-parent-graph_mutex);
}
- vb2_fop_release(file);
+ __vb2_fop_release(file);
pm_runtime_put(fimc-pdev-dev);
clear_bit(ST_FLITE_SUSPENDED, fimc-state);
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 594c75e..f48d72a 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2619,18
Re: [linux-media] Patch notification: 1 patch updated
Am 31.10.2013 13:13, schrieb Patchwork: Hello, The following patch (submitted by you) has been updated in patchwork: * linux-media: em28xx: make sure that all subdevices are powered on when needed - http://patchwork.linuxtv.org/patch/20422/ - for: Linux Media kernel patches was: New now: Superseded This patch isn't superseeded. Guennadi didn't pick it up, so it's still up to you to review it. Regards, Frank This email is a notification only - you do not need to respond. - Patches submitted to linux-media@vger.kernel.org have the following possible states: New: Patches not yet reviewed (typically new patches); Under review: When it is expected that someone is reviewing it (typically, the driver's author or maintainer). Unfortunately, patchwork doesn't have a field to indicate who is the driver maintainer. If in doubt about who is the driver maintainer please check the MAINTAINERS file or ask at the ML; Superseded: when the same patch is sent twice, or a new version of the same patch is sent, and the maintainer identified it, the first version is marked as such. It is also used when a patch was superseeded by a git pull request. Obsoleted: patch doesn't apply anymore, because the modified code doesn't exist anymore. Changes requested: when someone requests changes at the patch; Rejected: When the patch is wrong or doesn't apply. Most of the time, 'rejected' and 'changes requested' means the same thing for the developer: he'll need to re-work on the patch. RFC: patches marked as such and other patches that are also RFC, but the patch author was not nice enough to mark them as such. That includes: - patches sent by a driver's maintainer who send patches via git pull requests; - patches with a very active community (typically from developers working with embedded devices), where lots of versions are needed for the driver maintainer and/or the community to be happy with. Not Applicable: for patches that aren't meant to be applicable via the media-tree.git. Accepted: when some driver maintainer says that the patch will be applied via his tree, or when everything is ok and it got applied either at the main tree or via some other tree (fixes tree; some other maintainer's tree - when it belongs to other subsystems, etc); If you think any status change is a mistake, please send an email to the ML. - This is an automated mail sent by the patchwork system at patchwork.linuxtv.org. To stop receiving these notifications, edit your mail settings at: http://patchwork.linuxtv.org/mail/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 13/29] dvb-frontends: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/bcm3510.c:230:1: warning:
'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/itd1000.c:69:1: warning:
'itd1000_write_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
drivers/media/dvb-frontends/mt312.c:126:1: warning: 'mt312_write' uses
dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/nxt200x.c:111:1: warning:
'nxt200x_writebytes' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/stb6100.c:216:1: warning:
'stb6100_write_reg_range.constprop.3' uses dynamic stack allocation [enabled by
default]
drivers/media/dvb-frontends/stv6110.c:98:1: warning:
'stv6110_write_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/stv6110x.c:85:1: warning:
'stv6110x_write_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/tda18271c2dd.c:147:1: warning: 'WriteRegs'
uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/zl10039.c:119:1: warning: 'zl10039_write'
uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/dvb-frontends/bcm3510.c | 12 +++-
drivers/media/dvb-frontends/itd1000.c | 10 +-
drivers/media/dvb-frontends/mt312.c| 8 +++-
drivers/media/dvb-frontends/nxt200x.c | 8 +++-
drivers/media/dvb-frontends/stb6100.c | 9 -
drivers/media/dvb-frontends/stv6110.c | 9 -
drivers/media/dvb-frontends/stv6110x.c | 9 -
drivers/media/dvb-frontends/tda18271c2dd.c | 11 +--
drivers/media/dvb-frontends/zl10039.c | 9 -
9 files changed, 75 insertions(+), 10 deletions(-)
diff --git a/drivers/media/dvb-frontends/bcm3510.c
b/drivers/media/dvb-frontends/bcm3510.c
index 1b77909c0c71..efd8ce671caf 100644
--- a/drivers/media/dvb-frontends/bcm3510.c
+++ b/drivers/media/dvb-frontends/bcm3510.c
@@ -201,9 +201,19 @@ static int bcm3510_hab_send_request(struct bcm3510_state
*st, u8 *buf, int len)
static int bcm3510_do_hab_cmd(struct bcm3510_state *st, u8 cmd, u8 msgid, u8
*obuf, u8 olen, u8 *ibuf, u8 ilen)
{
- u8 ob[olen+2],ib[ilen+2];
+ u8 ob[128], ib[128];
int ret = 0;
+ if (ilen + 2 sizeof(ib)) {
+ deb_hab(do_hab_cmd: ilen=%d is too big!\n, ilen);
+ return -EREMOTEIO;
+ }
+
+ if (olen + 2 sizeof(ob)) {
+ deb_hab(do_hab_cmd: olen=%d is too big!\n, olen);
+ return -EREMOTEIO;
+ }
+
ob[0] = cmd;
ob[1] = msgid;
memcpy(ob[2],obuf,olen);
diff --git a/drivers/media/dvb-frontends/itd1000.c
b/drivers/media/dvb-frontends/itd1000.c
index c1c3400b2173..1a8e9f83a002 100644
--- a/drivers/media/dvb-frontends/itd1000.c
+++ b/drivers/media/dvb-frontends/itd1000.c
@@ -52,10 +52,18 @@ MODULE_PARM_DESC(debug, Turn on/off debugging
(default:off).);
/* don't write more than one byte with flexcop behind */
static int itd1000_write_regs(struct itd1000_state *state, u8 reg, u8 v[], u8
len)
{
- u8 buf[1+len];
+ u8 buf[80];
struct i2c_msg msg = {
.addr = state-cfg-i2c_address, .flags = 0, .buf = buf, .len =
len+1
};
+
+ if (1 + len sizeof(buf)) {
+ printk(KERN_WARNING
+ itd1000: i2c wr reg=%04x: len=%d is too big!\n,
+ reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg;
memcpy(buf[1], v, len);
diff --git a/drivers/media/dvb-frontends/mt312.c
b/drivers/media/dvb-frontends/mt312.c
index ec388c1d6913..fee0e7938f48 100644
--- a/drivers/media/dvb-frontends/mt312.c
+++ b/drivers/media/dvb-frontends/mt312.c
@@ -96,9 +96,15 @@ static int mt312_write(struct mt312_state *state, const enum
mt312_reg_addr reg,
const u8 *src, const size_t count)
{
int ret;
- u8 buf[count + 1];
+ u8 buf[80];
struct i2c_msg msg;
+ if (1 + count sizeof(buf)) {
+ printk(KERN_WARNING
+ mt312: write: len=%zd is too big!\n, count);
+ return -EREMOTEIO;
+ }
+
if (debug) {
int i;
dprintk(W(%d):, reg
[PATCHv2 06/29] iguanair: shut up a gcc warning on avr32 arch
drivers/media/rc/iguanair.c: In function 'iguanair_set_tx_carrier': drivers/media/rc/iguanair.c:304: warning: 'sevens' may be used uninitialized in this function This is clearly a gcc bug, but it doesn't hurt to add a default line at the switch to shut it up. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com --- drivers/media/rc/iguanair.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c index 19632b1c2190..67e5667db2eb 100644 --- a/drivers/media/rc/iguanair.c +++ b/drivers/media/rc/iguanair.c @@ -320,6 +320,7 @@ static int iguanair_set_tx_carrier(struct rc_dev *dev, uint32_t carrier) sevens = 2; break; case 3: + default: sevens = 1; break; } -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 29/29] lirc_zilog: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
ompilation complains about it on some archs:
drivers/staging/media/lirc/lirc_zilog.c:967:1: warning: 'read' uses
dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be 80. That should
be more than enough.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/staging/media/lirc/lirc_zilog.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/lirc/lirc_zilog.c
b/drivers/staging/media/lirc/lirc_zilog.c
index 11d5338b4f2f..9bcd52a962d4 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -941,7 +941,14 @@ static ssize_t read(struct file *filep, char *outbuf,
size_t n, loff_t *ppos)
schedule();
set_current_state(TASK_INTERRUPTIBLE);
} else {
- unsigned char buf[rbuf-chunk_size];
+ unsigned char buf[80];
+
+ if (rbuf-chunk_size sizeof(buf)) {
+ zilog_error(chunk_size is too big (%d)!\n,
+ rbuf-chunk_size);
+ ret = -EIO;
+ break;
+ }
m = lirc_buffer_read(rbuf, buf);
if (m == rbuf-chunk_size) {
ret = copy_to_user((void *)outbuf+written, buf,
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 26/29] af9015: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
ompilation complains about it on some archs:
drivers/media/usb/dvb-usb-v2/af9015.c:433:1: warning:
'af9015_eeprom_hash' uses dynamic stack allocation [enabled by default]
In this specific case, it is a gcc bug, as the size is a const, but
it is easy to just change it from const to a #define, getting rid of
the gcc warning.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/af9015.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb-v2/af9015.c
b/drivers/media/usb/dvb-usb-v2/af9015.c
index d556042cf312..da47d2392f2a 100644
--- a/drivers/media/usb/dvb-usb-v2/af9015.c
+++ b/drivers/media/usb/dvb-usb-v2/af9015.c
@@ -397,12 +397,13 @@ error:
return ret;
}
+#define AF9015_EEPROM_SIZE 256
+
/* hash (and dump) eeprom */
static int af9015_eeprom_hash(struct dvb_usb_device *d)
{
struct af9015_state *state = d_to_priv(d);
int ret, i;
- static const unsigned int AF9015_EEPROM_SIZE = 256;
u8 buf[AF9015_EEPROM_SIZE];
struct req_t req = {READ_I2C, AF9015_I2C_EEPROM, 0, 0, 1, 1, NULL};
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 12/29] s5h1420: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/s5h1420.c:851:1: warning:
's5h1420_tuner_i2c_tuner_xfer' uses dynamic stack allocation [enabled by
default]
Instead, let's enforce a limit for the buffer.
In the specific case of this frontend, only ttpci uses it. The maximum
number of messages there is two, on I2C read operations. As the logic
can add an extra operation, change the size to 3.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Patrick Boettcher p...@linuxtv.org
---
drivers/media/dvb-frontends/s5h1420.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/s5h1420.c
b/drivers/media/dvb-frontends/s5h1420.c
index e2fec9ebf947..e0b0366ccfa5 100644
--- a/drivers/media/dvb-frontends/s5h1420.c
+++ b/drivers/media/dvb-frontends/s5h1420.c
@@ -836,9 +836,16 @@ static u32 s5h1420_tuner_i2c_func(struct i2c_adapter
*adapter)
static int s5h1420_tuner_i2c_tuner_xfer(struct i2c_adapter *i2c_adap, struct
i2c_msg msg[], int num)
{
struct s5h1420_state *state = i2c_get_adapdata(i2c_adap);
- struct i2c_msg m[1 + num];
+ struct i2c_msg m[3];
u8 tx_open[2] = { CON_1, state-CON_1_val | 1 }; /* repeater stops once
there was a stop condition */
+ if (1 + num ARRAY_SIZE(m)) {
+ printk(KERN_WARNING
+ %s: i2c xfer: num=%d is too big!\n,
+ KBUILD_MODNAME, num);
+ return -EREMOTEIO;
+ }
+
memset(m, 0, sizeof(struct i2c_msg) * (1 + num));
m[0].addr = state-config-demod_address;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 08/29] cx18: disable compilation on frv arch
This driver produces a lot of errors on this arch: In file included from drivers/media/pci/cx18/cx18-driver.c:26:0: /drivers/media/pci/cx18/cx18-io.h: In function 'cx18_raw_readl': drivers/media/pci/cx18/cx18-io.h:40:2: warning: passing argument 1 of '__builtin_read32' discards 'const' qualifier from pointer target type [enabled by default] arch/frv/include/asm/mb-regs.h:24:15: note: expected 'volatile void *' but argument is of type 'const void *' ... While this is not fixed, just disable it. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com --- drivers/media/pci/cx18/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/pci/cx18/Kconfig b/drivers/media/pci/cx18/Kconfig index c675b83c43a9..10e6bc72c460 100644 --- a/drivers/media/pci/cx18/Kconfig +++ b/drivers/media/pci/cx18/Kconfig @@ -1,6 +1,7 @@ config VIDEO_CX18 tristate Conexant cx23418 MPEG encoder support depends on VIDEO_V4L2 DVB_CORE PCI I2C + depends on !FRV select I2C_ALGOBIT select VIDEOBUF_VMALLOC depends on RC_CORE -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 03/29] zoran: don't build it on alpha
This driver uses virt_to_bus() with is deprecated on Alpha: drivers/media/pci/zoran/zoran_device.c: In function 'zr36057_set_vfe': drivers/media/pci/zoran/zoran_device.c:451:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] drivers/media/pci/zoran/zoran_device.c:453:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] drivers/media/pci/zoran/zoran_device.c: In function 'zr36057_set_jpg': drivers/media/pci/zoran/zoran_device.c:796:2: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] drivers/media/pci/zoran/zoran_driver.c: In function 'v4l_fbuffer_alloc': drivers/media/pci/zoran/zoran_driver.c:241:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] drivers/media/pci/zoran/zoran_driver.c:245:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] drivers/media/pci/zoran/zoran_driver.c: In function 'jpg_fbuffer_alloc': drivers/media/pci/zoran/zoran_driver.c:334:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] drivers/media/pci/zoran/zoran_driver.c:347:5: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] drivers/media/pci/zoran/zoran_driver.c:366:6: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] As we're not even sure if it works on Alpha, better to just disable its compilation there. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com --- drivers/media/pci/zoran/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/pci/zoran/Kconfig b/drivers/media/pci/zoran/Kconfig index 26ca8702e33f..39ec35bd21a5 100644 --- a/drivers/media/pci/zoran/Kconfig +++ b/drivers/media/pci/zoran/Kconfig @@ -1,6 +1,7 @@ config VIDEO_ZORAN tristate Zoran ZR36057/36067 Video For Linux depends on PCI I2C_ALGOBIT VIDEO_V4L2 VIRT_TO_BUS + depends on !ALPHA help Say Y for support for MJPEG capture cards based on the Zoran 36057/36067 PCI controller chipset. This includes the Iomega -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 15/29] stb0899_drv: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/stb0899_drv.c:540:1: warning:
'stb0899_write_regs' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Michael Krufky mkru...@linuxtv.org
Cc: Zoran Turalija zoran.tural...@gmail.com
Cc: Reinhard Nißl rni...@gmx.de
---
drivers/media/dvb-frontends/stb0899_drv.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/stb0899_drv.c
b/drivers/media/dvb-frontends/stb0899_drv.c
index 3dd5714eadba..9df77899b219 100644
--- a/drivers/media/dvb-frontends/stb0899_drv.c
+++ b/drivers/media/dvb-frontends/stb0899_drv.c
@@ -499,7 +499,7 @@ err:
int stb0899_write_regs(struct stb0899_state *state, unsigned int reg, u8
*data, u32 count)
{
int ret;
- u8 buf[2 + count];
+ u8 buf[80];
struct i2c_msg i2c_msg = {
.addr = state-config-demod_address,
.flags = 0,
@@ -507,6 +507,13 @@ int stb0899_write_regs(struct stb0899_state *state,
unsigned int reg, u8 *data,
.len= 2 + count
};
+ if (2 + count sizeof(buf)) {
+ printk(KERN_WARNING
+ %s: i2c wr reg=%04x: len=%d is too big!\n,
+ KBUILD_MODNAME, reg, count);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg 8;
buf[1] = reg 0xff;
memcpy(buf[2], data, count);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 25/29] dw2102: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
ompilation complains about it on some archs:
drivers/media/usb/dvb-usb/dw2102.c:368:1: warning:
'dw2102_earda_i2c_transfer' uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb/dw2102.c:449:1: warning:
'dw2104_i2c_transfer' uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb/dw2102.c:512:1: warning:
'dw3101_i2c_transfer' uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb/dw2102.c:621:1: warning: 's6x0_i2c_transfer'
uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (80 bytes).
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Igor M. Liplianin liplia...@me.by
Cc: Andrey Pavlenko andrey.a.pavle...@gmail.com
Cc: Antti Palosaari cr...@iki.fi
Cc: Stephan Hilb step...@ecshi.net
---
drivers/media/usb/dvb-usb/dw2102.c | 87 +-
1 file changed, 77 insertions(+), 10 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/dw2102.c
b/drivers/media/usb/dvb-usb/dw2102.c
index 6136a2c7dbfd..1907a242d93f 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -308,7 +308,14 @@ static int dw2102_earda_i2c_transfer(struct i2c_adapter
*adap, struct i2c_msg ms
case 2: {
/* read */
/* first write first register number */
- u8 ibuf[msg[1].len + 2], obuf[3];
+ u8 ibuf[80], obuf[3];
+
+ if (2 + msg[1].len sizeof(ibuf)) {
+ warn(i2c rd: len=%d is too big!\n,
+msg[1].len);
+ return -EREMOTEIO;
+ }
+
obuf[0] = msg[0].addr 1;
obuf[1] = msg[0].len;
obuf[2] = msg[0].buf[0];
@@ -325,7 +332,14 @@ static int dw2102_earda_i2c_transfer(struct i2c_adapter
*adap, struct i2c_msg ms
switch (msg[0].addr) {
case 0x68: {
/* write to register */
- u8 obuf[msg[0].len + 2];
+ u8 obuf[80];
+
+ if (2 + msg[0].len sizeof(obuf)) {
+ warn(i2c wr: len=%d is too big!\n,
+msg[1].len);
+ return -EREMOTEIO;
+ }
+
obuf[0] = msg[0].addr 1;
obuf[1] = msg[0].len;
memcpy(obuf + 2, msg[0].buf, msg[0].len);
@@ -335,7 +349,14 @@ static int dw2102_earda_i2c_transfer(struct i2c_adapter
*adap, struct i2c_msg ms
}
case 0x61: {
/* write to tuner */
- u8 obuf[msg[0].len + 2];
+ u8 obuf[80];
+
+ if (2 + msg[0].len sizeof(obuf)) {
+ warn(i2c wr: len=%d is too big!\n,
+msg[1].len);
+ return -EREMOTEIO;
+ }
+
obuf[0] = msg[0].addr 1;
obuf[1] = msg[0].len;
memcpy(obuf + 2, msg[0].buf, msg[0].len);
@@ -401,7 +422,14 @@ static int dw2104_i2c_transfer(struct i2c_adapter *adap,
struct i2c_msg msg[], i
default: {
if (msg[j].flags == I2C_M_RD) {
/* read registers */
- u8 ibuf[msg[j].len + 2];
+ u8 ibuf[80];
+
+ if (2 + msg[j].len sizeof(ibuf)) {
+ warn(i2c rd: len=%d is too big!\n,
+msg[j].len);
+ return -EREMOTEIO;
+ }
+
dw210x_op_rw(d-udev, 0xc3,
(msg[j].addr 1) + 1, 0,
ibuf, msg[j].len + 2,
@@ -430,7 +458,14 @@ static int dw2104_i2c_transfer(struct i2c_adapter *adap,
struct i2c_msg msg[], i
} while (len 0);
} else {
/* write registers */
- u8 obuf[msg[j].len + 2];
+ u8 obuf[80];
+
+ if (2 + msg[j].len sizeof(obuf)) {
+ warn(i2c wr: len=%d is too big!\n,
+msg[j].len);
+ return -EREMOTEIO;
+ }
+
obuf[0] = msg[j].addr 1;
obuf[1] = msg[j].len;
[PATCHv2 14/29] dvb-frontends: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/af9013.c:77:1: warning:
'af9013_wr_regs_i2c' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/af9033.c:188:1: warning:
'af9033_wr_reg_val_tab' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/af9033.c:68:1: warning: 'af9033_wr_regs'
uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/bcm3510.c:230:1: warning:
'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/cxd2820r_core.c:84:1: warning:
'cxd2820r_rd_regs_i2c.isra.1' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/rtl2830.c:56:1: warning: 'rtl2830_wr' uses
dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/rtl2832.c:187:1: warning: 'rtl2832_wr' uses
dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/tda10071.c:52:1: warning:
'tda10071_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/tda10071.c:84:1: warning:
'tda10071_rd_regs' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/af9013.c| 9 -
drivers/media/dvb-frontends/af9033.c| 18 --
drivers/media/dvb-frontends/cxd2820r_core.c | 18 --
drivers/media/dvb-frontends/rtl2830.c | 9 -
drivers/media/dvb-frontends/rtl2832.c | 9 -
drivers/media/dvb-frontends/tda10071.c | 18 --
6 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/drivers/media/dvb-frontends/af9013.c
b/drivers/media/dvb-frontends/af9013.c
index a204f2828820..f968dc0e5de9 100644
--- a/drivers/media/dvb-frontends/af9013.c
+++ b/drivers/media/dvb-frontends/af9013.c
@@ -50,7 +50,7 @@ static int af9013_wr_regs_i2c(struct af9013_state *priv, u8
mbox, u16 reg,
const u8 *val, int len)
{
int ret;
- u8 buf[3+len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv-config.i2c_addr,
@@ -60,6 +60,13 @@ static int af9013_wr_regs_i2c(struct af9013_state *priv, u8
mbox, u16 reg,
}
};
+ if (3 + len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+%s: i2c wr reg=%04x: len=%d is too big!\n,
+KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = (reg 8) 0xff;
buf[1] = (reg 0) 0xff;
buf[2] = mbox;
diff --git a/drivers/media/dvb-frontends/af9033.c
b/drivers/media/dvb-frontends/af9033.c
index a777b4b944eb..efa2efafa97f 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -40,7 +40,7 @@ static int af9033_wr_regs(struct af9033_state *state, u32
reg, const u8 *val,
int len)
{
int ret;
- u8 buf[3 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = state-cfg.i2c_addr,
@@ -50,6 +50,13 @@ static int af9033_wr_regs(struct af9033_state *state, u32
reg, const u8 *val,
}
};
+ if (3 + len sizeof(buf)) {
+ dev_warn(state-i2c-dev,
+%s: i2c wr reg=%04x: len=%d is too big!\n,
+KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = (reg 16) 0xff;
buf[1] = (reg 8) 0xff;
buf[2] = (reg 0) 0xff;
@@ -161,7 +168,14 @@ static int af9033_wr_reg_val_tab(struct af9033_state
*state,
const struct reg_val *tab, int tab_len)
{
int ret, i, j;
- u8 buf[tab_len];
+ u8 buf[80];
+
+ if (tab_len sizeof(buf)) {
+ dev_warn(state-i2c-dev,
+%s: i2c wr len=%d is too big!\n,
+KBUILD_MODNAME, tab_len);
+ return -EREMOTEIO;
+ }
dev_dbg(state-i2c-dev, %s: tab_len=%d\n, __func__, tab_len);
diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c
b/drivers/media/dvb-frontends/cxd2820r_core.c
index d9eeeb1dfa96..8ef96a96b141 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++
[PATCHv2 16/29] stv0367: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/stv0367.c:791:1: warning:
'stv0367_writeregs.constprop.4' uses dynamic stack allocation [enabled by
default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Jiri Kosina jkos...@suse.cz
Cc: Geert Uytterhoeven ge...@linux-m68k.org
---
drivers/media/dvb-frontends/stv0367.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/stv0367.c
b/drivers/media/dvb-frontends/stv0367.c
index 7b6dba3ce55e..28294b3be319 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -767,7 +767,7 @@ static struct st_register def0367cab[STV0367CAB_NBREGS] = {
static
int stv0367_writeregs(struct stv0367_state *state, u16 reg, u8 *data, int len)
{
- u8 buf[len + 2];
+ u8 buf[80];
struct i2c_msg msg = {
.addr = state-config-demod_address,
.flags = 0,
@@ -776,6 +776,14 @@ int stv0367_writeregs(struct stv0367_state *state, u16
reg, u8 *data, int len)
};
int ret;
+ if (2 + len sizeof(buf)) {
+ printk(KERN_WARNING
+ %s: i2c wr reg=%04x: len=%d is too big!\n,
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
+
buf[0] = MSB(reg);
buf[1] = LSB(reg);
memcpy(buf + 2, data, len);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 18/29] av7110_hw: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/pci/ttpci/av7110_hw.c:510:1: warning: 'av7110_fw_cmd'
uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In the specific case of this driver, the maximum fw command size
is 6 + 2, as checked using:
$ git grep -A1 av7110_fw_cmd drivers/media/pci/ttpci/
So, use 8 for the buffer size.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/pci/ttpci/av7110_hw.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/media/pci/ttpci/av7110_hw.c
b/drivers/media/pci/ttpci/av7110_hw.c
index f1cbfe526989..ca6672a29fbc 100644
--- a/drivers/media/pci/ttpci/av7110_hw.c
+++ b/drivers/media/pci/ttpci/av7110_hw.c
@@ -22,7 +22,7 @@
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
* Or, point your browser to http://www.gnu.org/copyleft/gpl.html
*
- * the project's page is at http://www.linuxtv.org/
+ * the project's page is at http://www.linuxtv.org/
*/
/* for debugging ARM communication: */
@@ -488,11 +488,18 @@ static int av7110_send_fw_cmd(struct av7110 *av7110, u16*
buf, int length)
int av7110_fw_cmd(struct av7110 *av7110, int type, int com, int num, ...)
{
va_list args;
- u16 buf[num + 2];
+ u16 buf[8];
int i, ret;
// dprintk(4, %p\n, av7110);
+ if (2 + num sizeof(buf)) {
+ printk(KERN_WARNING
+ %s: %s len=%d is too big!\n,
+ KBUILD_MODNAME, __func__, num);
+ return -EREMOTEIO;
+ }
+
buf[0] = ((type 8) | com);
buf[1] = num;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 09/29] radio-si470x-i2c: fix a warning on ia64
on ia64, those warnings appear:
drivers/media/radio/si470x/radio-si470x-i2c.c:470:12: warning:
'si470x_i2c_suspend' defined but not used [-Wunused-function]
drivers/media/radio/si470x/radio-si470x-i2c.c:487:12: warning:
'si470x_i2c_resume' defined but not used [-Wunused-function]
They're caused because the PM logic uses this define:
#define SET_SYSTEM_SLEEP_PM_OPS()
With is only defined for CONFIG_PM_SLEEP.
So, change the logic there to test for CONFIG_PM_SLEEP, instead of
CONFIG_PM.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/radio/si470x/radio-si470x-i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index e5fc9acd0c4f..2a497c80c77f 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -463,7 +463,7 @@ static int si470x_i2c_remove(struct i2c_client *client)
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
/*
* si470x_i2c_suspend - suspend the device
*/
@@ -509,7 +509,7 @@ static struct i2c_driver si470x_i2c_driver = {
.driver = {
.name = si470x,
.owner = THIS_MODULE,
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
.pm = si470x_i2c_pm,
#endif
},
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 01/29] tda9887: remove an warning when compiling for alpha
There's no need to zero the buffer, as if the routine gets an error, rc will be different than one. That fixes the following warning: drivers/media/tuners/tda9887.c: In function 'tda9887_status': drivers/media/tuners/tda9887.c:539:2: warning: value computed is not used [-Wunused-value] Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com --- drivers/media/tuners/tda9887.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/tuners/tda9887.c b/drivers/media/tuners/tda9887.c index 35c535ba..9823248d743f 100644 --- a/drivers/media/tuners/tda9887.c +++ b/drivers/media/tuners/tda9887.c @@ -536,8 +536,8 @@ static int tda9887_status(struct dvb_frontend *fe) unsigned char buf[1]; int rc; - memset(buf,0,sizeof(buf)); - if (1 != (rc = tuner_i2c_xfer_recv(priv-i2c_props,buf,1))) + rc = tuner_i2c_xfer_recv(priv-i2c_props, buf, 1); + if (rc != 1) tuner_info(i2c i/o error: rc == %d (should be 1)\n, rc); dump_read_message(fe, buf); return 0; -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 10/29] rc: Fir warnings on m68k arch
Fix the following warnings:
drivers/media/rc/fintek-cir.c: In function 'fintek_cr_write':
drivers/media/rc/fintek-cir.c:45:2: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/fintek-cir.c:46:2: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/fintek-cir.c: In function 'fintek_cr_read':
drivers/media/rc/fintek-cir.c:54:2: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/fintek-cir.c:55:8: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/fintek-cir.c: In function 'fintek_config_mode_enable':
drivers/media/rc/fintek-cir.c:80:2: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/fintek-cir.c:81:2: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/fintek-cir.c: In function 'fintek_config_mode_disable':
drivers/media/rc/fintek-cir.c:87:2: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c: In function 'nvt_cr_write':
drivers/media/rc/nuvoton-cir.c:45:2: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c:46:2: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c: In function 'nvt_cr_read':
drivers/media/rc/nuvoton-cir.c:52:2: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c:53:9: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c: In function 'nvt_efm_enable':
drivers/media/rc/nuvoton-cir.c:74:2: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c:75:2: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c: In function 'nvt_efm_disable':
drivers/media/rc/nuvoton-cir.c:81:2: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c: In function 'nvt_select_logical_dev':
drivers/media/rc/nuvoton-cir.c:91:2: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/media/rc/nuvoton-cir.c:92:2: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
Those are caused because the I/O port is u32, instead of u8.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/rc/fintek-cir.h | 4 ++--
drivers/media/rc/nuvoton-cir.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/rc/fintek-cir.h b/drivers/media/rc/fintek-cir.h
index 82516a1d39b0..b698f3d2ced9 100644
--- a/drivers/media/rc/fintek-cir.h
+++ b/drivers/media/rc/fintek-cir.h
@@ -76,8 +76,8 @@ struct fintek_dev {
} tx;
/* Config register index/data port pair */
- u8 cr_ip;
- u8 cr_dp;
+ u32 cr_ip;
+ u32 cr_dp;
/* hardware I/O settings */
unsigned long cir_addr;
diff --git a/drivers/media/rc/nuvoton-cir.h b/drivers/media/rc/nuvoton-cir.h
index 7c3674ff5ea2..07e83108df0f 100644
--- a/drivers/media/rc/nuvoton-cir.h
+++ b/drivers/media/rc/nuvoton-cir.h
@@ -84,8 +84,8 @@ struct nvt_dev {
} tx;
/* EFER Config register index/data pair */
- u8 cr_efir;
- u8 cr_efdr;
+ u32 cr_efir;
+ u32 cr_efdr;
/* hardware I/O settings */
unsigned long cir_addr;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 11/29] uvc/lirc_serial: Fix some warnings on parisc arch
On this arch, usec is not unsigned long. So, we need to typecast,
in order to remove those warnings:
drivers/media/usb/uvc/uvc_video.c: In function 'uvc_video_clock_update':
drivers/media/usb/uvc/uvc_video.c:678:2: warning: format '%lu' expects
argument of type 'long unsigned int', but argument 9 has type
'__kernel_suseconds_t' [-Wformat]
drivers/staging/media/lirc/lirc_serial.c: In function 'irq_handler':
drivers/staging/media/lirc/lirc_serial.c:707:5: warning: format '%lx'
expects argument of type 'long unsigned int', but argument 6 has type
'__kernel_suseconds_t' [-Wformat]
drivers/staging/media/lirc/lirc_serial.c:707:5: warning: format '%lx'
expects argument of type 'long unsigned int', but argument 7 has type
'__kernel_suseconds_t' [-Wformat]
drivers/staging/media/lirc/lirc_serial.c:719:5: warning: format '%lx'
expects argument of type 'long unsigned int', but argument 6 has type
'__kernel_suseconds_t' [-Wformat]
drivers/staging/media/lirc/lirc_serial.c:719:5: warning: format '%lx'
expects argument of type 'long unsigned int', but argument 7 has type
'__kernel_suseconds_t' [-Wformat]
drivers/staging/media/lirc/lirc_serial.c:728:6: warning: format '%lx'
expects argument of type 'long unsigned int', but argument 6 has type
'__kernel_suseconds_t' [-Wformat]
drivers/staging/media/lirc/lirc_serial.c:728:6: warning: format '%lx'
expects argument of type 'long unsigned int', but argument 7 has type
'__kernel_suseconds_t' [-Wformat]
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/usb/uvc/uvc_video.c| 3 ++-
drivers/staging/media/lirc/lirc_serial.c | 9 ++---
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index 3394c3432011..899cb6d1c4a4 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -680,7 +680,8 @@ void uvc_video_clock_update(struct uvc_streaming *stream,
stream-dev-name,
sof 16, div_u64(((u64)sof 0x) * 100LLU, 65536),
y, ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC,
- v4l2_buf-timestamp.tv_sec, v4l2_buf-timestamp.tv_usec,
+ v4l2_buf-timestamp.tv_sec,
+ (unsigned long)v4l2_buf-timestamp.tv_usec,
x1, first-host_sof, first-dev_sof,
x2, last-host_sof, last-dev_sof, y1, y2);
diff --git a/drivers/staging/media/lirc/lirc_serial.c
b/drivers/staging/media/lirc/lirc_serial.c
index af08e677b60f..7b3be2346b4b 100644
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ b/drivers/staging/media/lirc/lirc_serial.c
@@ -707,7 +707,8 @@ static irqreturn_t irq_handler(int i, void *blah)
pr_warn(ignoring spike: %d %d %lx %lx %lx
%lx\n,
dcd, sense,
tv.tv_sec, lasttv.tv_sec,
- tv.tv_usec, lasttv.tv_usec);
+ (unsigned long)tv.tv_usec,
+ (unsigned long)lasttv.tv_usec);
continue;
}
@@ -719,7 +720,8 @@ static irqreturn_t irq_handler(int i, void *blah)
pr_warn(%d %d %lx %lx %lx %lx\n,
dcd, sense,
tv.tv_sec, lasttv.tv_sec,
- tv.tv_usec, lasttv.tv_usec);
+ (unsigned long)tv.tv_usec,
+ (unsigned long)lasttv.tv_usec);
data = PULSE_MASK;
} else if (deltv 15) {
data = PULSE_MASK; /* really long time */
@@ -728,7 +730,8 @@ static irqreturn_t irq_handler(int i, void *blah)
pr_warn(AI: %d %d %lx %lx %lx
%lx\n,
dcd, sense,
tv.tv_sec, lasttv.tv_sec,
- tv.tv_usec, lasttv.tv_usec);
+ (unsigned long)tv.tv_usec,
+ (unsigned long)lasttv.tv_usec);
/*
* detecting pulse while this
* MUST be a space!
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 19/29] tuners: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:66:1: warning:
'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:98:1: warning:
'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:90:1: warning:
'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18218.c:92:1: warning:
'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/e4000.c| 18 --
drivers/media/tuners/fc2580.c | 18 --
drivers/media/tuners/tda18212.c | 18 --
drivers/media/tuners/tda18218.c | 18 --
4 files changed, 64 insertions(+), 8 deletions(-)
diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
index ad9309da4a91..235e90251609 100644
--- a/drivers/media/tuners/e4000.c
+++ b/drivers/media/tuners/e4000.c
@@ -24,7 +24,7 @@
static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[1 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv-cfg-i2c_addr,
@@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8
*val, int len)
}
};
+ if (1 + len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+%s: i2c wr reg=%04x: len=%d is too big!\n,
+KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg;
memcpy(buf[1], val, len);
@@ -53,7 +60,7 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8
*val, int len)
static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[len];
+ u8 buf[80];
struct i2c_msg msg[2] = {
{
.addr = priv-cfg-i2c_addr,
@@ -68,6 +75,13 @@ static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8
*val, int len)
}
};
+ if (len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+%s: i2c rd reg=%04x: len=%d is too big!\n,
+KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
ret = i2c_transfer(priv-i2c, msg, 2);
if (ret == 2) {
memcpy(val, buf, len);
diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
index 81f38aae9c66..e27bf5be311d 100644
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -41,7 +41,7 @@
static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[1 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv-cfg-i2c_addr,
@@ -51,6 +51,13 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg,
u8 *val, int len)
}
};
+ if (1 + len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+%s: i2c wr reg=%04x: len=%d is too big!\n,
+KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg;
memcpy(buf[1], val, len);
@@ -69,7 +76,7 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg,
u8 *val, int len)
static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[len];
+ u8 buf[80];
struct i2c_msg msg[2] = {
{
.addr = priv-cfg-i2c_addr,
@@ -84,6 +91,13 @@ static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg,
u8 *val, int len)
[PATCHv2 02/29] radio-shark: remove a warning when CONFIG_PM is not defined
On alpha, allyesconfig doesn't have CONFIG_PM, and produces the following
warnings:
drivers/media/radio/radio-shark.c:274:13: warning: 'shark_resume_leds'
defined but not used [-Wunused-function]
drivers/media/radio/radio-shark2.c:240:13: warning: 'shark_resume_leds'
defined but not used [-Wunused-function]
That's because those functions are used only at device resume.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/radio/radio-shark.c | 2 ++
drivers/media/radio/radio-shark2.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/media/radio/radio-shark.c
b/drivers/media/radio/radio-shark.c
index b91477212413..3db8a8cfe1a8 100644
--- a/drivers/media/radio/radio-shark.c
+++ b/drivers/media/radio/radio-shark.c
@@ -271,6 +271,7 @@ static void shark_unregister_leds(struct shark_device
*shark)
cancel_work_sync(shark-led_work);
}
+#ifdef CONFIG_PM
static void shark_resume_leds(struct shark_device *shark)
{
if (test_bit(BLUE_IS_PULSE, shark-brightness_new))
@@ -280,6 +281,7 @@ static void shark_resume_leds(struct shark_device *shark)
set_bit(RED_LED, shark-brightness_new);
schedule_work(shark-led_work);
}
+#endif
#else
static int shark_register_leds(struct shark_device *shark, struct device *dev)
{
diff --git a/drivers/media/radio/radio-shark2.c
b/drivers/media/radio/radio-shark2.c
index 9fb669721e66..d86d90dab8bf 100644
--- a/drivers/media/radio/radio-shark2.c
+++ b/drivers/media/radio/radio-shark2.c
@@ -237,6 +237,7 @@ static void shark_unregister_leds(struct shark_device
*shark)
cancel_work_sync(shark-led_work);
}
+#ifdef CONFIG_PM
static void shark_resume_leds(struct shark_device *shark)
{
int i;
@@ -246,6 +247,7 @@ static void shark_resume_leds(struct shark_device *shark)
schedule_work(shark-led_work);
}
+#endif
#else
static int shark_register_leds(struct shark_device *shark, struct device *dev)
{
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 05/29] tef6862: fix warning on avr32 arch
On avr32 arch, we get those warnings:
drivers/media/radio/tef6862.c:59:1: warning: MODE_SHIFT redefined
In file included from
/devel/v4l/ktest-build/arch/avr32/include/asm/ptrace.h:11,
arch/avr32/include/uapi/asm/ptrace.h:41:1: warning: this is the
location of the previous definition
Prefix MSA_ to the MSA register bitmap macros, to avoid reusing the same symbol.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/radio/tef6862.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/media/radio/tef6862.c b/drivers/media/radio/tef6862.c
index 06ac69245ca1..69e3245a58a0 100644
--- a/drivers/media/radio/tef6862.c
+++ b/drivers/media/radio/tef6862.c
@@ -48,15 +48,15 @@
#define WM_SUB_TEST0xF
/* Different modes of the MSA register */
-#define MODE_BUFFER0x0
-#define MODE_PRESET0x1
-#define MODE_SEARCH0x2
-#define MODE_AF_UPDATE 0x3
-#define MODE_JUMP 0x4
-#define MODE_CHECK 0x5
-#define MODE_LOAD 0x6
-#define MODE_END 0x7
-#define MODE_SHIFT 5
+#define MSA_MODE_BUFFER0x0
+#define MSA_MODE_PRESET0x1
+#define MSA_MODE_SEARCH0x2
+#define MSA_MODE_AF_UPDATE 0x3
+#define MSA_MODE_JUMP 0x4
+#define MSA_MODE_CHECK 0x5
+#define MSA_MODE_LOAD 0x6
+#define MSA_MODE_END 0x7
+#define MSA_MODE_SHIFT 5
struct tef6862_state {
struct v4l2_subdev sd;
@@ -114,7 +114,7 @@ static int tef6862_s_frequency(struct v4l2_subdev *sd,
const struct v4l2_frequen
clamp(freq, TEF6862_LO_FREQ, TEF6862_HI_FREQ);
pll = 1964 + ((freq - TEF6862_LO_FREQ) * 20) / FREQ_MUL;
- i2cmsg[0] = (MODE_PRESET MODE_SHIFT) | WM_SUB_PLLM;
+ i2cmsg[0] = (MSA_MODE_PRESET MSA_MODE_SHIFT) | WM_SUB_PLLM;
i2cmsg[1] = (pll 8) 0xff;
i2cmsg[2] = pll 0xff;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 28/29] mxl111sf: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/usb/dvb-usb-v2/mxl111sf.c:74:1: warning:
'mxl111sf_ctrl_msg' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (80 bytes).
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Michael Krufky mkru...@kernellabs.com
---
drivers/media/usb/dvb-usb-v2/mxl111sf.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
index e97964ef7f56..6538fd54c84e 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
@@ -57,7 +57,12 @@ int mxl111sf_ctrl_msg(struct dvb_usb_device *d,
{
int wo = (rbuf == NULL || rlen == 0); /* write-only */
int ret;
- u8 sndbuf[1+wlen];
+ u8 sndbuf[80];
+
+ if (1 + wlen sizeof(sndbuf)) {
+ pr_warn(%s: len=%d is too big!\n, __func__, wlen);
+ return -EREMOTEIO;
+ }
pr_debug(%s(wlen = %d, rlen = %d)\n, __func__, wlen, rlen);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 20/29] tuner-xc2028: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/tuners/tuner-xc2028.c:651:1: warning: 'load_firmware'
uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In the specific case of this driver, the maximum limit is 80, used only
on tm6000 driver. This limit is due to the size of the USB control URBs.
Ok, it would be theoretically possible to use a bigger size on PCI
devices, but the firmware load time is already good enough. Anyway,
if some usage requires more, it is just a matter of also increasing
the buffer size at load_firmware().
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/tuners/tuner-xc2028.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/tuners/tuner-xc2028.c
b/drivers/media/tuners/tuner-xc2028.c
index e287a7417319..387934b22a2b 100644
--- a/drivers/media/tuners/tuner-xc2028.c
+++ b/drivers/media/tuners/tuner-xc2028.c
@@ -547,7 +547,10 @@ static int load_firmware(struct dvb_frontend *fe, unsigned
int type,
{
struct xc2028_data *priv = fe-tuner_priv;
intpos, rc;
- unsigned char *p, *endp, buf[priv-ctrl.max_len];
+ unsigned char *p, *endp, buf[80];
+
+ if (priv-ctrl.max_len sizeof(buf))
+ priv-ctrl.max_len = sizeof(buf);
tuner_dbg(%s called\n, __func__);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 07/29] platform drivers: Fix build on cris and frv archs
On cris and frv archs, the functions below aren't defined: drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_read': drivers/media/platform/sh_veu.c:228:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_write': drivers/media/platform/sh_veu.c:234:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read': drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write': drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read': drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write': drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_setup': drivers/media/platform/soc_camera/rcar_vin.c:284:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_request_capture_stop': drivers/media/platform/soc_camera/rcar_vin.c:353:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] While this is not fixed, remove those 3 drivers from building on those archs. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com Cc: sta...@vger.kernel.org --- drivers/media/platform/Kconfig| 2 ++ drivers/media/platform/soc_camera/Kconfig | 1 + 2 files changed, 3 insertions(+) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 3d9beef60325..ab4b22c8ee85 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -205,6 +205,7 @@ config VIDEO_SAMSUNG_EXYNOS_GSC config VIDEO_SH_VEU tristate SuperH VEU mem2mem video processing driver depends on VIDEO_DEV VIDEO_V4L2 HAS_DMA + depends on !CRIS !FRV select VIDEOBUF2_DMA_CONTIG select V4L2_MEM2MEM_DEV help @@ -214,6 +215,7 @@ config VIDEO_SH_VEU config VIDEO_RENESAS_VSP1 tristate Renesas VSP1 Video Processing Engine depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API HAS_DMA + depends on !CRIS !FRV select VIDEOBUF2_DMA_CONTIG ---help--- This is a V4L2 driver for the Renesas VSP1 video processing engine. diff --git a/drivers/media/platform/soc_camera/Kconfig b/drivers/media/platform/soc_camera/Kconfig index af39c4665554..df11f69aeba5 100644 --- a/drivers/media/platform/soc_camera/Kconfig +++ b/drivers/media/platform/soc_camera/Kconfig @@ -47,6 +47,7 @@ config VIDEO_PXA27x config VIDEO_RCAR_VIN tristate R-Car Video Input (VIN) support depends on VIDEO_DEV SOC_CAMERA + depends on !CRIS !FRV select VIDEOBUF2_DMA_CONTIG select SOC_CAMERA_SCALE_CROP ---help--- -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 27/29] af9035: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
ompilation complains about it on some archs:
drivers/media/usb/dvb-usb-v2/af9035.c:142:1: warning: 'af9035_wr_regs'
uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb-v2/af9035.c:305:1: warning:
'af9035_i2c_master_xfer' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (80 bytes).
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/usb/dvb-usb-v2/af9035.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
b/drivers/media/usb/dvb-usb-v2/af9035.c
index 1ea17dc2a76e..f43e9f336204 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -126,10 +126,16 @@ exit:
/* write multiple registers */
static int af9035_wr_regs(struct dvb_usb_device *d, u32 reg, u8 *val, int len)
{
- u8 wbuf[6 + len];
+ u8 wbuf[80];
u8 mbox = (reg 16) 0xff;
struct usb_req req = { CMD_MEM_WR, mbox, sizeof(wbuf), wbuf, 0, NULL };
+ if (6 + len sizeof(wbuf)) {
+ dev_warn(d-udev-dev, %s: i2c wr: len=%d is too big!\n,
+KBUILD_MODNAME, len);
+ return -EREMOTEIO;
+ }
+
wbuf[0] = len;
wbuf[1] = 2;
wbuf[2] = 0;
@@ -228,9 +234,16 @@ static int af9035_i2c_master_xfer(struct i2c_adapter *adap,
msg[1].len);
} else {
/* I2C */
- u8 buf[5 + msg[0].len];
+ u8 buf[80];
struct usb_req req = { CMD_I2C_RD, 0, sizeof(buf),
buf, msg[1].len, msg[1].buf };
+
+ if (5 + msg[0].len sizeof(buf)) {
+ dev_warn(d-udev-dev,
+%s: i2c xfer: len=%d is too big!\n,
+KBUILD_MODNAME, msg[0].len);
+ return -EREMOTEIO;
+ }
req.mbox |= ((msg[0].addr 0x80)3);
buf[0] = msg[1].len;
buf[1] = msg[0].addr 1;
@@ -257,9 +270,16 @@ static int af9035_i2c_master_xfer(struct i2c_adapter *adap,
msg[0].len - 3);
} else {
/* I2C */
- u8 buf[5 + msg[0].len];
+ u8 buf[80];
struct usb_req req = { CMD_I2C_WR, 0, sizeof(buf), buf,
0, NULL };
+
+ if (5 + msg[0].len sizeof(buf)) {
+ dev_warn(d-udev-dev,
+%s: i2c xfer: len=%d is too big!\n,
+KBUILD_MODNAME, msg[0].len);
+ return -EREMOTEIO;
+ }
req.mbox |= ((msg[0].addr 0x80)3);
buf[0] = msg[0].len;
buf[1] = msg[0].addr 1;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 23/29] cxusb: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/usb/dvb-usb/cxusb.c:209:1: warning: 'cxusb_i2c_xfer' uses
dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb/cxusb.c:69:1: warning: 'cxusb_ctrl_msg' uses
dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (80 bytes).
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Michael Krufky mkru...@linuxtv.org
---
drivers/media/usb/dvb-usb/cxusb.c | 38 ++
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/cxusb.c
b/drivers/media/usb/dvb-usb/cxusb.c
index 3940bb0f9ef6..7d21def6b145 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -57,7 +57,14 @@ static int cxusb_ctrl_msg(struct dvb_usb_device *d,
u8 cmd, u8 *wbuf, int wlen, u8 *rbuf, int rlen)
{
int wo = (rbuf == NULL || rlen == 0); /* write-only */
- u8 sndbuf[1+wlen];
+ u8 sndbuf[80];
+
+ if (1 + wlen sizeof(sndbuf)) {
+ warn(i2c wr: len=%d is too big!\n,
+wlen);
+ return -EREMOTEIO;
+ }
+
memset(sndbuf, 0, 1+wlen);
sndbuf[0] = cmd;
@@ -158,7 +165,13 @@ static int cxusb_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg msg[],
if (msg[i].flags I2C_M_RD) {
/* read only */
- u8 obuf[3], ibuf[1+msg[i].len];
+ u8 obuf[3], ibuf[80];
+
+ if (1 + msg[i].len sizeof(ibuf)) {
+ warn(i2c rd: len=%d is too big!\n,
+msg[i].len);
+ return -EREMOTEIO;
+ }
obuf[0] = 0;
obuf[1] = msg[i].len;
obuf[2] = msg[i].addr;
@@ -172,7 +185,18 @@ static int cxusb_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg msg[],
} else if (i+1 num (msg[i+1].flags I2C_M_RD)
msg[i].addr == msg[i+1].addr) {
/* write to then read from same address */
- u8 obuf[3+msg[i].len], ibuf[1+msg[i+1].len];
+ u8 obuf[80], ibuf[80];
+
+ if (3 + msg[i].len sizeof(obuf)) {
+ warn(i2c wr: len=%d is too big!\n,
+msg[i].len);
+ return -EREMOTEIO;
+ }
+ if (1 + msg[i + 1].len sizeof(ibuf)) {
+ warn(i2c rd: len=%d is too big!\n,
+msg[i + 1].len);
+ return -EREMOTEIO;
+ }
obuf[0] = msg[i].len;
obuf[1] = msg[i+1].len;
obuf[2] = msg[i].addr;
@@ -191,7 +215,13 @@ static int cxusb_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg msg[],
i++;
} else {
/* write only */
- u8 obuf[2+msg[i].len], ibuf;
+ u8 obuf[80], ibuf;
+
+ if (2 + msg[i].len sizeof(obuf)) {
+ warn(i2c wr: len=%d is too big!\n,
+msg[i].len);
+ return -EREMOTEIO;
+ }
obuf[0] = msg[i].addr;
obuf[1] = msg[i].len;
memcpy(obuf[2], msg[i].buf, msg[i].len);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 21/29] cimax2: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/pci/cx23885/cimax2.c
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/pci/cx23885/cimax2.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/cx23885/cimax2.c
b/drivers/media/pci/cx23885/cimax2.c
index 7344849183a7..e6515f48aa8d 100644
--- a/drivers/media/pci/cx23885/cimax2.c
+++ b/drivers/media/pci/cx23885/cimax2.c
@@ -125,7 +125,7 @@ static int netup_write_i2c(struct i2c_adapter *i2c_adap, u8
addr, u8 reg,
u8 *buf, int len)
{
int ret;
- u8 buffer[len + 1];
+ u8 buffer[80];
struct i2c_msg msg = {
.addr = addr,
@@ -134,6 +134,13 @@ static int netup_write_i2c(struct i2c_adapter *i2c_adap,
u8 addr, u8 reg,
.len= len + 1
};
+ if (1 + len sizeof(buffer)) {
+ printk(KERN_WARNING
+ %s: i2c wr reg=%04x: len=%d is too big!\n,
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buffer[0] = reg;
memcpy(buffer[1], buf, len);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 17/29] stv090x: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/stv090x.c:750:1: warning:
'stv090x_write_regs.constprop.6' uses dynamic stack allocation [enabled by
default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Manu Abraham m...@linuxtv.org
Cc: Alexey Khoroshilov khoroshi...@ispras.ru
Cc: Andreas Regel andreas.re...@gmx.de
---
drivers/media/dvb-frontends/stv090x.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/stv090x.c
b/drivers/media/dvb-frontends/stv090x.c
index 56d470ad5a82..7484b01a9f13 100644
--- a/drivers/media/dvb-frontends/stv090x.c
+++ b/drivers/media/dvb-frontends/stv090x.c
@@ -722,9 +722,16 @@ static int stv090x_write_regs(struct stv090x_state *state,
unsigned int reg, u8
{
const struct stv090x_config *config = state-config;
int ret;
- u8 buf[2 + count];
+ u8 buf[80];
struct i2c_msg i2c_msg = { .addr = config-address, .flags = 0, .buf =
buf, .len = 2 + count };
+ if (2 + count sizeof(buf)) {
+ printk(KERN_WARNING
+ %s: i2c wr reg=%04x: len=%d is too big!\n,
+ KBUILD_MODNAME, reg, count);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg 8;
buf[1] = reg 0xff;
memcpy(buf[2], data, count);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 00/29] Fix errors/warnings with allmodconfig/allyesconfig on non-x86 archs
To be sure that we're not introducing compilation regressions on media, I'm now using ktest to check for errors/warnings. My current setup is cross-building on several architectures: alpha, arm, avr32, cris (64), frv, i386, ia64, m32r, m68k, mips, openrisc, parisc, s390, sh, sparc, sparc64, uml, x86_64 I tried to enable a few other archs: blackfin, cris (32), powerpc (32, 64), tile, xtensa but they fail to compile with allyesconfig due to non-media related issues. I'm still unsure about how often I'll be doing it, I intend to run it at least by the end of the subsystem merge window (by -rc6 or -rc7), and fix the issues found there. This version 2 series contain the fixes for all errors, including the dynamic static allocation. The only changes on the first 11 patches are at the comments, that got improved, and a few cosmetic changes to make checkpatch.pl happy. Mauro Carvalho Chehab (29): tda9887: remove an warning when compiling for alpha radio-shark: remove a warning when CONFIG_PM is not defined zoran: don't build it on alpha cx18: struct i2c_client is too big for stack tef6862: fix warning on avr32 arch iguanair: shut up a gcc warning on avr32 arch platform drivers: Fix build on cris and frv archs cx18: disable compilation on frv arch radio-si470x-i2c: fix a warning on ia64 rc: Fir warnings on m68k arch uvc/lirc_serial: Fix some warnings on parisc arch s5h1420: Don't use dynamic static allocation dvb-frontends: Don't use dynamic static allocation dvb-frontends: Don't use dynamic static allocation stb0899_drv: Don't use dynamic static allocation stv0367: Don't use dynamic static allocation stv090x: Don't use dynamic static allocation av7110_hw: Don't use dynamic static allocation tuners: Don't use dynamic static allocation tuner-xc2028: Don't use dynamic static allocation cimax2: Don't use dynamic static allocation v4l2-async: Don't use dynamic static allocation cxusb: Don't use dynamic static allocation dibusb-common: Don't use dynamic static allocation dw2102: Don't use dynamic static allocation af9015: Don't use dynamic static allocation af9035: Don't use dynamic static allocation mxl111sf: Don't use dynamic static allocation lirc_zilog: Don't use dynamic static allocation drivers/media/dvb-frontends/af9013.c | 9 ++- drivers/media/dvb-frontends/af9033.c | 18 +- drivers/media/dvb-frontends/bcm3510.c | 12 +++- drivers/media/dvb-frontends/cxd2820r_core.c | 18 +- drivers/media/dvb-frontends/itd1000.c | 10 ++- drivers/media/dvb-frontends/mt312.c | 8 ++- drivers/media/dvb-frontends/nxt200x.c | 8 ++- drivers/media/dvb-frontends/rtl2830.c | 9 ++- drivers/media/dvb-frontends/rtl2832.c | 9 ++- drivers/media/dvb-frontends/s5h1420.c | 9 ++- drivers/media/dvb-frontends/stb0899_drv.c | 9 ++- drivers/media/dvb-frontends/stb6100.c | 9 ++- drivers/media/dvb-frontends/stv0367.c | 10 ++- drivers/media/dvb-frontends/stv090x.c | 9 ++- drivers/media/dvb-frontends/stv6110.c | 9 ++- drivers/media/dvb-frontends/stv6110x.c| 9 ++- drivers/media/dvb-frontends/tda10071.c| 18 +- drivers/media/dvb-frontends/tda18271c2dd.c| 11 +++- drivers/media/dvb-frontends/zl10039.c | 9 ++- drivers/media/pci/cx18/Kconfig| 1 + drivers/media/pci/cx18/cx18-driver.c | 20 +++--- drivers/media/pci/cx23885/cimax2.c| 9 ++- drivers/media/pci/ttpci/av7110_hw.c | 11 +++- drivers/media/pci/zoran/Kconfig | 1 + drivers/media/platform/Kconfig| 2 + drivers/media/platform/soc_camera/Kconfig | 1 + drivers/media/radio/radio-shark.c | 2 + drivers/media/radio/radio-shark2.c| 2 + drivers/media/radio/si470x/radio-si470x-i2c.c | 4 +- drivers/media/radio/tef6862.c | 20 +++--- drivers/media/rc/fintek-cir.h | 4 +- drivers/media/rc/iguanair.c | 1 + drivers/media/rc/nuvoton-cir.h| 4 +- drivers/media/tuners/e4000.c | 18 +- drivers/media/tuners/fc2580.c | 18 +- drivers/media/tuners/tda18212.c | 18 +- drivers/media/tuners/tda18218.c | 18 +- drivers/media/tuners/tda9887.c| 4 +- drivers/media/tuners/tuner-xc2028.c | 5 +- drivers/media/usb/dvb-usb-v2/af9015.c | 3 +- drivers/media/usb/dvb-usb-v2/af9035.c | 26 +++- drivers/media/usb/dvb-usb-v2/mxl111sf.c | 7 ++- drivers/media/usb/dvb-usb/cxusb.c | 38 ++-- drivers/media/usb/dvb-usb/dibusb-common.c | 7 ++- drivers/media/usb/dvb-usb/dw2102.c| 87 --- drivers/media/usb/uvc/uvc_video.c | 3 +- drivers/media/v4l2-core/v4l2-async.c | 5 +-
[PATCHv2 24/29] dibusb-common: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/usb/dvb-usb/dibusb-common.c:124:1: warning:
'dibusb_i2c_msg' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (80 bytes).
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/usb/dvb-usb/dibusb-common.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb/dibusb-common.c
b/drivers/media/usb/dvb-usb/dibusb-common.c
index c2dded92f1d3..ae9eed810bc2 100644
--- a/drivers/media/usb/dvb-usb/dibusb-common.c
+++ b/drivers/media/usb/dvb-usb/dibusb-common.c
@@ -105,11 +105,16 @@ EXPORT_SYMBOL(dibusb2_0_power_ctrl);
static int dibusb_i2c_msg(struct dvb_usb_device *d, u8 addr,
u8 *wbuf, u16 wlen, u8 *rbuf, u16 rlen)
{
- u8 sndbuf[wlen+4]; /* lead(1) devaddr,direction(1) addr(2) data(wlen)
(len(2) (when reading)) */
+ u8 sndbuf[80]; /* lead(1) devaddr,direction(1) addr(2) data(wlen)
(len(2) (when reading)) */
/* write only ? */
int wo = (rbuf == NULL || rlen == 0),
len = 2 + wlen + (wo ? 0 : 2);
+ if (4 + wlen sizeof(sndbuf)) {
+ warn(i2c wr: len=%d is too big!\n, wlen);
+ return -EREMOTEIO;
+ }
+
sndbuf[0] = wo ? DIBUSB_REQ_I2C_WRITE : DIBUSB_REQ_I2C_READ;
sndbuf[1] = (addr 1) | (wo ? 0 : 1);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 22/29] v4l2-async: Don't use dynamic static allocation
Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/v4l2-core/v4l2-async.c:238:1: warning: 'v4l2_async_notifier_unregister' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. In this specific case, there's a hard limit imposed by V4L2_MAX_SUBDEVS, with is currently 128. That means that the buffer size can be up to 128x8 = 1024 bytes (on a 64bits kernel), with is too big for stack. Worse than that, someone could increase it and cause real troubles. So, let's use dynamically allocated data, instead. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de --- drivers/media/v4l2-core/v4l2-async.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c index c85d69da35bd..071596869036 100644 --- a/drivers/media/v4l2-core/v4l2-async.c +++ b/drivers/media/v4l2-core/v4l2-async.c @@ -189,12 +189,14 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier) struct v4l2_subdev *sd, *tmp; unsigned int notif_n_subdev = notifier-num_subdevs; unsigned int n_subdev = min(notif_n_subdev, V4L2_MAX_SUBDEVS); - struct device *dev[n_subdev]; + struct device **dev; int i = 0; if (!notifier-v4l2_dev) return; + dev = kmalloc(sizeof(*dev) * n_subdev, GFP_KERNEL); + mutex_lock(list_lock); list_del(notifier-list); @@ -228,6 +230,7 @@ void v4l2_async_notifier_unregister(struct v4l2_async_notifier *notifier) } put_device(d); } + kfree(dev); notifier-v4l2_dev = NULL; -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-media] Patch notification: 1 patch updated
Em Sat, 02 Nov 2013 14:00:13 +0100 Frank Schäfer fschaefer@googlemail.com escreveu: Am 31.10.2013 13:13, schrieb Patchwork: Hello, The following patch (submitted by you) has been updated in patchwork: * linux-media: em28xx: make sure that all subdevices are powered on when needed - http://patchwork.linuxtv.org/patch/20422/ - for: Linux Media kernel patches was: New now: Superseded This patch isn't superseeded. Guennadi didn't pick it up, so it's still up to you to review it. From what I understood, Guennadi's patch series made it obsolete. Right? If not, what's the usecase where this patch is needed? Regards, Mauro Regards, Frank This email is a notification only - you do not need to respond. - Patches submitted to linux-media@vger.kernel.org have the following possible states: New: Patches not yet reviewed (typically new patches); Under review: When it is expected that someone is reviewing it (typically, the driver's author or maintainer). Unfortunately, patchwork doesn't have a field to indicate who is the driver maintainer. If in doubt about who is the driver maintainer please check the MAINTAINERS file or ask at the ML; Superseded: when the same patch is sent twice, or a new version of the same patch is sent, and the maintainer identified it, the first version is marked as such. It is also used when a patch was superseeded by a git pull request. Obsoleted: patch doesn't apply anymore, because the modified code doesn't exist anymore. Changes requested: when someone requests changes at the patch; Rejected: When the patch is wrong or doesn't apply. Most of the time, 'rejected' and 'changes requested' means the same thing for the developer: he'll need to re-work on the patch. RFC: patches marked as such and other patches that are also RFC, but the patch author was not nice enough to mark them as such. That includes: - patches sent by a driver's maintainer who send patches via git pull requests; - patches with a very active community (typically from developers working with embedded devices), where lots of versions are needed for the driver maintainer and/or the community to be happy with. Not Applicable: for patches that aren't meant to be applicable via the media-tree.git. Accepted: when some driver maintainer says that the patch will be applied via his tree, or when everything is ok and it got applied either at the main tree or via some other tree (fixes tree; some other maintainer's tree - when it belongs to other subsystems, etc); If you think any status change is a mistake, please send an email to the ML. - This is an automated mail sent by the patchwork system at patchwork.linuxtv.org. To stop receiving these notifications, edit your mail settings at: http://patchwork.linuxtv.org/mail/ -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 26/29] af9015: Don't use dynamic static allocation
ACK. IIRC I did macro optimization here and that used way gives few
bytes smaller footprint =)
Antti
On 02.11.2013 15:31, Mauro Carvalho Chehab wrote:
Dynamic static allocation is evil, as Kernel stack is too low, and
ompilation complains about it on some archs:
drivers/media/usb/dvb-usb-v2/af9015.c:433:1: warning:
'af9015_eeprom_hash' uses dynamic stack allocation [enabled by default]
In this specific case, it is a gcc bug, as the size is a const, but
it is easy to just change it from const to a #define, getting rid of
the gcc warning.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Antti Palosaari cr...@iki.fi
Acked-by: Antti Palosaari cr...@iki.fi
Reviewed-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/af9015.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb-v2/af9015.c
b/drivers/media/usb/dvb-usb-v2/af9015.c
index d556042cf312..da47d2392f2a 100644
--- a/drivers/media/usb/dvb-usb-v2/af9015.c
+++ b/drivers/media/usb/dvb-usb-v2/af9015.c
@@ -397,12 +397,13 @@ error:
return ret;
}
+#define AF9015_EEPROM_SIZE 256
+
/* hash (and dump) eeprom */
static int af9015_eeprom_hash(struct dvb_usb_device *d)
{
struct af9015_state *state = d_to_priv(d);
int ret, i;
- static const unsigned int AF9015_EEPROM_SIZE = 256;
u8 buf[AF9015_EEPROM_SIZE];
struct req_t req = {READ_I2C, AF9015_I2C_EEPROM, 0, 0, 1, 1, NULL};
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 14/29] dvb-frontends: Don't use dynamic static allocation
Acked-by: Antti Palosaari cr...@iki.fi
Reviewed-by: Antti Palosaari cr...@iki.fi
Antti
On 02.11.2013 15:31, Mauro Carvalho Chehab wrote:
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/af9013.c:77:1: warning:
'af9013_wr_regs_i2c' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/af9033.c:188:1: warning:
'af9033_wr_reg_val_tab' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/af9033.c:68:1: warning: 'af9033_wr_regs'
uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/bcm3510.c:230:1: warning:
'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/cxd2820r_core.c:84:1: warning:
'cxd2820r_rd_regs_i2c.isra.1' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/rtl2830.c:56:1: warning: 'rtl2830_wr' uses
dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/rtl2832.c:187:1: warning: 'rtl2832_wr' uses
dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/tda10071.c:52:1: warning:
'tda10071_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/tda10071.c:84:1: warning:
'tda10071_rd_regs' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/af9013.c| 9 -
drivers/media/dvb-frontends/af9033.c| 18 --
drivers/media/dvb-frontends/cxd2820r_core.c | 18 --
drivers/media/dvb-frontends/rtl2830.c | 9 -
drivers/media/dvb-frontends/rtl2832.c | 9 -
drivers/media/dvb-frontends/tda10071.c | 18 --
6 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/drivers/media/dvb-frontends/af9013.c
b/drivers/media/dvb-frontends/af9013.c
index a204f2828820..f968dc0e5de9 100644
--- a/drivers/media/dvb-frontends/af9013.c
+++ b/drivers/media/dvb-frontends/af9013.c
@@ -50,7 +50,7 @@ static int af9013_wr_regs_i2c(struct af9013_state *priv, u8
mbox, u16 reg,
const u8 *val, int len)
{
int ret;
- u8 buf[3+len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv-config.i2c_addr,
@@ -60,6 +60,13 @@ static int af9013_wr_regs_i2c(struct af9013_state *priv, u8
mbox, u16 reg,
}
};
+ if (3 + len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+%s: i2c wr reg=%04x: len=%d is too big!\n,
+KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = (reg 8) 0xff;
buf[1] = (reg 0) 0xff;
buf[2] = mbox;
diff --git a/drivers/media/dvb-frontends/af9033.c
b/drivers/media/dvb-frontends/af9033.c
index a777b4b944eb..efa2efafa97f 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -40,7 +40,7 @@ static int af9033_wr_regs(struct af9033_state *state, u32
reg, const u8 *val,
int len)
{
int ret;
- u8 buf[3 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = state-cfg.i2c_addr,
@@ -50,6 +50,13 @@ static int af9033_wr_regs(struct af9033_state *state, u32
reg, const u8 *val,
}
};
+ if (3 + len sizeof(buf)) {
+ dev_warn(state-i2c-dev,
+%s: i2c wr reg=%04x: len=%d is too big!\n,
+KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = (reg 16) 0xff;
buf[1] = (reg 8) 0xff;
buf[2] = (reg 0) 0xff;
@@ -161,7 +168,14 @@ static int af9033_wr_reg_val_tab(struct af9033_state
*state,
const struct reg_val *tab, int tab_len)
{
int ret, i, j;
- u8 buf[tab_len];
+ u8 buf[80];
+
+ if (tab_len sizeof(buf)) {
+ dev_warn(state-i2c-dev,
+%s: i2c wr len=%d is too big!\n,
+KBUILD_MODNAME, tab_len);
+ return -EREMOTEIO;
+ }
dev_dbg(state-i2c-dev, %s: tab_len=%d\n, __func__, tab_len);
diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c
Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
Acked-by: Antti Palosaari cr...@iki.fi
Reviewed-by: Antti Palosaari cr...@iki.fi
Antti
On 02.11.2013 15:31, Mauro Carvalho Chehab wrote:
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:66:1: warning:
'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:98:1: warning:
'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:90:1: warning:
'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18218.c:92:1: warning:
'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/e4000.c| 18 --
drivers/media/tuners/fc2580.c | 18 --
drivers/media/tuners/tda18212.c | 18 --
drivers/media/tuners/tda18218.c | 18 --
4 files changed, 64 insertions(+), 8 deletions(-)
diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
index ad9309da4a91..235e90251609 100644
--- a/drivers/media/tuners/e4000.c
+++ b/drivers/media/tuners/e4000.c
@@ -24,7 +24,7 @@
static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[1 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv-cfg-i2c_addr,
@@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8
*val, int len)
}
};
+ if (1 + len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+%s: i2c wr reg=%04x: len=%d is too big!\n,
+KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg;
memcpy(buf[1], val, len);
@@ -53,7 +60,7 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8
*val, int len)
static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[len];
+ u8 buf[80];
struct i2c_msg msg[2] = {
{
.addr = priv-cfg-i2c_addr,
@@ -68,6 +75,13 @@ static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8
*val, int len)
}
};
+ if (len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+%s: i2c rd reg=%04x: len=%d is too big!\n,
+KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
ret = i2c_transfer(priv-i2c, msg, 2);
if (ret == 2) {
memcpy(val, buf, len);
diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
index 81f38aae9c66..e27bf5be311d 100644
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -41,7 +41,7 @@
static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[1 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv-cfg-i2c_addr,
@@ -51,6 +51,13 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg,
u8 *val, int len)
}
};
+ if (1 + len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+%s: i2c wr reg=%04x: len=%d is too big!\n,
+KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
buf[0] = reg;
memcpy(buf[1], val, len);
@@ -69,7 +76,7 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg,
u8 *val, int len)
static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[len];
+ u8 buf[80];
struct i2c_msg msg[2] = {
{
Re: [PATCHv2 27/29] af9035: Don't use dynamic static allocation
Acked-by: Antti Palosaari cr...@iki.fi
Reviewed-by: Antti Palosaari cr...@iki.fi
Antti
On 02.11.2013 15:31, Mauro Carvalho Chehab wrote:
Dynamic static allocation is evil, as Kernel stack is too low, and
ompilation complains about it on some archs:
drivers/media/usb/dvb-usb-v2/af9035.c:142:1: warning: 'af9035_wr_regs'
uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb-v2/af9035.c:305:1: warning:
'af9035_i2c_master_xfer' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (80 bytes).
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
---
drivers/media/usb/dvb-usb-v2/af9035.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
b/drivers/media/usb/dvb-usb-v2/af9035.c
index 1ea17dc2a76e..f43e9f336204 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -126,10 +126,16 @@ exit:
/* write multiple registers */
static int af9035_wr_regs(struct dvb_usb_device *d, u32 reg, u8 *val, int len)
{
- u8 wbuf[6 + len];
+ u8 wbuf[80];
u8 mbox = (reg 16) 0xff;
struct usb_req req = { CMD_MEM_WR, mbox, sizeof(wbuf), wbuf, 0, NULL };
+ if (6 + len sizeof(wbuf)) {
+ dev_warn(d-udev-dev, %s: i2c wr: len=%d is too big!\n,
+KBUILD_MODNAME, len);
+ return -EREMOTEIO;
+ }
+
wbuf[0] = len;
wbuf[1] = 2;
wbuf[2] = 0;
@@ -228,9 +234,16 @@ static int af9035_i2c_master_xfer(struct i2c_adapter *adap,
msg[1].len);
} else {
/* I2C */
- u8 buf[5 + msg[0].len];
+ u8 buf[80];
struct usb_req req = { CMD_I2C_RD, 0, sizeof(buf),
buf, msg[1].len, msg[1].buf };
+
+ if (5 + msg[0].len sizeof(buf)) {
+ dev_warn(d-udev-dev,
+%s: i2c xfer: len=%d is too big!\n,
+KBUILD_MODNAME, msg[0].len);
+ return -EREMOTEIO;
+ }
req.mbox |= ((msg[0].addr 0x80)3);
buf[0] = msg[1].len;
buf[1] = msg[0].addr 1;
@@ -257,9 +270,16 @@ static int af9035_i2c_master_xfer(struct i2c_adapter *adap,
msg[0].len - 3);
} else {
/* I2C */
- u8 buf[5 + msg[0].len];
+ u8 buf[80];
struct usb_req req = { CMD_I2C_WR, 0, sizeof(buf), buf,
0, NULL };
+
+ if (5 + msg[0].len sizeof(buf)) {
+ dev_warn(d-udev-dev,
+%s: i2c xfer: len=%d is too big!\n,
+KBUILD_MODNAME, msg[0].len);
+ return -EREMOTEIO;
+ }
req.mbox |= ((msg[0].addr 0x80)3);
buf[0] = msg[0].len;
buf[1] = msg[0].addr 1;
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
Hi Mauro,
I'll review this series more carefully on Monday, but for now I want to make
a suggestion for the array checks:
On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:66:1: warning:
'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/fc2580.c:98:1: warning:
'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:90:1: warning:
'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18218.c:92:1: warning:
'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/e4000.c| 18 --
drivers/media/tuners/fc2580.c | 18 --
drivers/media/tuners/tda18212.c | 18 --
drivers/media/tuners/tda18218.c | 18 --
4 files changed, 64 insertions(+), 8 deletions(-)
diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
index ad9309da4a91..235e90251609 100644
--- a/drivers/media/tuners/e4000.c
+++ b/drivers/media/tuners/e4000.c
@@ -24,7 +24,7 @@
static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[1 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv-cfg-i2c_addr,
@@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg,
u8 *val, int len)
}
};
+ if (1 + len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+ %s: i2c wr reg=%04x: len=%d is too big!\n,
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
I think this can be greatly simplified to:
if (WARN_ON(len + 1 sizeof(buf))
return -EREMOTEIO;
This should really never happen, and it is a clear driver bug if it does.
WARN_ON
does the job IMHO. I also don't like the EREMOTEIO error: it has nothing to do
with
an I/O problem. Wouldn't EMSGSIZE be much better here?
Ditto for all the similar situations in the patch series.
Regards,
Hans
buf[0] = reg;
memcpy(buf[1], val, len);
@@ -53,7 +60,7 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg,
u8 *val, int len)
static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[len];
+ u8 buf[80];
struct i2c_msg msg[2] = {
{
.addr = priv-cfg-i2c_addr,
@@ -68,6 +75,13 @@ static int e4000_rd_regs(struct e4000_priv *priv, u8 reg,
u8 *val, int len)
}
};
+ if (len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+ %s: i2c rd reg=%04x: len=%d is too big!\n,
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
ret = i2c_transfer(priv-i2c, msg, 2);
if (ret == 2) {
memcpy(val, buf, len);
diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
index 81f38aae9c66..e27bf5be311d 100644
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -41,7 +41,7 @@
static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[1 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv-cfg-i2c_addr,
@@ -51,6 +51,13 @@ static int fc2580_wr_regs(struct fc2580_priv *priv, u8
reg, u8 *val, int len)
}
};
+ if (1 + len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+ %s: i2c wr reg=%04x:
status of Technisat CableStar Combi CI HD kernel support
I've just subscribed to the list following the advice given at http://www.linuxtv.org/wiki/index.php/DVB-C_USB_Devices: If you own one or more devices from the following list and you want to help with support development, please contact the Linux-Media Mailing List Adding the support for the device requires just a simple patch http://www.linuxtv.org/wiki/index.php/TechniSat_CableStar_Combo_HD_CI so I have a simple question: when the support will be available in the official kernel? Is it already on some kind of waiting list or some additional action is required? Best regards Janusz -- Prof. dr hab. Janusz S. Bień - Uniwersytet Warszawski (Katedra Lingwistyki Formalnej) Prof. Janusz S. Bień - University of Warsaw (Formal Linguistics Department) jsb...@uw.edu.pl, jsb...@mimuw.edu.pl, http://fleksem.klf.uw.edu.pl/~jsbien/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kconfig] update: results of some syntactical checks
On Sun, 2013-10-20 at 00:03 +0200, Martin Walch wrote: drivers/media/common/siano/Kconfig:21-26 config SMS_SIANO_DEBUGFS bool Enable debugfs for smsdvb depends on SMS_SIANO_MDTV depends on DEBUG_FS depends on SMS_USB_DRV depends on CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV The last line adds the dependency CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV. This expression does not look sound as those two symbols are not declared anywhere. So, the two strings CONFIG_SMS_USB_DRV and CONFIG_SMS_SDIO_DRV are compared, yielding always 'n'. As a result, SMS_SIANO_DEBUGFS will never be enabled. Those are obvious typos. Still present in v3.12-rc7. Perhaps you'd like to send the trivial patch to fix this? Probably, it was meant to say something like depends on SMS_USB_DRV = SMS_SDIO_DRV Two other config sections that probably behave differently than expected: drivers/staging/rtl8188eu/Kconfig: 13-15 config 88EU_AP_MODE bool Realtek RTL8188EU AP mode default Y drivers/staging/rtl8188eu/Kconfig: 21-23 config 88EU_P2P bool Realtek RTL8188EU Peer-to-peer mode default Y The capital Y is different from the lowercase y. While y is an actually hard coded constant symbol, Y is undeclared and evaluates to n. The default values are probably only for convenience, so 88EU_AP_MODE and 88EU_P2P are activated together with 8188EU. They still can be turned off. Anyway, it should probably say default y in both cases. Ditto. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kconfig] update: results of some syntactical checks
Em Sat, 02 Nov 2013 20:20:54 +0100 Paul Bolle pebo...@tiscali.nl escreveu: On Sun, 2013-10-20 at 00:03 +0200, Martin Walch wrote: drivers/media/common/siano/Kconfig:21-26 config SMS_SIANO_DEBUGFS bool Enable debugfs for smsdvb depends on SMS_SIANO_MDTV depends on DEBUG_FS depends on SMS_USB_DRV depends on CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV The last line adds the dependency CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV. This expression does not look sound as those two symbols are not declared anywhere. So, the two strings CONFIG_SMS_USB_DRV and CONFIG_SMS_SDIO_DRV are compared, yielding always 'n'. As a result, SMS_SIANO_DEBUGFS will never be enabled. Those are obvious typos. Still present in v3.12-rc7. Perhaps you'd like to send the trivial patch to fix this? Yes, it is a typo... Probably, it was meant to say something like depends on SMS_USB_DRV = SMS_SDIO_DRV But this is not the right thing to do. The Kconfig logic here is that it should depends on !SMS_SDIO_DRV or SMS_USB_DRV = SMS_SDIO_DRV. I remember I made a patch like that while testing some things with this driver, but it seems that I forgot to push. I might have it somewhere on my test machine. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] az6007: support Technisat Cablestar Combo HDCI (minus remote)
This is similar to the Terratec H7. It works with the same az6007 firmware as
the former, however the drx-k firmware of the H7 will NOT work. Hence use
a different firmware name. The firmware does not need to exist as the one in
the eeprom is just fine as long as the h7 one doesn't get loaded, but maybe
some day someone wants to load it (the one from the h5 would work too).
Also since the config entry is now different anyway disable support for rc.
AFAIK the Technisat remote (TS35) is RC5 and the code (which a code comment
claims doesn't work anyway) only would handle NEC hence it's pointless creating
a device and polling it if we already know it can't work.
CI is untested.
Originally based on idea found on
http://www.linuxtv.org/wiki/index.php/TechniSat_CableStar_Combo_HD_CI claiming
only id needs to be added (but failed to mention it only worked because the
driver couldn't find the h7 drx-k firmware...).
Signed-off-by: Roland Scheidegger rscheidegger_li...@hispeed.ch
---
drivers/media/dvb-core/dvb-usb-ids.h | 1 +
drivers/media/usb/dvb-usb-v2/az6007.c | 59 +++
2 files changed, 60 insertions(+)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index 419a2d6..4a53454 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -365,6 +365,7 @@
#define USB_PID_TERRATEC_DVBS2CI_V20x10ac
#define USB_PID_TECHNISAT_USB2_HDCI_V1 0x0001
#define USB_PID_TECHNISAT_USB2_HDCI_V2 0x0002
+#define USB_PID_TECHNISAT_USB2_CABLESTAR_HDCI 0x0003
#define USB_PID_TECHNISAT_AIRSTAR_TELESTICK_2 0x0004
#define USB_PID_TECHNISAT_USB2_DVB_S2 0x0500
#define USB_PID_CPYTO_REDI_PC50A 0xa803
diff --git a/drivers/media/usb/dvb-usb-v2/az6007.c
b/drivers/media/usb/dvb-usb-v2/az6007.c
index 44c64ef3..c1051c3 100644
--- a/drivers/media/usb/dvb-usb-v2/az6007.c
+++ b/drivers/media/usb/dvb-usb-v2/az6007.c
@@ -68,6 +68,19 @@ static struct drxk_config terratec_h7_drxk = {
.microcode_name = dvb-usb-terratec-h7-drxk.fw,
};
+static struct drxk_config cablestar_hdci_drxk = {
+ .adr = 0x29,
+ .parallel_ts = true,
+ .dynamic_clk = true,
+ .single_master = true,
+ .enable_merr_cfg = true,
+ .no_i2c_bridge = false,
+ .chunk_size = 64,
+ .mpeg_out_clk_strength = 0x02,
+ .qam_demod_parameter_count = 2,
+ .microcode_name = dvb-usb-technisat-cablestar-hdci-drxk.fw,
+};
+
static int drxk_gate_ctrl(struct dvb_frontend *fe, int enable)
{
struct az6007_device_state *st = fe_to_priv(fe);
@@ -630,6 +643,27 @@ static int az6007_frontend_attach(struct dvb_usb_adapter
*adap)
return 0;
}
+static int az6007_cablestar_hdci_frontend_attach(struct dvb_usb_adapter *adap)
+{
+ struct az6007_device_state *st = adap_to_priv(adap);
+ struct dvb_usb_device *d = adap_to_d(adap);
+
+ pr_debug(attaching demod drxk\n);
+
+ adap-fe[0] = dvb_attach(drxk_attach, cablestar_hdci_drxk,
+d-i2c_adap);
+ if (!adap-fe[0])
+ return -EINVAL;
+
+ adap-fe[0]-sec_priv = adap;
+ st-gate_ctrl = adap-fe[0]-ops.i2c_gate_ctrl;
+ adap-fe[0]-ops.i2c_gate_ctrl = drxk_gate_ctrl;
+
+ az6007_ci_init(adap);
+
+ return 0;
+}
+
static int az6007_tuner_attach(struct dvb_usb_adapter *adap)
{
struct dvb_usb_device *d = adap_to_d(adap);
@@ -868,6 +902,29 @@ static struct dvb_usb_device_properties az6007_props = {
}
};
+static struct dvb_usb_device_properties az6007_cablestar_hdci_props = {
+ .driver_name = KBUILD_MODNAME,
+ .owner = THIS_MODULE,
+ .firmware= AZ6007_FIRMWARE,
+
+ .adapter_nr = adapter_nr,
+ .size_of_priv= sizeof(struct az6007_device_state),
+ .i2c_algo= az6007_i2c_algo,
+ .tuner_attach= az6007_tuner_attach,
+ .frontend_attach = az6007_cablestar_hdci_frontend_attach,
+ .streaming_ctrl = az6007_streaming_ctrl,
+/* ditch get_rc_config as it can't work (TS35 remote, I believe it's rc5) */
+ .get_rc_config = NULL,
+ .read_mac_address= az6007_read_mac_addr,
+ .download_firmware = az6007_download_firmware,
+ .identify_state = az6007_identify_state,
+ .power_ctrl = az6007_power_ctrl,
+ .num_adapters= 1,
+ .adapter = {
+ { .stream = DVB_USB_STREAM_BULK(0x02, 10, 4096), }
+ }
+};
+
static struct usb_device_id az6007_usb_table[] = {
{DVB_USB_DEVICE(USB_VID_AZUREWAVE, USB_PID_AZUREWAVE_6007,
az6007_props, Azurewave 6007, RC_MAP_EMPTY)},
@@ -875,6 +932,8 @@ static struct usb_device_id az6007_usb_table[] = {
az6007_props, Terratec H7, RC_MAP_NEC_TERRATEC_CINERGY_XS)},
Re: [kconfig] update: results of some syntactical checks
On Sat, 2013-11-02 at 17:40 -0200, Mauro Carvalho Chehab wrote: Em Sat, 02 Nov 2013 20:20:54 +0100 Paul Bolle pebo...@tiscali.nl escreveu: Those are obvious typos. Still present in v3.12-rc7. Perhaps you'd like to send the trivial patch to fix this? Yes, it is a typo... Probably, it was meant to say something like depends on SMS_USB_DRV = SMS_SDIO_DRV But this is not the right thing to do. The Kconfig logic here is that it should depends on !SMS_SDIO_DRV or SMS_USB_DRV = SMS_SDIO_DRV. For the record: my reason for suggesting to Martin to send patches is that sending a (trivial) patch often turns out to be a quick way to get issues like that resolved. Maintainers seem to react quite quickly on patches. Perhaps even faster if a patch is not solving the issue at hand entirely correct! Messages like Martin's, that basically state that there are one or more tree-wide problems, seem to be overlooked easily. I remember I made a patch like that while testing some things with this driver, but it seems that I forgot to push. I might have it somewhere on my test machine. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tda18271-fe: Fix dvb-c standard selection
Fix dvb-c standard selection - qam8 for ANNEX_AC
Signed-off-by: Evgeny Plehov evgenyple...@ukr.net
diff --git a/drivers/media/tuners/tda18271-fe.c
b/drivers/media/tuners/tda18271-fe.c
index 4995b89..6a385c8 100644
--- a/drivers/media/tuners/tda18271-fe.c
+++ b/drivers/media/tuners/tda18271-fe.c
@@ -960,16 +960,12 @@ static int tda18271_set_params(struct dvb_frontend *fe)
break;
case SYS_DVBC_ANNEX_B:
bw = 600;
- /* falltrough */
+ map = std_map-qam_6;
+ break;
case SYS_DVBC_ANNEX_A:
case SYS_DVBC_ANNEX_C:
- if (bw = 600) {
- map = std_map-qam_6;
- } else if (bw = 700) {
- map = std_map-qam_7;
- } else {
- map = std_map-qam_8;
- }
+ bw = 800;
+ map = std_map-qam_8;
break;
default:
tda_warn(modulation type not supported!\n);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cxd2820r_c: Fix if_ctl calculation
Fix tune for DVB-C. Signed-off-by: Evgeny Plehov evgenyple...@ukr.net diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c b/drivers/media/dvb-frontends/cxd2820r_c.c index 125a440..5c6ab49 100644 --- a/drivers/media/dvb-frontends/cxd2820r_c.c +++ b/drivers/media/dvb-frontends/cxd2820r_c.c @@ -78,7 +78,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe) num = if_freq / 1000; /* Hz = kHz */ num *= 0x4000; - if_ctl = cxd2820r_div_u64_round_closest(num, 41000); + if_ctl = 0x4000 - cxd2820r_div_u64_round_closest(num, 41000); buf[0] = (if_ctl 8) 0x3f; buf[1] = (if_ctl 0) 0xff; -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dw2102: Geniatech T220 support
Support for Geniatech T220 DVB-T/T2/C USB stick.
Signed-off-by: Evgeny Plehov evgenyple...@ukr.net
diff --git a/drivers/media/usb/dvb-usb/dw2102.c
b/drivers/media/usb/dvb-usb/dw2102.c
index 6136a2c..12e00aa 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -2,7 +2,7 @@
* DVBWorld DVB-S 2101, 2102, DVB-S2 2104, DVB-C 3101,
* TeVii S600, S630, S650, S660, S480, S421, S632
* Prof 1100, 7500,
- * Geniatech SU3000 Cards
+ * Geniatech SU3000, T220 Cards
* Copyright (C) 2008-2012 Igor M. Liplianin (liplia...@me.by)
*
* This program is free software; you can redistribute it and/or modify it
@@ -29,6 +29,8 @@
#include stb6100.h
#include stb6100_proc.h
#include m88rs2000.h
+#include tda18271.h
+#include cxd2820r.h
#ifndef USB_PID_DW2102
#define USB_PID_DW2102 0x2102
@@ -1025,6 +1027,16 @@ static struct ds3000_config su3000_ds3000_config = {
.set_lock_led = dw210x_led_ctrl,
};
+static struct cxd2820r_config cxd2820r_config = {
+ .i2c_address = 0x6c, /* (0xd8 1) */
+ .ts_mode = 0x38,
+};
+
+static struct tda18271_config tda18271_config = {
+ .output_opt = TDA18271_OUTPUT_LT_OFF,
+ .gate = TDA18271_GATE_DIGITAL,
+};
+
static u8 m88rs2000_inittab[] = {
DEMOD_WRITE, 0x9a, 0x30,
DEMOD_WRITE, 0x00, 0x01,
@@ -1294,6 +1306,49 @@ static int su3000_frontend_attach(struct dvb_usb_adapter
*d)
return -EIO;
}
+static int t220_frontend_attach(struct dvb_usb_adapter *d)
+{
+ u8 obuf[3] = { 0xe, 0x80, 0 };
+ u8 ibuf[] = { 0 };
+
+ if (dvb_usb_generic_rw(d-dev, obuf, 3, ibuf, 1, 0) 0)
+ err(command 0x0e transfer failed.);
+
+ obuf[0] = 0xe;
+ obuf[1] = 0x83;
+ obuf[2] = 0;
+
+ if (dvb_usb_generic_rw(d-dev, obuf, 3, ibuf, 1, 0) 0)
+ err(command 0x0e transfer failed.);
+
+ msleep(100);
+
+ obuf[0] = 0xe;
+ obuf[1] = 0x80;
+ obuf[2] = 1;
+
+ if (dvb_usb_generic_rw(d-dev, obuf, 3, ibuf, 1, 0) 0)
+ err(command 0x0e transfer failed.);
+
+ obuf[0] = 0x51;
+
+ if (dvb_usb_generic_rw(d-dev, obuf, 1, ibuf, 1, 0) 0)
+ err(command 0x51 transfer failed.);
+
+ d-fe_adap[0].fe = dvb_attach(cxd2820r_attach, cxd2820r_config,
+ d-dev-i2c_adap, NULL);
+ if (d-fe_adap[0].fe != NULL) {
+ if (dvb_attach(tda18271_attach, d-fe_adap[0].fe, 0x60,
+ d-dev-i2c_adap, tda18271_config)) {
+ info(Attached TDA18271HD/CXD2820R!\n);
+ return 0;
+ }
+ }
+
+ info(Failed to attach TDA18271HD/CXD2820R!\n);
+ return -EIO;
+}
+
static int m88rs2000_frontend_attach(struct dvb_usb_adapter *d)
{
u8 obuf[] = { 0x51 };
@@ -1560,6 +1615,7 @@ enum dw2102_table_entry {
TEVII_S632,
TERRATEC_CINERGY_S2_R2,
GOTVIEW_SAT_HD,
+ GENIATECH_T220,
};
static struct usb_device_id dw2102_table[] = {
@@ -1582,6 +1638,7 @@ static struct usb_device_id dw2102_table[] = {
[TEVII_S632] = {USB_DEVICE(0x9022, USB_PID_TEVII_S632)},
[TERRATEC_CINERGY_S2_R2] = {USB_DEVICE(USB_VID_TERRATEC, 0x00b0)},
[GOTVIEW_SAT_HD] = {USB_DEVICE(0x1FE1, USB_PID_GOTVIEW_SAT_HD)},
+ [GENIATECH_T220] = {USB_DEVICE(0x1f4d, 0xD220)},
{ }
};
@@ -2007,6 +2064,54 @@ static struct dvb_usb_device_properties
su3000_properties = {
}
};
+static struct dvb_usb_device_properties t220_properties = {
+ .caps = DVB_USB_IS_AN_I2C_ADAPTER,
+ .usb_ctrl = DEVICE_SPECIFIC,
+ .size_of_priv = sizeof(struct su3000_state),
+ .power_ctrl = su3000_power_ctrl,
+ .num_adapters = 1,
+ .identify_state = su3000_identify_state,
+ .i2c_algo = su3000_i2c_algo,
+
+ .rc.legacy = {
+ .rc_map_table = rc_map_su3000_table,
+ .rc_map_size = ARRAY_SIZE(rc_map_su3000_table),
+ .rc_interval = 150,
+ .rc_query = dw2102_rc_query,
+ },
+
+ .read_mac_address = su3000_read_mac_address,
+
+ .generic_bulk_ctrl_endpoint = 0x01,
+
+ .adapter = {
+ {
+ .num_frontends = 1,
+ .fe = { {
+ .streaming_ctrl = su3000_streaming_ctrl,
+ .frontend_attach = t220_frontend_attach,
+ .stream = {
+ .type = USB_BULK,
+ .count = 8,
+ .endpoint = 0x82,
+ .u = {
+ .bulk = {
+ .buffersize = 4096,
+ }
+ }
+ }
+ } },
+ }
+ },
+ .num_device_descs = 1,
+ .devices = {
+
Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
Em Sat, 02 Nov 2013 18:25:19 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
Hi Mauro,
I'll review this series more carefully on Monday,
Thanks!
but for now I want to make
a suggestion for the array checks:
On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:66:1: warning:
'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/fc2580.c:98:1: warning:
'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:90:1: warning:
'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18218.c:92:1: warning:
'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/e4000.c| 18 --
drivers/media/tuners/fc2580.c | 18 --
drivers/media/tuners/tda18212.c | 18 --
drivers/media/tuners/tda18218.c | 18 --
4 files changed, 64 insertions(+), 8 deletions(-)
diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
index ad9309da4a91..235e90251609 100644
--- a/drivers/media/tuners/e4000.c
+++ b/drivers/media/tuners/e4000.c
@@ -24,7 +24,7 @@
static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[1 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv-cfg-i2c_addr,
@@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8
reg, u8 *val, int len)
}
};
+ if (1 + len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+%s: i2c wr reg=%04x: len=%d is too big!\n,
+KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
I think this can be greatly simplified to:
if (WARN_ON(len + 1 sizeof(buf))
return -EREMOTEIO;
This should really never happen, and it is a clear driver bug if it does.
WARN_ON
does the job IMHO.
Works for me. I'll wait for more comments, and go for it on v3.
I also don't like the EREMOTEIO error: it has nothing to do with
an I/O problem. Wouldn't EMSGSIZE be much better here?
EMSGSIZE is not used yet at drivers/media. So, it is probably not the
right error code.
I remember that there's an error code for that on I2C (EOPNOTSUPP?).
In any case, I don't think we should use an unusual error code here.
In theory, this error should never happen, but we don't want to break
userspace because of it. That's why I opted to use EREMOTEIO: this is
the error code that most of those drivers return when something gets
wrong during I2C transfers.
Ditto for all the similar situations in the patch series.
Regards,
Hans
buf[0] = reg;
memcpy(buf[1], val, len);
@@ -53,7 +60,7 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8 reg,
u8 *val, int len)
static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[len];
+ u8 buf[80];
struct i2c_msg msg[2] = {
{
.addr = priv-cfg-i2c_addr,
@@ -68,6 +75,13 @@ static int e4000_rd_regs(struct e4000_priv *priv, u8
reg, u8 *val, int len)
}
};
+ if (len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+%s: i2c rd reg=%04x: len=%d is too big!\n,
+KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
ret = i2c_transfer(priv-i2c, msg, 2);
if (ret == 2) {
memcpy(val, buf, len);
diff --git a/drivers/media/tuners/fc2580.c
Re: [PATCH] tda18271-fe: Fix dvb-c standard selection
Em Sat, 02 Nov 2013 23:05:14 +0200
CrazyCat crazyca...@narod.ru escreveu:
Fix dvb-c standard selection - qam8 for ANNEX_AC
Signed-off-by: Evgeny Plehov evgenyple...@ukr.net
diff --git a/drivers/media/tuners/tda18271-fe.c
b/drivers/media/tuners/tda18271-fe.c
index 4995b89..6a385c8 100644
--- a/drivers/media/tuners/tda18271-fe.c
+++ b/drivers/media/tuners/tda18271-fe.c
@@ -960,16 +960,12 @@ static int tda18271_set_params(struct dvb_frontend *fe)
break;
case SYS_DVBC_ANNEX_B:
bw = 600;
- /* falltrough */
+ map = std_map-qam_6;
+ break;
case SYS_DVBC_ANNEX_A:
case SYS_DVBC_ANNEX_C:
- if (bw = 600) {
- map = std_map-qam_6;
- } else if (bw = 700) {
- map = std_map-qam_7;
- } else {
- map = std_map-qam_8;
- }
+ bw = 800;
+ map = std_map-qam_8;
This is wrong, as it breaks for 6MHz-spaced channels, like what's used
in Brazil and Japan.
What happens here is that, if the tuner uses a too wide lowpass filter,
the interference will be higher at the demod, and it may not be able
to decode.
As the bandwidth is already estimated by the DVB frontend core, the
tuners should be adjusted to get the closest filter for a given
bandwidth.
So, the driver is correct (and it is tested under 6MHz spaced channels).
break;
default:
tda_warn(modulation type not supported!\n);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] as3645a: Remove set_power() from platform data
On Wed, May 23, 2012 at 03:06:41PM +0300, Sakari Ailus wrote: On Wed, May 23, 2012 at 01:31:26PM +0200, Laurent Pinchart wrote: Hi Sakari, ... If the chip is powered on constantly, why do we need a .s_power() subdev operation at all ? I don't know why was it there in the first place. Probably to make it easier to use the driver on boards that required e.g. a regulator for the chip. But typically they're connected to battery directly. The idle power consumption is just some tens of µA. What about on the N9 ? That function pointer is NULL for N9. I used to configure the GPIOs but that was wrong in the first place. Ping. Should we either remove the s_power() callback altogether or just the platform data callback function (which is unused)? It is indeed possible that the device was powered from a regulator which isn't always on but we don't have such use cases right now. -- Cheers, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
On 11/02/2013 10:15 PM, Mauro Carvalho Chehab wrote:
Em Sat, 02 Nov 2013 18:25:19 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
Hi Mauro,
I'll review this series more carefully on Monday,
Thanks!
but for now I want to make
a suggestion for the array checks:
On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:66:1: warning:
'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/fc2580.c:98:1: warning:
'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:90:1: warning:
'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18218.c:92:1: warning:
'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/e4000.c| 18 --
drivers/media/tuners/fc2580.c | 18 --
drivers/media/tuners/tda18212.c | 18 --
drivers/media/tuners/tda18218.c | 18 --
4 files changed, 64 insertions(+), 8 deletions(-)
diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
index ad9309da4a91..235e90251609 100644
--- a/drivers/media/tuners/e4000.c
+++ b/drivers/media/tuners/e4000.c
@@ -24,7 +24,7 @@
static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
{
int ret;
- u8 buf[1 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv-cfg-i2c_addr,
@@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8
reg, u8 *val, int len)
}
};
+ if (1 + len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+%s: i2c wr reg=%04x: len=%d is too big!\n,
+KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
I think this can be greatly simplified to:
if (WARN_ON(len + 1 sizeof(buf))
return -EREMOTEIO;
This should really never happen, and it is a clear driver bug if it does.
WARN_ON
does the job IMHO.
Works for me. I'll wait for more comments, and go for it on v3.
I also don't like the EREMOTEIO error: it has nothing to do with
an I/O problem. Wouldn't EMSGSIZE be much better here?
EMSGSIZE is not used yet at drivers/media. So, it is probably not the
right error code.
I remember that there's an error code for that on I2C (EOPNOTSUPP?).
In any case, I don't think we should use an unusual error code here.
In theory, this error should never happen, but we don't want to break
userspace because of it. That's why I opted to use EREMOTEIO: this is
the error code that most of those drivers return when something gets
wrong during I2C transfers.
The problem I have is that EREMOTEIO is used when the i2c transfer fails,
i.e. there is some sort of a hardware or communication problem.
That's not the case here, it's an argument error. So EINVAL would actually
be better, but that's perhaps overused which is why I suggested EMSGSIZE.
I personally don't think EIO or EREMOTEIO should be used for something that
is not hardware related. I'm sure there are some gray areas, but this
particular situation is clearly not hardware-related.
So if EMSGSIZE won't work for you, then I prefer EINVAL over EREMOTEIO.
ENOMEM is also an option (you are after all 'out of buffer memory').
A bit more exotic, but still sort of in the area, is EPROTO.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
On 11/02/2013 10:53 PM, Hans Verkuil wrote:
On 11/02/2013 10:15 PM, Mauro Carvalho Chehab wrote:
Em Sat, 02 Nov 2013 18:25:19 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
Hi Mauro,
I'll review this series more carefully on Monday,
Thanks!
but for now I want to make
a suggestion for the array checks:
On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:66:1: warning:
'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/fc2580.c:98:1: warning:
'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:90:1: warning:
'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18218.c:92:1: warning:
'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/e4000.c| 18 --
drivers/media/tuners/fc2580.c | 18 --
drivers/media/tuners/tda18212.c | 18 --
drivers/media/tuners/tda18218.c | 18 --
4 files changed, 64 insertions(+), 8 deletions(-)
diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
index ad9309da4a91..235e90251609 100644
--- a/drivers/media/tuners/e4000.c
+++ b/drivers/media/tuners/e4000.c
@@ -24,7 +24,7 @@
static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int
len)
{
int ret;
- u8 buf[1 + len];
+ u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv-cfg-i2c_addr,
@@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8
reg, u8 *val, int len)
}
};
+ if (1 + len sizeof(buf)) {
+ dev_warn(priv-i2c-dev,
+ %s: i2c wr reg=%04x: len=%d is too big!\n,
+ KBUILD_MODNAME, reg, len);
+ return -EREMOTEIO;
+ }
+
I think this can be greatly simplified to:
if (WARN_ON(len + 1 sizeof(buf))
return -EREMOTEIO;
This should really never happen, and it is a clear driver bug if it does.
WARN_ON
does the job IMHO.
Works for me. I'll wait for more comments, and go for it on v3.
I also don't like the EREMOTEIO error: it has nothing to do with
an I/O problem. Wouldn't EMSGSIZE be much better here?
EMSGSIZE is not used yet at drivers/media. So, it is probably not the
right error code.
I remember that there's an error code for that on I2C (EOPNOTSUPP?).
In any case, I don't think we should use an unusual error code here.
In theory, this error should never happen, but we don't want to break
userspace because of it. That's why I opted to use EREMOTEIO: this is
the error code that most of those drivers return when something gets
wrong during I2C transfers.
The problem I have is that EREMOTEIO is used when the i2c transfer fails,
i.e. there is some sort of a hardware or communication problem.
That's not the case here, it's an argument error. So EINVAL would actually
be better, but that's perhaps overused which is why I suggested EMSGSIZE.
I personally don't think EIO or EREMOTEIO should be used for something that
is not hardware related. I'm sure there are some gray areas, but this
particular situation is clearly not hardware-related.
So if EMSGSIZE won't work for you, then I prefer EINVAL over EREMOTEIO.
ENOMEM is also an option (you are after all 'out of buffer memory').
A bit more exotic, but still sort of in the area, is EPROTO.
After thinking about it a little bit more I would just return -EINVAL. It's
a wrong argument, it's something that shouldn't happen at all, and you get a
big fat stack trace anyway due to the WARN_ON, so EINVAL makes perfect sense.
Regards,
Hans
--
To
Re: RTL2832U DAB Support?
Hi, You can listen to DAB with http://www.sdr-j.tk/index.html You need a powerful CPU though, and you might have to unload the DVB driver first. On 27 October 2013 16:45, Christof Meerwald cme...@cmeerw.org wrote: Hi, http://www.linuxtv.org/wiki/index.php/RealTek_RTL2832U mentions DAB support. But what exactly does that mean? Can you actually listen to DAB radio with that hardware on Linux today (and if so, what software is needed) or is there lots of software/drivers missing to get DAB support working on Linux? Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Alistair Buxton a.j.bux...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gspca-stk1135: Add delay after configuring clock
Add a small delay at the end of configure_clock() to allow sensor to initialize. This is needed by Asus VX2S laptop webcam to detect sensor type properly (the already-supported MT9M112). Signed-off-by: Ondrej Zary li...@rainbow-software.org --- drivers/media/usb/gspca/stk1135.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/usb/gspca/stk1135.c b/drivers/media/usb/gspca/stk1135.c index 8add2f7..d8a813c 100644 --- a/drivers/media/usb/gspca/stk1135.c +++ b/drivers/media/usb/gspca/stk1135.c @@ -361,6 +361,9 @@ static void stk1135_configure_clock(struct gspca_dev *gspca_dev) /* set serial interface clock divider (30MHz/0x1f*16+2) = 60240 kHz) */ reg_w(gspca_dev, STK1135_REG_SICTL + 2, 0x1f); + + /* wait a while for sensor to catch up */ + udelay(1000); } static void stk1135_camera_disable(struct gspca_dev *gspca_dev) -- Ondrej Zary -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tda18271-fe: Fix dvb-c standard selection
Em Sat, 02 Nov 2013 23:31:58 +0200
CrazyCat crazyca...@narod.ru escreveu:
Mauro Carvalho Chehab пишет:
This is wrong, as it breaks for 6MHz-spaced channels, like what's used
in Brazil and Japan.
What happens here is that, if the tuner uses a too wide lowpass filter,
the interference will be higher at the demod, and it may not be able
to decode.
As the bandwidth is already estimated by the DVB frontend core, the
tuners should be adjusted to get the closest filter for a given
bandwidth.
So, the driver is correct (and it is tested under 6MHz spaced channels).
But usual applications only set cable standard (Annex A/C or B) and not set
bandwidth. So for annex A/C default selected 6MHz ?
Usual applications set the symbol rate, and symbol rate is easily
converted into bandwidth. The DVB core does that. see
dtv_set_frontend():
switch (c-delivery_system) {
case SYS_ATSC:
case SYS_DVBC_ANNEX_B:
c-bandwidth_hz = 600;
break;
case SYS_DVBC_ANNEX_A:
rolloff = 115;
break;
case SYS_DVBC_ANNEX_C:
rolloff = 113;
break;
default:
break;
}
if (rolloff)
c-bandwidth_hz = (c-symbol_rate * rolloff) / 100;
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 19/29] tuners: Don't use dynamic static allocation
Em Sat, 02 Nov 2013 22:59:04 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
On 11/02/2013 10:53 PM, Hans Verkuil wrote:
On 11/02/2013 10:15 PM, Mauro Carvalho Chehab wrote:
Em Sat, 02 Nov 2013 18:25:19 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
Hi Mauro,
I'll review this series more carefully on Monday,
Thanks!
but for now I want to make
a suggestion for the array checks:
On 11/02/2013 02:31 PM, Mauro Carvalho Chehab wrote:
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:66:1: warning:
'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/fc2580.c:98:1: warning:
'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:90:1: warning:
'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses
dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18218.c:92:1: warning:
'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by
default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 80, it seem safe to use 80 as the hard limit for all
those devices. On most cases, the limit is a way lower than that, but
80 is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/e4000.c| 18 --
drivers/media/tuners/fc2580.c | 18 --
drivers/media/tuners/tda18212.c | 18 --
drivers/media/tuners/tda18218.c | 18 --
4 files changed, 64 insertions(+), 8 deletions(-)
diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
index ad9309da4a91..235e90251609 100644
--- a/drivers/media/tuners/e4000.c
+++ b/drivers/media/tuners/e4000.c
@@ -24,7 +24,7 @@
static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int
len)
{
int ret;
-u8 buf[1 + len];
+u8 buf[80];
struct i2c_msg msg[1] = {
{
.addr = priv-cfg-i2c_addr,
@@ -34,6 +34,13 @@ static int e4000_wr_regs(struct e4000_priv *priv, u8
reg, u8 *val, int len)
}
};
+if (1 + len sizeof(buf)) {
+dev_warn(priv-i2c-dev,
+ %s: i2c wr reg=%04x: len=%d is too big!\n,
+ KBUILD_MODNAME, reg, len);
+return -EREMOTEIO;
+}
+
I think this can be greatly simplified to:
if (WARN_ON(len + 1 sizeof(buf))
return -EREMOTEIO;
This should really never happen, and it is a clear driver bug if it does.
WARN_ON
does the job IMHO.
Works for me. I'll wait for more comments, and go for it on v3.
I also don't like the EREMOTEIO error: it has nothing to do with
an I/O problem. Wouldn't EMSGSIZE be much better here?
EMSGSIZE is not used yet at drivers/media. So, it is probably not the
right error code.
I remember that there's an error code for that on I2C (EOPNOTSUPP?).
In any case, I don't think we should use an unusual error code here.
In theory, this error should never happen, but we don't want to break
userspace because of it. That's why I opted to use EREMOTEIO: this is
the error code that most of those drivers return when something gets
wrong during I2C transfers.
The problem I have is that EREMOTEIO is used when the i2c transfer fails,
i.e. there is some sort of a hardware or communication problem.
That's not the case here, it's an argument error. So EINVAL would actually
be better, but that's perhaps overused which is why I suggested EMSGSIZE.
I personally don't think EIO or EREMOTEIO should be used for something that
is not hardware related. I'm sure there are some gray areas, but this
particular situation is clearly not hardware-related.
So if EMSGSIZE won't work for you, then I prefer EINVAL over EREMOTEIO.
ENOMEM is also an option (you are after all 'out of buffer memory').
A bit more exotic, but still sort of in the area, is EPROTO.
After
[PATCH 04/12] tda18212dd: Support for NXP TDA18212 (DD) silicon tuner
Added support for the NXP TDA18212 silicon tuner used by recent
Digital Devices hardware. This will allow update of ddbridge driver
to support newer devices.
Signed-off-by: Maik Broemme mbroe...@parallels.com
---
drivers/media/dvb-frontends/Kconfig | 9 +
drivers/media/dvb-frontends/Makefile | 1 +
drivers/media/dvb-frontends/tda18212dd.c | 934 +++
drivers/media/dvb-frontends/tda18212dd.h | 37 ++
4 files changed, 981 insertions(+)
create mode 100644 drivers/media/dvb-frontends/tda18212dd.c
create mode 100644 drivers/media/dvb-frontends/tda18212dd.h
diff --git a/drivers/media/dvb-frontends/Kconfig
b/drivers/media/dvb-frontends/Kconfig
index 7cac015..a34c1c7 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -65,6 +65,15 @@ config DVB_STV0367DD
Say Y when you want to support this frontend.
+config DVB_TDA18212DD
+ tristate NXP TDA18212 silicon tuner (DD)
+ depends on DVB_CORE I2C
+ default m if DVB_FE_CUSTOMISE
+ help
+ NXP TDA18212 silicon tuner (Digital Devices driver).
+
+ Say Y when you want to support this tuner.
+
comment DVB-S (satellite) frontends
depends on DVB_CORE
diff --git a/drivers/media/dvb-frontends/Makefile
b/drivers/media/dvb-frontends/Makefile
index de100f1..ed12424 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_DVB_CXD2820R) += cxd2820r.o
obj-$(CONFIG_DVB_DRXK) += drxk.o
obj-$(CONFIG_DVB_TDA18271C2DD) += tda18271c2dd.o
obj-$(CONFIG_DVB_STV0367DD) += stv0367dd.o
+obj-$(CONFIG_DVB_TDA18212DD) += tda18212dd.o
obj-$(CONFIG_DVB_IT913X_FE) += it913x-fe.o
obj-$(CONFIG_DVB_A8293) += a8293.o
obj-$(CONFIG_DVB_TDA10071) += tda10071.o
diff --git a/drivers/media/dvb-frontends/tda18212dd.c
b/drivers/media/dvb-frontends/tda18212dd.c
new file mode 100644
index 000..3d2e04e
--- /dev/null
+++ b/drivers/media/dvb-frontends/tda18212dd.c
@@ -0,0 +1,934 @@
+/*
+ * tda18212dd.c: Driver for the TDA18212 tuner
+ *
+ * Copyright (C) 2010-2013 Digital Devices GmbH
+ * Copyright (C) 2013 Maik Broemme mbroe...@parallels.com
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/firmware.h
+#include linux/i2c.h
+#include linux/version.h
+#include asm/div64.h
+
+#include dvb_frontend.h
+
+#ifndef CHK_ERROR
+#define CHK_ERROR(s) if ((status = s) 0) break
+#endif
+
+#define MASTER_PSM_AGC1 0
+#define MASTER_AGC1_6_15dB 1
+
+#define SLAVE_PSM_AGC1 1
+#define SLAVE_AGC1_6_15dB 0
+
+// 0 = 2 Vpp ... 2 = 1 Vpp, 7 = 0.5 Vpp
+#define IF_LEVEL_DVBC2
+#define IF_LEVEL_DVBT2
+
+enum {
+ ID_1= 0x00,
+ ID_2= 0x01,
+ ID_3= 0x02,
+ THERMO_1,
+ THERMO_2,
+ POWER_STATE_1,
+ POWER_STATE_2,
+ INPUT_POWER_LEVEL,
+ IRQ_STATUS,
+ IRQ_ENABLE,
+ IRQ_CLEAR,
+ IRQ_SET,
+ AGC1_1,
+ AGC2_1,
+ AGCK_1,
+ RF_AGC_1,
+ IR_MIXER_1 = 0x10,
+ AGC5_1,
+ IF_AGC,
+ IF_1,
+ REFERENCE,
+ IF_FREQUENCY_1,
+ RF_FREQUENCY_1,
+ RF_FREQUENCY_2,
+ RF_FREQUENCY_3,
+ MSM_1,
+ MSM_2,
+ PSM_1,
+ DCC_1,
+ FLO_MAX,
+ IR_CAL_1,
+ IR_CAL_2,
+ IR_CAL_3= 0x20,
+ IR_CAL_4,
+ VSYNC_MGT,
+ IR_MIXER_2,
+ AGC1_2,
+ AGC5_2,
+ RF_CAL_1,
+ RF_CAL_2,
+ RF_CAL_3,
+ RF_CAL_4,
+ RF_CAL_5,
+ RF_CAL_6,
+ RF_FILTER_1,
+ RF_FILTER_2,
+ RF_FILTER_3,
+ RF_BAND_PASS_FILTER,
+ CP_CURRENT = 0x30,
+ AGC_DET_OUT = 0x31,
+ RF_AGC_GAIN_1 = 0x32,
+ RF_AGC_GAIN_2 = 0x33,
+ IF_AGC_GAIN = 0x34,
+ POWER_1 = 0x35,
+ POWER_2 = 0x36,
+ MISC_1,
+ RFCAL_LOG_1,
+ RFCAL_LOG_2,
+ RFCAL_LOG_3,
+ RFCAL_LOG_4,
+ RFCAL_LOG_5,
+ RFCAL_LOG_6,
+ RFCAL_LOG_7,
+ RFCAL_LOG_8,
+ RFCAL_LOG_9 = 0x40,
+ RFCAL_LOG_10= 0x41,
+ RFCAL_LOG_11=
[PATCH 05/12] cxd2843: Support for CXD2843ER demodulator for DVB-T/T2/C/C2
Added support for the CXD2843ER demodulator for DVB-T/T2/C/C2
used by recent Digital Devices hardware.
Signed-off-by: Maik Broemme mbroe...@parallels.com
---
drivers/media/dvb-frontends/Kconfig |9 +
drivers/media/dvb-frontends/Makefile |1 +
drivers/media/dvb-frontends/cxd2843.c | 1647 +
drivers/media/dvb-frontends/cxd2843.h | 47 +
4 files changed, 1704 insertions(+)
create mode 100644 drivers/media/dvb-frontends/cxd2843.c
create mode 100644 drivers/media/dvb-frontends/cxd2843.h
diff --git a/drivers/media/dvb-frontends/Kconfig
b/drivers/media/dvb-frontends/Kconfig
index a34c1c7..3e39319 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -74,6 +74,15 @@ config DVB_TDA18212DD
Say Y when you want to support this tuner.
+config DVB_CXD2843
+ tristate CXD2843ER based for DVB-T/T2/C/C2
+ depends on DVB_CORE I2C
+ default m if DVB_FE_CUSTOMISE
+ help
+ Sony CXD2843ER/CXD2837ER DVB-T/T2/C/C2 demodulator.
+
+ Say Y when you want to support this frontend.
+
comment DVB-S (satellite) frontends
depends on DVB_CORE
diff --git a/drivers/media/dvb-frontends/Makefile
b/drivers/media/dvb-frontends/Makefile
index ed12424..90cad36 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -99,6 +99,7 @@ obj-$(CONFIG_DVB_DRXK) += drxk.o
obj-$(CONFIG_DVB_TDA18271C2DD) += tda18271c2dd.o
obj-$(CONFIG_DVB_STV0367DD) += stv0367dd.o
obj-$(CONFIG_DVB_TDA18212DD) += tda18212dd.o
+obj-$(CONFIG_DVB_CXD2843) += cxd2843.o
obj-$(CONFIG_DVB_IT913X_FE) += it913x-fe.o
obj-$(CONFIG_DVB_A8293) += a8293.o
obj-$(CONFIG_DVB_TDA10071) += tda10071.o
diff --git a/drivers/media/dvb-frontends/cxd2843.c
b/drivers/media/dvb-frontends/cxd2843.c
new file mode 100644
index 000..87a3000
--- /dev/null
+++ b/drivers/media/dvb-frontends/cxd2843.c
@@ -0,0 +1,1647 @@
+/*
+ * cxd2843.c: Driver for the Sony CXD2843ER DVB-T/T2/C/C2 demodulator.
+ * Also supports the CXD2837ER DVB-T/T2/C and the CXD2838ER
+ * ISDB-T demodulator.
+ *
+ * Copyright (C) 2010-2013 Digital Devices GmbH
+ * Copyright (C) 2013 Maik Broemme mbroe...@parallels.com
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/firmware.h
+#include linux/i2c.h
+#include linux/version.h
+#include linux/mutex.h
+#include asm/div64.h
+
+#include dvb_frontend.h
+#include cxd2843.h
+
+
+enum EDemodType { CXD2843, CXD2837, CXD2838 };
+enum EDemodState { Unknown, Shutdown, Sleep, ActiveT, ActiveT2, ActiveC,
ActiveC2, ActiveIT };
+enum omode { OM_NONE, OM_DVBT, OM_DVBT2, OM_DVBC, OM_QAM_ITU_C, OM_DVBC2,
OM_ISDBT };
+
+struct cxd_state {
+ struct dvb_frontend frontend;
+ struct i2c_adapter *i2c;
+ struct mutex mutex;
+
+ u8 adrt;
+ u8 curbankt;
+
+ u8 adrx;
+ u8 curbankx;
+
+ enum EDemodType type;
+ enum EDemodState state;
+ enum omode omode;
+
+ u8IF_FS;
+ int ContinuousClock;
+ int SerialMode;
+ u8SerialClockFrequency;
+
+ u32 LockTimeout;
+ u32 TSLockTimeout;
+ u32 L1PostTimeout;
+ u32 DataSliceID;
+ int FirstTimeLock;
+ u32 PLPNumber;
+ u32 last_status;
+
+ u32 bandwidth;
+ u32 bw;
+};
+
+static int i2c_write(struct i2c_adapter *adap, u8 adr, u8 *data, int len)
+{
+ struct i2c_msg msg =
+ {.addr = adr, .flags = 0, .buf = data, .len = len};
+
+ if (i2c_transfer(adap, msg, 1) != 1) {
+ printk(cxd2843: i2c_write error\n);
+ return -1;
+ }
+ return 0;
+}
+
+static int writeregs(struct cxd_state *state, u8 adr, u8 reg, u8 *regd, u16
len)
+{
+ u8 data[len + 1];
+
+ data[0] = reg;
+ memcpy(data + 1, regd, len);
+ return i2c_write(state-i2c, adr, data, len + 1);
+}
+
+static int writereg(struct cxd_state *state, u8 adr, u8 reg, u8 dat)
+{
+ u8 mm[2] = {reg, dat};
+
+ return i2c_write(state-i2c, adr, mm, 2);
+}
+
+static int i2c_read(struct i2c_adapter *adap,
+ u8 adr, u8 *msg, int len, u8
[PATCH 06/12] dvb-core: export dvb_usercopy and new DVB device constants
Added EXPORT_SYMBOL(dvb_usercopy) to allow new ddbridge driver to
use it. It is questionable if I should use it in this way or not.
If not I will fix it.
Added two new DVB device constants DVB_DEVICE_CI and DVB_DEVICE_MOD
required by newer ddbridge driver. Again it is questionable to use
them or modify ddbridge driver.
Signed-off-by: Maik Broemme mbroe...@parallels.com
---
drivers/media/dvb-core/dvbdev.c | 1 +
drivers/media/dvb-core/dvbdev.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index 401ef64..e451e9e 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -438,6 +438,7 @@ out:
kfree(mbuf);
return err;
}
+EXPORT_SYMBOL(dvb_usercopy);
static int dvb_uevent(struct device *dev, struct kobj_uevent_env *env)
{
diff --git a/drivers/media/dvb-core/dvbdev.h b/drivers/media/dvb-core/dvbdev.h
index 93a9470..016c46e 100644
--- a/drivers/media/dvb-core/dvbdev.h
+++ b/drivers/media/dvb-core/dvbdev.h
@@ -47,6 +47,8 @@
#define DVB_DEVICE_CA 6
#define DVB_DEVICE_NET7
#define DVB_DEVICE_OSD8
+#define DVB_DEVICE_CI 9
+#define DVB_DEVICE_MOD 10
#define DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr) \
static short adapter_nr[] = \
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/12] ddbridge: Updated ddbridge registers
Updated ddbridge registers: - Added GPIO and MDIO registers - Added Clock Generator (Sil598 @ 0xAA I2c) - Added DAC (AD9781/AD9783 SPI) - Added Temperature Monitor (2x LM75A @ 0x90,0x92 I2c) - Added CI Interface (only CI-Bridge) - Added output control registers - Added modulator channels - Removed unneded defines (might be added later again if needed) Signed-off-by: Maik Broemme mbroe...@parallels.com --- drivers/media/pci/ddbridge/ddbridge-regs.h | 273 ++--- 1 file changed, 168 insertions(+), 105 deletions(-) diff --git a/drivers/media/pci/ddbridge/ddbridge-regs.h b/drivers/media/pci/ddbridge/ddbridge-regs.h index a3ccb31..7d8bda4 100644 --- a/drivers/media/pci/ddbridge/ddbridge-regs.h +++ b/drivers/media/pci/ddbridge/ddbridge-regs.h @@ -1,47 +1,53 @@ /* - * ddbridge-regs.h: Digital Devices PCIe bridge driver + * ddbridge-regs.h: Digital Devices PCIe bridge driver * - * Copyright (C) 2010-2011 Digital Devices GmbH + * Copyright (C) 2010-2013 Digital Devices GmbH + * Copyright (C) 2013 Maik Broemme mbroe...@parallels.com * - * 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 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. * - * 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. - * - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA - * 02110-1301, USA - * Or, point your browser to http://www.gnu.org/copyleft/gpl.html + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA + * 02110-1301, USA */ -/* DD-DVBBridgeV1.h 273 2010-09-17 05:03:16Z manfred */ +#ifndef _DDBRIDGE_REGS_H_ +#define _DDBRIDGE_REGS_H_ /* Register Definitions */ +#define CUR_REGISTERMAP_VERSION 0x10003 +#define CUR_REGISTERMAP_VERSION_CI 0x1 +#define CUR_REGISTERMAP_VERSION_MOD 0x1 -#define CUR_REGISTERMAP_VERSION 0x1 - -#define HARDWARE_VERSION 0x00 -#define REGISTERMAP_VERSION0x04 +#define HARDWARE_VERSION0x00 +#define REGISTERMAP_VERSION 0x04 -/* - */ /* SPI Controller */ +#define SPI_CONTROL 0x10 +#define SPI_DATA 0x14 -#define SPI_CONTROL 0x10 -#define SPI_DATA0x14 +/* GPIO */ +#define GPIO_OUTPUT 0x20 +#define GPIO_DIRECTION 0x28 -/* - */ +/* MDIO */ +#define MDIO_CTRL0x20 +#define MDIO_ADR 0x24 +#define MDIO_REG 0x28 +#define MDIO_VAL 0x2C -/* Interrupt controller */ -/* How many MSI's are available depends on HW (Min 2 max 8) */ -/* How many are usable also depends on Host platform*/ +/* How many MSI's are available depends on HW (Min 2 max 8) + How many are usable also depends on Host platform */ +/* Interrupt controller */ #define INTERRUPT_BASE (0x40) #define INTERRUPT_ENABLE (INTERRUPT_BASE + 0x00) @@ -57,95 +63,152 @@ #define INTERRUPT_STATUS (INTERRUPT_BASE + 0x20) #define INTERRUPT_ACK(INTERRUPT_BASE + 0x20) -#define INTMASK_I2C1(0x0001) -#define INTMASK_I2C2(0x0002) -#define INTMASK_I2C3(0x0004) -#define INTMASK_I2C4(0x0008) - -#define INTMASK_CIRQ1 (0x0010) -#define INTMASK_CIRQ2 (0x0020) -#define INTMASK_CIRQ3 (0x0040) -#define INTMASK_CIRQ4 (0x0080) - -#define INTMASK_TSINPUT1(0x0100) -#define INTMASK_TSINPUT2(0x0200) -#define INTMASK_TSINPUT3(0x0400) -#define INTMASK_TSINPUT4(0x0800) -#define INTMASK_TSINPUT5(0x1000) -#define INTMASK_TSINPUT6(0x2000) -#define INTMASK_TSINPUT7(0x4000) -#define INTMASK_TSINPUT8(0x8000) - -#define INTMASK_TSOUTPUT1 (0x0001) -#define INTMASK_TSOUTPUT2 (0x0002) -#define INTMASK_TSOUTPUT3 (0x0004) -#define INTMASK_TSOUTPUT4 (0x0008) - -/*
[PATCH 00/12] DDBridge 0.9.10 driver updates
I've updated the current DDBridge to latest version 0.9.10 from Ralph Metzler available at: http://www.metzlerbros.de/dddvb/dddvb-0.9.10.tar.bz2 I've merged the driver to work with current v4l/dvb tree and I will maintain the driver for v4l/dvb in future. The coming patch series is the first version and I explicitly want to get feedback and hints if some parts are merged at wrong places, etc... The following changes were made: - MSI enabled by default (some issues left with i2c timeouts) - no support for Digital Devices Octonet - no support for DVB Netstream - removed unused module parameters 'tt' and 'vlan' (used by Octonet) - removed unused registers to cleanup code (might be added later again if needed) The following devices are supported by the driver update: - Octopus DVB adapter - Octopus V3 DVB adapter - Octopus LE DVB adapter - Octopus OEM - Octopus Mini - Cine S2 V6 DVB adapter - Cine S2 V6.5 DVB adapter - Octopus CI - Octopus CI single - DVBCT V6.1 DVB adapter - DVB-C modulator - SaTiX-S2 V3 DVB adapter I might merge the Octonet and DVB Netstream drivers from Ralphs source later once the current committed DDBridge driver updates are merged in mainline. Signed-off-by: Maik Broemme mbroe...@parallels.com Maik Broemme (12): dvb-frontends: Support for DVB-C2 to DVB frontends tda18271c2dd: Fix description of NXP TDA18271C2 silicon tuner stv0367dd: Support for STV 0367 DVB-C/T (DD) demodulator tda18212dd: Support for NXP TDA18212 (DD) silicon tuner cxd2843: Support for CXD2843ER demodulator for DVB-T/T2/C/C2 dvb-core: export dvb_usercopy and new DVB device constants ddbridge: Updated ddbridge registers ddbridge: Moved i2c interfaces into separate file ddbridge: Support for the Digital Devices Resi DVB-C Modulator card ddbridge: Update ddbridge driver to version 0.9.10 ddbridge: Update ddbridge header for 0.9.10 changes ddbridge: Kconfig and Makefile fixes to build latest ddbridge drivers/media/dvb-core/dvbdev.c |1 drivers/media/dvb-core/dvbdev.h |2 drivers/media/dvb-frontends/Kconfig | 31 drivers/media/dvb-frontends/Makefile |3 drivers/media/dvb-frontends/cxd2843.c| 1647 drivers/media/dvb-frontends/cxd2843.h| 47 drivers/media/dvb-frontends/stv0367dd.c | 2329 ++ drivers/media/dvb-frontends/stv0367dd.h | 48 drivers/media/dvb-frontends/stv0367dd_regs.h | 3442 +++ drivers/media/dvb-frontends/tda18212dd.c | 934 +++ drivers/media/dvb-frontends/tda18212dd.h | 37 drivers/media/pci/ddbridge/Kconfig | 21 drivers/media/pci/ddbridge/Makefile |2 drivers/media/pci/ddbridge/ddbridge-core.c | 3085 +--- drivers/media/pci/ddbridge/ddbridge-i2c.c| 239 + drivers/media/pci/ddbridge/ddbridge-mod.c| 1033 drivers/media/pci/ddbridge/ddbridge-regs.h | 273 +- drivers/media/pci/ddbridge/ddbridge.h| 408 ++- include/uapi/linux/dvb/frontend.h|1 19 files changed, 12555 insertions(+), 1028 deletions(-) --Maik -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/12] tda18271c2dd: Fix description of NXP TDA18271C2 silicon tuner
Added (DD) to NXP TDA18271C2 silicon tuner as this tuner was specifically added for Digital Devices ddbridge driver. Signed-off-by: Maik Broemme mbroe...@parallels.com --- drivers/media/dvb-frontends/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/dvb-frontends/Kconfig b/drivers/media/dvb-frontends/Kconfig index bddbab4..6f99eb8 100644 --- a/drivers/media/dvb-frontends/Kconfig +++ b/drivers/media/dvb-frontends/Kconfig @@ -48,11 +48,11 @@ config DVB_DRXK Say Y when you want to support this frontend. config DVB_TDA18271C2DD - tristate NXP TDA18271C2 silicon tuner + tristate NXP TDA18271C2 silicon tuner (DD) depends on DVB_CORE I2C default m if !MEDIA_SUBDRV_AUTOSELECT help - NXP TDA18271 silicon tuner. + NXP TDA18271 silicon tuner (Digital Devices driver). Say Y when you want to support this tuner. -- 1.8.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/12] dvb-frontends: Support for DVB-C2 to DVB frontends
Added support for DVB-C2 to DVB frontends. It will be required
by cxd2843 and tda18212dd (Digital Devices) frontends.
Signed-off-by: Maik Broemme mbroe...@parallels.com
---
include/uapi/linux/dvb/frontend.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/dvb/frontend.h
b/include/uapi/linux/dvb/frontend.h
index c56d77c..98648eb 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -410,6 +410,7 @@ typedef enum fe_delivery_system {
SYS_DVBT2,
SYS_TURBO,
SYS_DVBC_ANNEX_C,
+ SYS_DVBC2,
} fe_delivery_system_t;
/* backward compatibility */
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/12] ddbridge: Moved i2c interfaces into separate file
Moved i2c interfaces from ddbridge-core.c into separate file.
Signed-off-by: Maik Broemme mbroe...@parallels.com
---
drivers/media/pci/ddbridge/ddbridge-i2c.c | 239 ++
1 file changed, 239 insertions(+)
create mode 100644 drivers/media/pci/ddbridge/ddbridge-i2c.c
diff --git a/drivers/media/pci/ddbridge/ddbridge-i2c.c
b/drivers/media/pci/ddbridge/ddbridge-i2c.c
new file mode 100644
index 000..5e9788c
--- /dev/null
+++ b/drivers/media/pci/ddbridge/ddbridge-i2c.c
@@ -0,0 +1,239 @@
+/*
+ * ddbridge-i2c.c: Digital Devices bridge i2c driver
+ *
+ * Copyright (C) 2010-2013 Digital Devices GmbH
+ * Copyright (C) 2013 Maik Broemme mbroe...@parallels.com
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA
+ */
+
+#include ddbridge.h
+#include ddbridge-regs.h
+
+static int i2c_cmd(struct ddb_i2c *i2c, u32 adr, u32 cmd)
+{
+ struct ddb *dev = i2c-dev;
+ int stat;
+ u32 val;
+ u32 istat;
+
+ // i2c-done = 0;
+ ddbwritel(dev, (adr 9) | cmd, i2c-regs + I2C_COMMAND);
+
+ // TODO: fix timeout issue.
+ // stat = wait_event_timeout(i2c-wq, i2c-done == 1, HZ);
+ stat = wait_for_completion_timeout(i2c-completion, HZ);
+ if (stat = 0) {
+ printk(KERN_ERR DDBridge I2C timeout, card %d, port %d\n,
+ dev-nr, i2c-nr);
+ istat = ddbreadl(dev, INTERRUPT_STATUS);
+ printk(KERN_ERR DDBridge IRS %08x\n, istat);
+ ddbwritel(dev, istat, INTERRUPT_ACK);
+ return -EIO;
+ }
+ val = ddbreadl(dev, i2c-regs + I2C_COMMAND);
+ if (val 0x7)
+ return -EIO;
+ return 0;
+}
+
+static int i2c_master_xfer(struct i2c_adapter *adapter,
+ struct i2c_msg msg[], int num)
+{
+ struct ddb_i2c *i2c = (struct ddb_i2c *) i2c_get_adapdata(adapter);
+ struct ddb *dev = i2c-dev;
+ u8 addr = 0;
+
+ if (num)
+ addr = msg[0].addr;
+ if (num == 2 msg[1].flags I2C_M_RD
+ !(msg[0].flags I2C_M_RD)) {
+ memcpy_toio(dev-regs + I2C_TASKMEM_BASE + i2c-wbuf,
+ msg[0].buf, msg[0].len);
+ ddbwritel(dev, msg[0].len|(msg[1].len 16),
+ i2c-regs + I2C_TASKLENGTH);
+ if (!i2c_cmd(i2c, addr, 1)) {
+ memcpy_fromio(msg[1].buf,
+ dev-regs + I2C_TASKMEM_BASE + i2c-rbuf,
+ msg[1].len);
+ return num;
+ }
+ }
+ if (num == 1 !(msg[0].flags I2C_M_RD)) {
+ ddbcpyto(dev, I2C_TASKMEM_BASE + i2c-wbuf,
+msg[0].buf, msg[0].len);
+ ddbwritel(dev, msg[0].len, i2c-regs + I2C_TASKLENGTH);
+ if (!i2c_cmd(i2c, addr, 2)) {
+ return num;
+ }
+ }
+ if (num == 1 (msg[0].flags I2C_M_RD)) {
+ ddbwritel(dev, msg[0].len 16, i2c-regs + I2C_TASKLENGTH);
+ if (!i2c_cmd(i2c, addr, 3)) {
+ ddbcpyfrom(dev, msg[0].buf,
+ I2C_TASKMEM_BASE + i2c-rbuf, msg[0].len);
+ return num;
+ }
+ }
+ return -EIO;
+}
+
+static u32 i2c_functionality(struct i2c_adapter *adap)
+{
+ return I2C_FUNC_SMBUS_EMUL;
+}
+
+static void i2c_handler(unsigned long priv)
+{
+ struct ddb_i2c *i2c = (struct ddb_i2c *) priv;
+
+ complete(i2c-completion);
+}
+
+static struct i2c_algorithm i2c_algo = {
+ .master_xfer = i2c_master_xfer,
+ .functionality = i2c_functionality,
+};
+
+int ddb_i2c_write(struct i2c_adapter *adap, u8 adr, u8 *data, int len)
+{
+ struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = data, .len = len};
+
+ return (i2c_transfer(adap, msg, 1) == 1) ? 0 : -1;
+}
+
+int ddb_i2c_read(struct i2c_adapter *adapter, u8 adr, u8 *val)
+{
+ struct i2c_msg msgs[1] = {{.addr = adr, .flags = I2C_M_RD,
+ .buf = val, .len = 1 } };
+ return (i2c_transfer(adapter, msgs, 1) == 1) ? 0 : -1;
+}
+
+int ddb_i2c_read_regs(struct i2c_adapter *adapter,
+u8 adr, u8 reg, u8 *val, u8 len)
+{
+ struct i2c_msg msgs[2] = {{.addr
[PATCH 09/12] ddbridge: Support for the Digital Devices Resi DVB-C Modulator card
Added support for the Digital Devices Resi DVB-C Modulator card.
Signed-off-by: Maik Broemme mbroe...@parallels.com
---
drivers/media/pci/ddbridge/ddbridge-mod.c | 1033 +
1 file changed, 1033 insertions(+)
create mode 100644 drivers/media/pci/ddbridge/ddbridge-mod.c
diff --git a/drivers/media/pci/ddbridge/ddbridge-mod.c
b/drivers/media/pci/ddbridge/ddbridge-mod.c
new file mode 100644
index 000..8f7c256
--- /dev/null
+++ b/drivers/media/pci/ddbridge/ddbridge-mod.c
@@ -0,0 +1,1033 @@
+/*
+ * ddbridge-mod.c: Digital Devices DVB modulator driver
+ *
+ * Copyright (C) 2010-2013 Digital Devices GmbH
+ * Copyright (C) 2013 Maik Broemme mbroe...@parallels.com
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA
+ */
+
+#include ddbridge.h
+#include ddbridge-regs.h
+
+inline s64 ConvertPCR(s64 a)
+{
+ s32 ext;
+ s64 b;
+
+ b = div_s64_rem(a, 300 22, ext);
+
+ return (b 31) | ext;
+
+}
+
+inline s64 NegConvertPCR(s64 a)
+{
+ s32 ext;
+ s64 b;
+
+ b = -div_s64_rem(a, 300 22, ext);
+
+ if( ext != 0 ) {
+ ext = (300 22) - ext;
+ b -= 1;
+ }
+ return (b 31) | ext;
+}
+
+inline s64 RoundPCR(s64 a)
+{
+ s64 b = a + (HW_LSB_MASK1);
+ return b ~(HW_LSB_MASK - 1);
+}
+
+inline s64 RoundPCRUp(s64 a)
+{
+ s64 b = a + (HW_LSB_MASK - 1);
+ return b ~(HW_LSB_MASK - 1);
+}
+
+inline s64 RoundPCRDown(s64 a)
+{
+ return a ~(HW_LSB_MASK - 1);
+}
+
+static int mod_busy(struct ddb *dev, int chan)
+{
+ u32 creg;
+
+ while (1) {
+ creg = ddbreadl(dev, CHANNEL_CONTROL(chan));
+ if (creg == 0x)
+ return -EFAULT;
+ if ((creg CHANNEL_CONTROL_BUSY) == 0)
+ break;
+ }
+ return 0;
+}
+
+void ddbridge_mod_output_stop(struct ddb_output *output)
+{
+ struct ddb *dev = output-port-dev;
+ struct mod_state *mod= dev-mod[output-nr];
+
+ mod-State = CM_IDLE;
+ mod-Control = 0;
+ ddbwritel(dev, 0, CHANNEL_CONTROL(output-nr));
+
+ mod_busy(dev, output-nr);
+ printk(mod_output_stop %d.%d\n, dev-nr, output-nr);
+}
+
+static void mod_set_incs(struct ddb_output *output)
+{
+ s64 pcr;
+ struct ddb *dev = output-port-dev;
+ struct mod_state *mod= dev-mod[output-nr];
+
+ pcr = ConvertPCR(mod-PCRIncrement);
+ ddbwritel(dev, pcr 0x,
+ CHANNEL_PCR_ADJUST_OUTL(output-nr));
+ ddbwritel(dev, (pcr 32) 0x,
+ CHANNEL_PCR_ADJUST_OUTH(output-nr));
+ mod_busy(dev, output-nr);
+
+ pcr = NegConvertPCR(mod-PCRDecrement);
+ ddbwritel(dev, pcr 0x,
+ CHANNEL_PCR_ADJUST_INL(output-nr));
+ ddbwritel(dev, (pcr 32) 0x,
+ CHANNEL_PCR_ADJUST_INH(output-nr));
+ mod_busy(dev, output-nr);
+
+}
+
+static u32 qamtab[6] = { 0x000, 0x600, 0x601, 0x602, 0x903, 0x604 };
+
+void ddbridge_mod_output_start(struct ddb_output *output)
+{
+ struct ddb *dev = output-port-dev;
+ struct mod_state *mod= dev-mod[output-nr];
+
+ // PCRIncrement = RoundPCR(PCRIncrement);
+ // PCRDecrement = RoundPCR(PCRDecrement);
+
+ mod-LastInPacketCount = 0;
+ mod-LastOutPacketCount = 0;
+ mod-InOverflowPacketCount = 0;
+ mod-OutOverflowPacketCount = 0;
+ mod-LastInPackets = 0;
+ mod-LastOutPackets = 0;
+ mod-LastPCRAdjust = 0;
+ mod-PCRRunningCorr = 0;
+ mod-MinInputPackets = 524288/2; // we interrupt every 0x8=524288
packets
+ mod-PCRIncrement = 0; // PCRIncrement;
+ mod-PCRDecrement = 0; // PCRDecrement;
+
+ mod-State = CM_STARTUP;
+ mod-StateCounter = CM_STARTUP_DELAY;
+
+ ddbwritel(dev, 0, CHANNEL_CONTROL(output-nr));
+ udelay(10);
+ ddbwritel(dev, CHANNEL_CONTROL_RESET, CHANNEL_CONTROL(output-nr));
+ udelay(10);
+ ddbwritel(dev, 0, CHANNEL_CONTROL(output-nr));
+
+ // QAM: 600 601 602 903 604 = 16 32 64 128 256
+ // ddbwritel(dev, 0x604, CHANNEL_SETTINGS(output-nr));
+ ddbwritel(dev, qamtab[mod-modulation], CHANNEL_SETTINGS(output-nr));
+
+ ddbwritel(dev, mod-rate_inc, CHANNEL_RATE_INCR(output-nr));
+
[PATCH 11/12] ddbridge: Update ddbridge header for 0.9.10 changes
Updated ddbridge header for 0.9.10 changes.
Signed-off-by: Maik Broemme mbroe...@parallels.com
---
drivers/media/pci/ddbridge/ddbridge.h | 408 --
1 file changed, 343 insertions(+), 65 deletions(-)
diff --git a/drivers/media/pci/ddbridge/ddbridge.h
b/drivers/media/pci/ddbridge/ddbridge.h
index 8b1b41d..f35a5b4 100644
--- a/drivers/media/pci/ddbridge/ddbridge.h
+++ b/drivers/media/pci/ddbridge/ddbridge.h
@@ -1,38 +1,69 @@
/*
- * ddbridge.h: Digital Devices PCIe bridge driver
+ * ddbridge.h: Digital Devices PCIe bridge driver
*
- * Copyright (C) 2010-2011 Digital Devices GmbH
+ * Copyright (C) 2010-2013 Digital Devices GmbH
+ * Copyright (C) 2013 Maik Broemme mbroe...@parallels.com
*
- * 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 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.
*
- * 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.
- *
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA
- * Or, point your browser to http://www.gnu.org/copyleft/gpl.html
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA
*/
#ifndef _DDBRIDGE_H_
#define _DDBRIDGE_H_
+#include linux/version.h
+
+#if (LINUX_VERSION_CODE = KERNEL_VERSION(3,8,0))
+#define __devexit
+#define __devinit
+#endif
+
+#include linux/module.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/slab.h
+#include linux/poll.h
+#include linux/io.h
+#include linux/pci.h
+#include linux/pci_ids.h
+#include linux/timer.h
+#include linux/i2c.h
+#include linux/swab.h
+#include linux/vmalloc.h
+#include linux/workqueue.h
+#include linux/kthread.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/spi/spi.h
+#include linux/gpio.h
+#include linux/completion.h
+
#include linux/types.h
#include linux/sched.h
#include linux/interrupt.h
#include linux/i2c.h
#include linux/mutex.h
#include asm/dma.h
-#include linux/dvb/frontend.h
+#include asm/io.h
+#include asm/irq.h
+#include asm/uaccess.h
+
#include linux/dvb/ca.h
#include linux/socket.h
+#include linux/device.h
+#include linux/io.h
#include dmxdev.h
#include dvbdev.h
@@ -44,51 +75,83 @@
#include cxd2099.h
#define DDB_MAX_I2C 4
-#define DDB_MAX_PORT4
+#define DDB_MAX_PORT 10
#define DDB_MAX_INPUT 8
-#define DDB_MAX_OUTPUT 4
+#define DDB_MAX_OUTPUT 10
+
+struct ddb_regset {
+ uint32_t base;
+ uint32_t num;
+ uint32_t size;
+};
+
+struct ddb_regmap {
+ struct ddb_regset i2c;
+ struct ddb_regset i2c_buf;
+ struct ddb_regset dma;
+ struct ddb_regset dma_buf;
+ struct ddb_regset input;
+ struct ddb_regset output;
+ struct ddb_regset channel;
+ struct ddb_regset ci;
+ struct ddb_regset pid_filter;
+};
struct ddb_info {
int type;
#define DDB_NONE 0
#define DDB_OCTOPUS 1
+#define DDB_OCTOPUS_CI 2
+#define DDB_MOD 3
+#define DDB_OCTONET 4
char *name;
int port_num;
- u32 port_type[DDB_MAX_PORT];
+ int i2c_num;
+ int led_num;
+ int fan_num;
+ int temp_num;
+ int temp_bus;
+ struct ddb_regmap regmap;
};
-/* DMA_SIZE MUST be divisible by 188 and 128 !!! */
+/* DMA_SIZE MUST be smaller than 256k and
+ MUST be divisible by 188 and 128 !!! */
+
+#define DMA_MAX_BUFS 32 /* hardware table limit */
-#define INPUT_DMA_MAX_BUFS 32 /* hardware table limit */
#define INPUT_DMA_BUFS 8
#define INPUT_DMA_SIZE (128*47*21)
+#define INPUT_DMA_IRQ_DIV 1
-#define OUTPUT_DMA_MAX_BUFS 32
#define OUTPUT_DMA_BUFS 8
#define OUTPUT_DMA_SIZE (128*47*21)
+#define OUTPUT_DMA_IRQ_DIV 1
struct ddb;
struct ddb_port;
-struct ddb_input {
- struct ddb_port *port;
+struct ddb_dma {
+ void *io;
u32nr;
- intattached;
-
- dma_addr_t
[PATCH 12/12] ddbridge: Kconfig and Makefile fixes to build latest ddbridge
Fixed Kconfig and Makefile to build latest version off ddbridge. It adds support for the following devices: - Octopus DVB adapter - Octopus V3 DVB adapter - Octopus LE DVB adapter - Octopus OEM - Octopus Mini - Cine S2 V6 DVB adapter - Cine S2 V6.5 DVB adapter - Octopus CI - Octopus CI single - DVBCT V6.1 DVB adapter - DVB-C modulator - SaTiX-S2 V3 DVB adapter Signed-off-by: Maik Broemme mbroe...@parallels.com --- drivers/media/pci/ddbridge/Kconfig | 21 +++-- drivers/media/pci/ddbridge/Makefile | 2 +- 2 files changed, 16 insertions(+), 7 deletions(-) diff --git a/drivers/media/pci/ddbridge/Kconfig b/drivers/media/pci/ddbridge/Kconfig index 44e5dc1..a30848f 100644 --- a/drivers/media/pci/ddbridge/Kconfig +++ b/drivers/media/pci/ddbridge/Kconfig @@ -6,13 +6,22 @@ config DVB_DDBRIDGE select DVB_STV090x if MEDIA_SUBDRV_AUTOSELECT select DVB_DRXK if MEDIA_SUBDRV_AUTOSELECT select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT + select DVB_STV0367DD if MEDIA_SUBDRV_AUTOSELECT + select DVB_TDA18212DD if MEDIA_SUBDRV_AUTOSELECT + select DVB_CXD2843 if MEDIA_SUBDRV_AUTOSELECT ---help--- Support for cards with the Digital Devices PCI express bridge: - - Octopus PCIe Bridge - - Octopus mini PCIe Bridge - - Octopus LE - - DuoFlex S2 Octopus - - DuoFlex CT Octopus - - cineS2(v6) + - Octopus DVB adapter + - Octopus V3 DVB adapter + - Octopus LE DVB adapter + - Octopus OEM + - Octopus Mini + - Cine S2 V6 DVB adapter + - Cine S2 V6.5 DVB adapter + - Octopus CI + - Octopus CI single + - DVBCT V6.1 DVB adapter + - DVB-C modulator + - SaTiX-S2 V3 DVB adapter Say Y if you own such a card and want to use it. diff --git a/drivers/media/pci/ddbridge/Makefile b/drivers/media/pci/ddbridge/Makefile index 7446c8b..c274b81 100644 --- a/drivers/media/pci/ddbridge/Makefile +++ b/drivers/media/pci/ddbridge/Makefile @@ -2,7 +2,7 @@ # Makefile for the ddbridge device driver # -ddbridge-objs := ddbridge-core.o +ddbridge-objs := ddbridge-core.o ddbridge-i2c.o ddbridge-mod.o obj-$(CONFIG_DVB_DDBRIDGE) += ddbridge.o -- 1.8.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Nov 3 04:00:28 CET 2013 git branch: for-v3.13c git hash: 3adeac2c34cc28e05d0ec52f38f009dcce278555 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.11-6.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
