summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-11-08[media] dvb-frontends: Don't use dynamic static allocationMauro Carvalho Chehab
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 <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] dvb-frontends: Don't use dynamic static allocationMauro Carvalho Chehab
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 <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] s5h1420: Don't use dynamic static allocationMauro Carvalho Chehab
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.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] uvc/lirc_serial: Fix some warnings on parisc archMauro Carvalho Chehab
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.chehab@samsung.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] rc: Fir warnings on m68k archMauro Carvalho Chehab
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.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] radio-si470x-i2c: fix a warning on ia64Mauro Carvalho Chehab
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.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08metag: off by one in setup_bootmem_node()Dan Carpenter
If "nid == MAX_NUMNODES" then we write beyond the end of the node_data[] array. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: James Hogan <james.hogan@imgtec.com>
2013-11-08Merge remote-tracking branch 'asoc/topic/wm8996' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/wm8962' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/wm8400' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/wm0010' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/warn' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/twl6040' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/twl4030' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/tpa6130a2' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/tlv320aic3x' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/tlv320aic32x4' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/tlv320aic26' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/tlv320aic23' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/tegra' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/tas5086' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/spear' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/sn95031' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/simple' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/si476x' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/samsung' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/rt5640' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/rcar' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/pxa' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/pcm1792a' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/pcm1681' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/mxs' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/ml26124' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/mc13783' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/max9850' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/max98095' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/max98088' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/kirkwood' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/fsl' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/ep93xx' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/doc' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/devm' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/davinci' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/cs42l73' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/cs42l52' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/cs4271' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/cq93vc' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/core' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/component' into asoc-nextMark Brown
2013-11-08Merge remote-tracking branch 'asoc/topic/bclk' into asoc-nextMark Brown