kernel/linux.git/drivers/media/dvb-frontends, branch v4.19.16

media: dvb-pll: don't re-validate tuner frequencies

2018-12-13T08:16:17+00:00

commit 3420f65cbbd0555049bd02394bed33a0ef74d860 upstream. The dvb_frontend core already checks for the frequencies. No need for any additional check inside the driver. It is part of the fixes for the following bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1116374 Fixes: a3f90c75b833 ("media: dvb: convert tuner_info frequencies to Hz") Reported-by: Stakanov Schufter Reported-by: Takashi Iwai Cc: stable@vger.kernel.org # For 4.19 Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: dvb-pll: fix tuner frequency ranges

2018-12-13T08:16:17+00:00

commit 3d8e450f517cdb33da77827ec75929354753e9c0 upstream. Tuners should report frequencies in Hz. That works fine on most drivers, but, in the case of dvb-pll, some settings are for satellite tuners, while others are for terrestrial/cable ones. The code was trying to solve it at probing time, but that doesn't work, as, when _attach is called, the delivery system may be wrong. Fix it by ensuring that all frequencies are in Hz at the per-tuner max/min values. While here, add a debug message, as this would help to debug any issues there. It partially fixes the following bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1116374 Fixes: a3f90c75b833 ("media: dvb: convert tuner_info frequencies to Hz") Reported-by: Stakanov Schufter Reported-by: Takashi Iwai Cc: stable@vger.kernel.org # For 4.19 Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

Merge branch 'i2c/for-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

2018-08-22T00:40:46+00:00

Pull i2c updates from Wolfram Sang: - the core has now a lockless variant of i2c_smbus_xfer. Some open coded versions of this got removed in drivers. This also enables proper SCCB support in regmap. - locking got a more precise naming. i2c_{un}lock_adapter() had to go, and we know use i2c_lock_bus() consistently with flags like I2C_LOCK_ROOT_ADAPTER and I2C_LOCK_SEGMENT to avoid ambiguity. - the gpio fault injector got a new delicate testcase - the bus recovery procedure got fixed to handle the new testcase correctly - a new quirk flag for controllers not able to handle zero length messages together with driver updates to use it - new drivers: FSI bus attached I2C masters, GENI I2C controller, Owl family S900 - and a good set of driver improvements and bugfixes * 'i2c/for-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (77 commits) i2c: rcar: implement STOP and REP_START according to docs i2c: rcar: refactor private flags i2c: core: ACPI: Make acpi_gsb_i2c_read_bytes() check i2c_transfer return value i2c: core: ACPI: Properly set status byte to 0 for multi-byte writes dt-bindings: i2c: rcar: Add r8a774a1 support dt-bindings: i2c: sh_mobile: Add r8a774a1 support i2c: imx: Simplify stopped state tracking i2c: imx: Fix race condition in dma read i2c: pasemi: remove hardcoded bus numbers on smbus i2c: designware: Add SPDX license tag i2c: designware: Convert to use struct i2c_timings i2c: core: Parse SDA hold time from firmware i2c: designware-pcidrv: Mark expected switch fall-through i2c: amd8111: Mark expected switch fall-through i2c: sh_mobile: use core to detect 'no zero length read' quirk i2c: xlr: use core to detect 'no zero length' quirk i2c: rcar: use core to detect 'no zero length' quirk i2c: stu300: use core to detect 'no zero length' quirk i2c: pmcmsp: use core to detect 'no zero length' quirk i2c: mxs: use core to detect 'no zero length' quirk ...

media: drxj: get rid of uneeded casts

2018-08-08T14:57:14+00:00

Instead of doing casts, use %zd to print sizes, in order to make smatch happier: drivers/media/dvb-frontends/drx39xyj/drxj.c:11814 drx_ctrl_u_code() warn: argument 4 to %u specifier is cast from pointer drivers/media/dvb-frontends/drx39xyj/drxj.c:11845 drx_ctrl_u_code() warn: argument 3 to %u specifier is cast from pointer drivers/media/dvb-frontends/drx39xyj/drxj.c:11869 drx_ctrl_u_code() warn: argument 3 to %u specifier is cast from pointer drivers/media/dvb-frontends/drx39xyj/drxj.c:11878 drx_ctrl_u_code() warn: argument 3 to %u specifier is cast from pointer Signed-off-by: Mauro Carvalho Chehab

media: cleanup fall-through comments

2018-08-08T14:57:14+00:00

As Ian pointed out, adding a '-' to the fallthrough seems to meet the regex requirements at level 3 of the warning, at least when the comment fits into a single line. So, replace by a single line the comments that were broken into multiple lines just to make gcc -Wimplicit-fallthrough=3 happy. Suggested-by: Ian Arkver Signed-off-by: Mauro Carvalho Chehab

media: dvb-frontends: rtl2832_sdr: Replace GFP_ATOMIC with GFP_KERNEL

2018-08-02T23:10:56+00:00

rtl2832_sdr_submit_urbs(), rtl2832_sdr_alloc_stream_bufs(), and rtl2832_sdr_alloc_urbs() are never called in atomic context. They call usb_submit_urb(), usb_alloc_coherent() and usb_alloc_urb() with GFP_ATOMIC, which is not necessary. GFP_ATOMIC can be replaced with GFP_KERNEL. This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai Signed-off-by: Mauro Carvalho Chehab

media: dvb-frontends: add Socionext MN88443x ISDB-S/T demodulator driver

2018-08-02T22:54:03+00:00

This patch adds a frontend driver for the Socionext/Panasonic MN884434 and MN884433 ISDB-S/T demodulators. The maximum and minimum frequency of MN88443x comes from ISDB-S and ISDB-T so frequency range is the following: - ISDB-S (BS/CS110 IF frequency, Local freq 10.678GHz) - Min: BS-1: 1032MHz - Max: ND24: 2070MHz - ISDB-T - Min: ch13: 470MHz - Max: ch62: 770MHz Signed-off-by: Katsuhiro Suzuki Signed-off-by: Mauro Carvalho Chehab

media: helene: add I2C device probe function

2018-08-02T22:53:42+00:00

This patch adds I2C probe function to use dvb_module_probe() with this driver. And also support multiple delivery systems at the same device. Signed-off-by: Katsuhiro Suzuki Signed-off-by: Mauro Carvalho Chehab

media: dvb: represent min/max/step/tolerance freqs in Hz

2018-08-02T22:10:48+00:00

Right now, satellite frontend drivers specify frequencies in kHz, while terrestrial/cable ones specify in Hz. That's confusing for developers. However, the main problem is that universal frontends 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 frontends. So, convert everything to specify frontend frequencies in Hz. Tested-by: Katsuhiro Suzuki Signed-off-by: Mauro Carvalho Chehab

media: dvb: convert tuner_info frequencies to Hz

2018-08-02T20:14:50+00:00

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 Acked-by: Michael Büsch Signed-off-by: Mauro Carvalho Chehab