- 18 Nov, 2016 40 commits
-
-
Peter Griffin authored
Now that CLK_PROC_STFE is defined as a critical clock in DT, we can remove the commented clk_disable_unprepare from the c8sectpfe driver. This means we now have balanced clk*enable/disable calls in the driver, but on STiH407 family the clock in reality will never actually be disabled. This is due to a HW bug where once the IP has been configured and the SLIM core is running, disabling the clock causes a unrecoverable bus lockup. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Acked-by: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Jean-Baptiste Abbadie authored
Removes the superfluous statement about writing to the FSF in the GPL notice Signed-off-by: Jean-Baptiste Abbadie <jb@abbadie.fr> Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Jean-Baptiste Abbadie authored
Align multiple lines statement with parentheses Signed-off-by: Jean-Baptiste Abbadie <jb@abbadie.fr> Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Jean-Baptiste Abbadie authored
This replaces the S_* style permissions by numbers for the __ATTR macros Signed-off-by: Jean-Baptiste Abbadie <jb@abbadie.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Sakari Ailus authored
Document the interface between the CSI-2 transmitter and receiver drivers. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Markus Elfring authored
A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Markus Elfring authored
Return directly after a call of the function "rc_allocate_device" failed at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Markus Elfring authored
The local variable "ret" will be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Markus Elfring authored
The local variable "rc" will be set to an appropriate value a bit later. Thus omit the explicit initialisation at the beginning. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Markus Elfring authored
* Return directly after a call of the function "kcalloc" failed at the beginning. * Reorder two calls for the function "kfree" at the end. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Markus Elfring authored
Replace the specification of a data type by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Markus Elfring authored
The script "checkpatch.pl" pointed information out like the following. WARNING: Possible unnecessary 'out of memory' message Thus remove such a logging statement in five functions. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Markus Elfring authored
* Multiplications for the size determination of memory allocations indicated that array data structures should be processed. Thus use the corresponding function "kcalloc". This issue was detected by using the Coccinelle software. * Replace the specification of data types by pointer dereferences to make the corresponding size determination a bit safer according to the Linux coding style convention. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Unfortunately, the callers of tveeprom don't do the right thing to initialize the device. So, it produces log messages like: [ 267.533010] (null): Hauppauge model 42012, rev C186, serial# 2819348 [ 267.533012] (null): tuner model is Philips FQ1236 MK3 (idx 86, type 43) [ 267.533013] (null): TV standards NTSC(M) (eeprom 0x08) [ 267.533014] (null): audio processor is MSP3445 (idx 12) [ 267.533015] (null): has radio So, replace it to pr_foo(), as it should work fine. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Instead of calling printk() directly, use pr_foo() macro. That should make the rc_core messages be formatted with the right prefix. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Unfortunately, KERN_CONT doesn't work with dev_foo(), producing weird messages like: tvp5150 6-005c: tvp5150: read 0xf6 = 0xff ff So, we need to get rid of it. As we're always printing read/write in hexa when dumping multiple register values, also remove the "0x" from the read/write debug messages too. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
When returning results via v4l2_subdev_core_ops.log_status, use dev_foo() call, instead of just calling printk() directly, without even specifying the log message level. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Instead of using v4l_foo(), use the dev_foo() macros, as most modern media drivers. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Instead of using pr_foo(), use dev_foo(), with provides a better output. As this device is a multi-interface one, we'll set the device name to show the chipset and the driver used. While here, get rid of printk continuation messages. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Instead of using the v4l_foo() macros, just use the kernel-wide dev_foo() macros, as there's no good reason to use something else. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Drivers using dev_foo() macro should not use KERN_CONT, as, internally, those macros work as if all strings were terminated by a \n. So, doing: dev_info(&client->dev, "%s ", client->name); printk(KERN_CONT "supports radio, mode is autodetect and autoselect"); Would produce the following output: msp3400 6-0044: msp3400 supports radio, mode is autodetect and autoselect As there's no good reason to use KERN_CONT, let's rewrite the code to avoid that, allowing this driver to be converted to dev_foo(). Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Currently, there's a mess at the V4L2 printk macros: some drivers use their own macros, others use pr_foo() or v4l_foo() macros, while more modern drivers use dev_foo() macros. The best is to get rid of v4l_foo() macros, as they can be replaced by either dev_foo() or pr_foo(). Yet, such change can be disruptive, as dev_foo() cannot use KERN_CONT. So, the best is to do such change driver by driver. There are replacements for most v4l_foo() macros, but it lacks a way to enable debug messages per level. So, add such macro, in order to make the conversion easier. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Tuner core uses its own printk internal macros, instead of the standard debug ones, for no good reason. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
The dvb-usb system has its own macro to print hexa dumps (debug_dump). Such macro doesn't support messages with KERN_CONT after commit 56387331 ("Merge branch 'printk-cleanups'"). So, let's get rid of a printk() that would be assuming that this would work. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
The dprintk() macro relies on continuation lines. This is not a good practice and will break after commit 56387331 ("Merge branch 'printk-cleanups'"). So, instead of directly calling printk(), use pr_foo() macros, adding a \n leading char on each macro call. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
The dprintk() macro relies on continuation lines. This is not a good practice and will break after commit 56387331 ("Merge branch 'printk-cleanups'"). So, instead of directly calling printk(), use pr_foo() macros, adding a\n leading char on each macro call. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
The dprintk() macro relies on continuation lines. This is not a good practice and will break after commit 56387331 ("Merge branch 'printk-cleanups'"). So, instead of directly calling printk(), use pr_foo() macros, adding a\n leading char on each macro call. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
The dprintk() macro relies on continuation lines. This is not a good practice and will break after commit 56387331 ("Merge branch 'printk-cleanups'"). So, instead of directly calling printk(), use pr_foo() macros, adding a \n leading char on each macro call. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
The dprintk() macro relies on continuation lines. This is not a good practice and will break after commit 56387331 ("Merge branch 'printk-cleanups'"). So, instead of directly calling printk(), use pr_foo() macros, adding a \n leading char on each macro call. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
The dprintk() macro relies on continuation lines. This is not a good practice and will break after commit 56387331 ("Merge branch 'printk-cleanups'"). So, instead of directly calling printk(), use pr_foo() macros, adding a \n leading char on each macro call. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
The dprintk() macro relies on continuation lines. This is not a good practice and will break after commit 56387331 ("Merge branch 'printk-cleanups'"). So, instead of directly calling printk(), use pr_foo() macros, adding a \n leading char on each macro call. The frontend settings also rely on continuation lines. Change it to avoid the need of adding pr_cont() calls. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
The dprintk() macro relies on continuation lines. This is not a good practice and will break after commit 56387331 ("Merge branch 'printk-cleanups"). So, instead of directly calling printk(), use pr_foo() macros, adding a \n leading char on each macro call. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
The dprintk() macro relies on continuation lines. This is not a good practice and will break after commit 56387331 ("Merge branch 'printk-cleanups"). So, instead of directly calling printk(), use pr_foo() macros, adding a \n leading char on each macro call. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Continuation lines without KERN_CONT won't work anymore. However, the way dprintk() was defined leads to the usage of continuation lines, with should be avoided when possible. So, redefine those macros. While hre, remove some dead code at av7110.c with also relies on continuation lines. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Some continuation messages are not using KERNEL_CONT. Since commit 56387331 ("Merge branch 'printk-cleanups"), this won't work as expected anymore. So, let's add KERN_CONT to those lines. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Some continuation messages are not using KERNEL_CONT. Since commit 56387331 ("Merge branch 'printk-cleanups"), this won't work as expected anymore. So, let's add KERN_CONT to those lines. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Some continuation messages are not using KERNEL_CONT. Since commit 56387331 ("Merge branch 'printk-cleanups"), this won't work as expected anymore. So, let's add KERN_CONT to those lines. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Some continuation messages are not using KERN_CONT. Since commit 56387331 ("Merge branch 'printk-cleanups"), this won't work as expected anymore. So, let's add KERN_CONT to those lines. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
Some continuation messages are not using KERN_CONT. Since commit 56387331 ("Merge branch 'printk-cleanups"), this won't work as expected anymore. So, let's add KERN_CONT to those lines. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Mauro Carvalho Chehab authored
This driver is old, and have lots of checkpatch violations. As we're touching a lot on this driver due to the printk conversions, let's run checkpatch --fix on it, in order to solve some of those issues. Also, do a few manual adjustments: - remove the FSF address and use the usual coding style for the initial comments; - use WARN_ON() instead of BUG_ON(); - remove an unused typedef; - break a few long lines. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-