aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/media/dvb-frontends/stv6110x.c
AgeCommit message (Collapse)Author
2018-08-02media: dvb: convert tuner_info frequencies to HzMauro Carvalho Chehab
Right now, satellite tuner drivers specify frequencies in kHz, while terrestrial/cable ones specify in Hz. That's confusing for developers. However, the main problem is that universal tuners capable of handling both satellite and non-satelite delivery systems are appearing. We end by needing to hack the drivers in order to support such hybrid tuners. So, convert everything to specify tuner frequencies in Hz. Plese notice that a similar patch is also needed for frontends. Tested-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com> Acked-by: Michael Büsch <m@bues.ch> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-01-04media: replace all <spaces><tab> occurrencesMauro Carvalho Chehab
There are a lot of places where sequences of space/tabs are found. Get rid of all spaces before tabs. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-12-28media: move dvb kAPI headers to include/mediaMauro Carvalho Chehab
Except for DVB, all media kAPI headers are at include/media. Move the headers to it. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2017-12-15media: dvb-frontends: fix i2c access helpers for KASANArnd Bergmann
A typical code fragment was copied across many dvb-frontend drivers and causes large stack frames when built with with CONFIG_KASAN on gcc-5/6/7: drivers/media/dvb-frontends/cxd2841er.c:3225:1: error: the frame size of 3992 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] drivers/media/dvb-frontends/cxd2841er.c:3404:1: error: the frame size of 3136 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] drivers/media/dvb-frontends/stv0367.c:3143:1: error: the frame size of 4016 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] drivers/media/dvb-frontends/stv090x.c:3430:1: error: the frame size of 5312 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] drivers/media/dvb-frontends/stv090x.c:4248:1: error: the frame size of 4872 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] gcc-8 now solves this by consolidating the stack slots for the argument variables, but on older compilers we can get the same behavior by taking the pointer of a local variable rather than the inline function argument. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-11-18Revert "[media] dvb_frontend: merge duplicate dvb_tuner_ops.release ↵Mauro Carvalho Chehab
implementations" While this patch sounded a good idea, unfortunately, it causes bad dependencies, as drivers that would otherwise work without the DVB core will now break: ERROR: "dvb_tuner_simple_release" [drivers/media/tuners/tea5767.ko] undefined! ERROR: "dvb_tuner_simple_release" [drivers/media/tuners/tea5761.ko] undefined! ERROR: "dvb_tuner_simple_release" [drivers/media/tuners/tda827x.ko] undefined! ERROR: "dvb_tuner_simple_release" [drivers/media/tuners/tda18218.ko] undefined! ERROR: "dvb_tuner_simple_release" [drivers/media/tuners/qt1010.ko] undefined! ERROR: "dvb_tuner_simple_release" [drivers/media/tuners/mt2266.ko] undefined! ERROR: "dvb_tuner_simple_release" [drivers/media/tuners/mt20xx.ko] undefined! ERROR: "dvb_tuner_simple_release" [drivers/media/tuners/mt2060.ko] undefined! ERROR: "dvb_tuner_simple_release" [drivers/media/tuners/mc44s803.ko] undefined! ERROR: "dvb_tuner_simple_release" [drivers/media/tuners/fc0013.ko] undefined! ERROR: "dvb_tuner_simple_release" [drivers/media/tuners/fc0012.ko] undefined! ERROR: "dvb_tuner_simple_release" [drivers/media/tuners/fc0011.ko] undefined! So, we have to revert it. Note: as the argument for the release ops changed from "int" to "void", we needed to change it at the revert patch, to avoid compilation issues like: drivers/media/tuners/tea5767.c:437:23: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .release = tea5767_release, ^~~~~~~~~~~~~~~ This reverts commit 22a613e89825ea7a3984a968463cc6d425bd8856. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-11-18[media] dvb_frontend: merge duplicate dvb_tuner_ops.release implementationsMax Kellermann
Most release callback functions are identical: free the "tuner_priv" and clear it. Let's eliminate some bloat by providing this simple implementation in the dvb_frontend library. Signed-off-by: Max Kellermann <max.kellermann@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-09-19[media] dvb-frontends: constify dvb_tuner_ops structuresJulia Lawall
These structures are only used to copy into other structures, so declare them as const. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r disable optional_qualifier@ identifier i; position p; @@ static struct dvb_tuner_ops i@p = { ... }; @ok1@ identifier r.i; expression e; position p; @@ e = i@p @ok2@ identifier r.i; expression e1, e2; position p; @@ memcpy(e1, &i@p, e2) @bad@ position p != {r.p,ok1.p,ok2.p}; identifier r.i; struct dvb_tuner_ops e; @@ e@i@p @depends on !bad disable optional_qualifier@ identifier r.i; @@ static +const struct dvb_tuner_ops i = { ... }; // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-02-01[media] constify stv6110x_devctl structureJulia Lawall
The stv6110x_devctl structure is never modified, so declare it as const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.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>
2012-08-13[media] move the dvb/frontends to drivers/media/dvb-frontendsMauro Carvalho Chehab
Raise the DVB frontends one level up, as the intention is to remove the drivers/media/dvb directory. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>