- 08 Nov, 2013 16 commits
-
-
Mauro Carvalho Chehab authored
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 (64 bytes). Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
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 (64 bytes). Signed-off-by:
-
Mauro Carvalho Chehab authored
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 authored
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:149:1: warning: 'netup_write_i2c' 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 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit 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 authored
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 authored
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 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit 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:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Mauro Carvalho Chehab authored
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 authored
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 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit 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 authored
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 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit 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 authored
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 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit 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 authored
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 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit 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 authored
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 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit 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 authored
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 authored
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:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Mauro Carvalho Chehab authored
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 authored
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:
-
- 07 Nov, 2013 6 commits
-
-
Sean Young authored
Simplify the logic that calculates the carrier, and removes a 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 Signed-off-by:Sean Young <sean@mess.org> Signed-off-by:
-
Mauro Carvalho Chehab authored
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 authored
drivers/media/pci/cx18/cx18-driver.c: In function 'cx18_read_eeprom': drivers/media/pci/cx18/cx18-driver.c:357:1: warning: the frame size of 1072 bytes is larger than 1024 bytes [-Wframe-larger-than=] That happens because the routine allocates 256 bytes for an eeprom buffer, plus the size of struct i2c_client, with is big. Change the logic to dynamically allocate/deallocate space for struct i2c_client, instead of using the stack. Signed-off-by:
-
Mauro Carvalho Chehab authored
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 authored
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 authored
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] While here, make fix the CodingStyle on this function. Signed-off-by:
-
- 31 Oct, 2013 18 commits
-
-
Srinivas Kandagatla authored
This patch adds support to ST RC driver, which is basically a IR/UHF receiver and transmitter. This IP (IRB) is common across all the ST parts for settop box platforms. IRB is embedded in ST COMMS IP block. It supports both Rx & Tx functionality. This driver adds only Rx functionality via LIRC codec. Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@st.com> Acked-by:
-
Sachin Kamat authored
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by:
-
Sachin Kamat authored
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Sachin Kamat authored
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by:
-
Sachin Kamat authored
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by:
-
Sachin Kamat authored
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by:
-
Laurent Pinchart authored
The helper function is defined by a macro that is erroneously called with the compose rectangle instead of the crop rectangle. Fix it. Signed-off-by:
Sakari Ailus <sakari.ailus@iki.fi> Signed-off-by:
-
Daniel Jeong authored
Adds the driver for the LM3560, dual LED Flash The LM3560 has two 1A constant current driver for high current white LEDs. It is controlled via an I2C compatible interface(up to 400kHz). Each flash brightness, torch brightness and enable/disable can be controlled independantly, but flash timeout and operation mode are shared. Signed-off-by:
Daniel Jeong <gshark.jeong@gmail.com> Signed-off-by:
-
Antti Palosaari authored
Components are RTL2832P + R828D + MN88472. Currently support only DVB-T as there is no driver for MN88472 demod. Signed-off-by:
-
Antti Palosaari authored
RTL2832P is version of RTL2832U with extra TS interface. As for now, we support only integrated RTL2832 demod. Signed-off-by:
-
Antti Palosaari authored
Use R820T config for R828D too as those are about same tuner. Signed-off-by:
-
Antti Palosaari authored
Small changes in order to support tuner version R828D @ 16 MHz clock. There was 'vco_fine_tune' check, which seems to adjust synthesizer output divider (mixer dix / LO div / Rout) by one. R828D seems to return vco_fine_tune=1 every time and that condition causes tuning fail as output divider was increased by one. Resolve problem by skipping whole condition in case of R828D tuner. Just to mention, other tuner, R820T, seems to return 2 here. Synthesizer maximum frequency check was hard coded to check synthesizer N and thus worked correctly only for clock frequencies around 30 MHz. As whole test is quite useless in any case, I removed it totally. Signed-off-by:
-
Russell King - ARM Linux authored
v3.12-rc fails to build with this error: drivers/media/i2c/ths8200.c:49:2: error: unknown field 'bt' specified in initializer drivers/media/i2c/ths8200.c:50:3: error: field name not in record or union initializer drivers/media/i2c/ths8200.c:50:3: error: (near initialization for 'ths8200_timings_cap.reserved') drivers/media/i2c/ths8200.c:51:3: error: field name not in record or union initializer drivers/media/i2c/ths8200.c:51:3: error: (near initialization for 'ths8200_timings_cap.reserved') ... with gcc 4.5.4. This error was not detected in builds prior to v3.12-rc. This patch fixes this. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Cc: stable@vger.kernel.org # For kernel v3.12 Signed-off-by:
-
Jean-Francois Thibert authored
This patch adds support for the UB435-Q V2. You might need to use the device once with the Windows driver provided by KWorld in order to permanently reprogram the device descriptors. Thanks to Jarod Wilson for the initial attempt at adding support for this device. [m.chehab@samsung.com: Fixed Whitespace mangling, Coding Style and improved the error handling at DVB attach] Signed-off-by:
Jean-Francois Thibert <jfthibert@google.com> Reviewed-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
Randy Dunlap authored
Fix build error when VIDEOBUF2_CORE=m and USB_MSI3101=y. drivers/built-in.o: In function `msi3101_buf_queue': sdr-msi3101.c:(.text+0x1298d6): undefined reference to `vb2_buffer_done' drivers/built-in.o: In function `msi3101_cleanup_queued_bufs': sdr-msi3101.c:(.text+0x1299c7): undefined reference to `vb2_buffer_done' drivers/built-in.o: In function `msi3101_isoc_handler': sdr-msi3101.c:(.text+0x12a08d): undefined reference to `vb2_plane_vaddr' sdr-msi3101.c:(.text+0x12a0b9): undefined reference to `vb2_buffer_done' drivers/built-in.o: In function `msi3101_probe': sdr-msi3101.c:(.text+0x12a1c5): undefined reference to `vb2_vmalloc_memops' sdr-msi3101.c:(.text+0x12a1d7): undefined reference to `vb2_queue_init' drivers/built-in.o:(.rodata+0x34cf0): undefined reference to `vb2_ioctl_reqbufs' drivers/built-in.o:(.rodata+0x34cf4): undefined reference to `vb2_ioctl_querybuf' drivers/built-in.o:(.rodata+0x34cf8): undefined reference to `vb2_ioctl_qbuf' drivers/built-in.o:(.rodata+0x34d00): undefined reference to `vb2_ioctl_dqbuf' drivers/built-in.o:(.rodata+0x34d04): undefined reference to `vb2_ioctl_create_bufs' drivers/built-in.o:(.rodata+0x34d08): undefined reference to `vb2_ioctl_prepare_buf' drivers/built-in.o:(.rodata+0x34d18): undefined reference to `vb2_ioctl_streamon' drivers/built-in.o:(.rodata+0x34d1c): undefined reference to `vb2_ioctl_streamoff' drivers/built-in.o:(.rodata+0x35580): undefined reference to `vb2_fop_read' drivers/built-in.o:(.rodata+0x35588): undefined reference to `vb2_fop_poll' drivers/built-in.o:(.rodata+0x35598): undefined reference to `vb2_fop_mmap' drivers/built-in.o:(.rodata+0x355a0): undefined reference to `vb2_fop_release' drivers/built-in.o:(.data+0x23b40): undefined reference to `vb2_ops_wait_prepare' drivers/built-in.o:(.data+0x23b44): undefined reference to `vb2_ops_wait_finish' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Jingoo Han authored
Casting the return value which is a void pointer is redundant. The conversion from void pointer to any other pointer type is guaranteed by the C programming language. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Jingoo Han authored
Casting the return value which is a void pointer is redundant. The conversion from void pointer to any other pointer type is guaranteed by the C programming language. Signed-off-by:
-
Alexandru Juncu authored
i2c_adap is a field of a struct and will always be allocated so its address will never be null. Suggested by coccinelle, manually verified. Signed-off-by:
Alexandru Juncu <alexj@rosedu.org> Signed-off-by:
-
