- 15 Dec, 2017 2 commits
-
-
Arnd Bergmann authored
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>
-
Arnd Bergmann authored
With CONFIG_KASAN, we get an overly long stack frame due to inlining the register access functions: drivers/media/tuners/r820t.c: In function 'generic_set_freq.isra.7': drivers/media/tuners/r820t.c:1334:1: error: the frame size of 2880 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] This is caused by a gcc bug that has now been fixed in gcc-8. To work around the problem, we can pass the register data through a local variable that older gcc versions can optimize out as well. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715Signed-off-by:
-
- 14 Dec, 2017 38 commits
-
-
Hans Verkuil authored
Rename soc_camera to pxa_camera as this has no longer anything to do with the old soc_camera driver/framework. It's confusing when grepping on soc_camera. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Hans Verkuil authored
The description of V4L2_DV_FL_HALF_LINE mixed up frontporch with backporch. It's the backporch that has different sizes for interlaced formats, the frontporch remains constant. Signed-off-by:
-
Daniel Scheller authored
Prefix dev_*() I2C address prints with 0x, change CXD2099 to CXD2099AR, change the MODULE_DESCRIPTION to a proper one and have a better (and shorter) description for the buffermode modparam. Signed-off-by:
Daniel Scheller <d.scheller@gmx.net> Signed-off-by:
Jasmin Jessich <jasmin@anw.at> Signed-off-by:
-
Daniel Scheller authored
Debug messages should go to KERN_DEBUG, thus change the slot_shutdown() notice from dev_info() to dev_dbg(). Signed-off-by:
-
Daniel Scheller authored
Fix up all remaining cosmetic issues as reported by checkpatch.pl. Signed-off-by:
-
Ron Economos authored
On faster CPUs a delay is required after the resume command and the restart command. Without the delay, the restart command often returns -EREMOTEIO and the Si2168 does not restart. Note that this patch fixes the same issue as https://patchwork.linuxtv.org/patch/44304/, but I believe my udelay() fix addresses the actual problem. Signed-off-by:
Ron Economos <w6rz@comcast.net> Signed-off-by:
-
Daniel Scheller authored
While the failure handling in dvb_input_attach() has been improved lately so any tuner failure won't result in demod driver modules with a usecount > 0 anymore (thus requiring rmmod -f), there's still an issue with stv090x and stv0910 based tuner modules, in that LNB driver attach failures leave an attached demod frontend driver behind which have a usecount of > 0 in this failure case, due to them not being detached/ released. Fix this by detaching the demod frontends if the LNB driver fails. Richard tested and verified the changes with STV0910 hardware, thus adding his Tested-by. Signed-off-by:
Richard Scobie <rascobie@slingshot.co.nz> Signed-off-by:
-
Arnd Bergmann authored
With CONFIG_KASAN enabled, we get a relatively large stack frame in one function drivers/media/tuners/tda8290.c: In function 'tda8290_set_params': drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 1520 bytes is larger than 1024 bytes [-Wframe-larger-than=] With CONFIG_KASAN_EXTRA this goes up to drivers/media/tuners/tda8290.c: In function 'tda8290_set_params': drivers/media/tuners/tda8290.c:310:1: error: the frame size of 3200 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] We can significantly reduce this by marking local arrays as 'static const', and this should result in better compiled code for everyone. [mchehab@s-opensource.com: fix a trivial merge conflict] Signed-off-by:
Michael Ira Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Mauro Carvalho Chehab authored
This is part of the uAPI. Add it to the documentation again, and fix cross-references. Signed-off-by:
Sean Young <sean@mess.org>
-
Sean Young authored
CEC autorepeat is different than other protocols. Autorepeat is triggered by the first repeated user control pressed CEC message, rather than a fixed REP_DELAY. This change also does away with the KEY_UP event directly after the first KEY_DOWN event, which was used to stop autorepeat from starting. See commit a9a249a2 ("media: cec: fix remote control passthrough") for the original change. Acked-by:
-
Sean Young authored
Another device with the 0xffdc device id, this one with 0x30 in the config byte. Its an iMON VFD + iMON IR (it does not understand rc6). Signed-off-by:
-
Arvind Yadav authored
The pnp_irq() function returns -1 if an error occurs. pnp_irq() error checking for zero is not correct. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
-
Chunyan Zhang authored
This patch changes the 32-bit time type (timeval) to the 64-bit one (ktime_t), since 32-bit time types will break in the year 2038. I use ktime_t instead of all uses of timeval in imon.c This patch also changes do_gettimeofday() to ktime_get() accordingly, since ktime_get returns a ktime_t, but do_gettimeofday returns a struct timeval, and the other reason is that ktime_get() uses the monotonic clock. Signed-off-by:
Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by:
-
Sean Young authored
Once rc_unregister_device() has been called, no driver function should be called. This prevents some nasty race conditions with an ioctl calls driver functions when the driver specific data has been freed. Signed-off-by:
-
Sean Young authored
This makes it possible for lircd to read from a lirc chardev, and not keep it busy. Note that this changes the default for timeout reports to on. lircd already enables timeout reports when it opens a lirc device, leaving them on until the next reboot. Signed-off-by:
-
Sean Young authored
This removes the need for include/media/lirc.h, which just includes the uapi file. Signed-off-by:
-
Sean Young authored
Since removing the lirc kapi, ir-lirc-codec.c only contains lirc fops so the file name is no longer correct. By moving its content into lirc_dev.c the ugly extern struct lirc_fops is not longer needed, and everything lirc related is in one file. Signed-off-by:
-
Sean Young authored
If you try to store u64 in a kfifo (or a struct with u64 members), then the buf member of __STRUCT_KFIFO_PTR will cause 4 bytes padding due to alignment (note that struct __kfifo is 20 bytes on 32 bit). That in turn causes the __is_kfifo_ptr() to fail, which is caught by kfifo_alloc(), which now returns EINVAL. So, ensure that __is_kfifo_ptr() compares to the right structure. Signed-off-by:
Stefani Seibold <stefani@seibold.net> Signed-off-by:
-
Sean Young authored
Now that the lirc interface supports scancodes, RC scancode devices can also have a lirc device. The only receiving feature they will have enabled is LIRC_CAN_REC_SCANCODE. Note that CEC devices have no lirc device, since they can be controlled from their /dev/cecN chardev. Signed-off-by:
-
Sean Young authored
Lirc supports a new mode which requires documentation. Signed-off-by:
-
Sean Young authored
The lirc device should get lirc repeats whether there is a keymap match or not. Signed-off-by:
-
Sean Young authored
This implements LIRC_MODE_SCANCODE reading from the lirc device. The scancode can be read from the input device too, but with this interface you get the rc protocol, keycode, toggle and repeat status in addition to just the scancode. int main() { int fd, mode, rc; fd = open("/dev/lirc0", O_RDWR); mode = LIRC_MODE_SCANCODE; if (ioctl(fd, LIRC_SET_REC_MODE, &mode)) { // kernel too old or lirc does not support transmit } struct lirc_scancode scancode; while (read(fd, &scancode, sizeof(scancode)) == sizeof(scancode)) { printf("protocol:%d scancode:0x%x toggle:%d repeat:%d\n", scancode.rc_proto, scancode.scancode, !!(scancode.flags & LIRC_SCANCODE_FLAG_TOGGLE), !!(scancode.flags & LIRC_SCANCODE_FLAG_REPEAT)); } close(fd); } Signed-off-by: -
Sean Young authored
rc-core has replaced the lirc kapi many years ago, and now with the last driver ported to rc-core, we can finally remove it. Note this has no effect on userspace. All future IR drivers should use the rc-core api. Signed-off-by:
-
Sean Young authored
This is a duplicate of rcdev->driver_name. Signed-off-by:
-
Sean Young authored
Replace the generic kernel lirc api with ones which use rc-core, further reducing the lirc_dev members. Signed-off-by:
-
Sean Young authored
If a lirc chardev is held open after a device is unplugged, rc_close() will be called after rc_unregister_device(). The driver is not expecting any calls at this point, and the iguanair driver causes an oops in this scenario. rc_open() can be called when the device is removed too, by calling open on the chardev whilst the device is being removed. Signed-off-by:
-
Sean Young authored
This is done to further remove the lirc kernel api. Ensure that every fops checks for this. Signed-off-by:
-
Sean Young authored
Since the only mode lirc devices can handle is raw IR, handle this in a plain kfifo. Remove lirc_buffer since this is no longer needed. Signed-off-by:
-
Sean Young authored
Calculate lirc features when necessary, and add LIRC_{S,G}ET_REC_MODE cases to ir_lirc_ioctl. This makes lirc_dev_fop_ioctl() unnecessary since all cases are already handled by ir_lirc_ioctl(). Signed-off-by: -
Sean Young authored
For some IR protocols, some scancode values not valid, i.e. they're part of a different protocol variant. Signed-off-by:
-
Sean Young authored
Ensure we reject an attempt to transmit invalid scancodes. Signed-off-by:
-
Sean Young authored
The lirc user interface exists as a raw decoder, which does not make much sense for transmit-only devices. In addition, we want to have lirc char devices for devices which do not use raw IR, i.e. scancode only devices. Note that rc-code, lirc_dev, ir-lirc-codec are now calling functions of each other, so they've been merged into one module rc-core to avoid circular dependencies. Since ir-lirc-codec no longer exists as separate codec module, there is no need for RC_DRIVER_IR_RAW_TX type drivers to call ir_raw_event_register(). Signed-off-by:
-
Sean Young authored
When sending scancodes, load the encoder if we need it. Signed-off-by:
-
Sean Young authored
If the lirc device supports it, set the carrier for the protocol. Signed-off-by:
-
Sean Young authored
This introduces a new lirc mode: scancode. Any device which can send raw IR can now also send scancodes. int main() { int mode, fd = open("/dev/lirc0", O_RDWR); mode = LIRC_MODE_SCANCODE; if (ioctl(fd, LIRC_SET_SEND_MODE, &mode)) { // kernel too old or lirc does not support transmit } struct lirc_scancode scancode = { .scancode = 0x1e3d, .rc_proto = RC_PROTO_RC5, }; write(fd, &scancode, sizeof(scancode)); close(fd); } The other fields of lirc_scancode must be set to 0. Note that toggle (rc5, rc6) and repeats (nec) are not implemented. Nor is there a method for holding down a key for a period. Signed-off-by: -
Sean Young authored
LIRCCODE is a lirc mode where a driver produces driver-dependent codes for receive and transmit. No driver uses this any more. The LIRC_GET_LENGTH ioctl was used for this mode only. Signed-off-by:
-
Sean Young authored
Now that lirc is no longer in the staging area, remove the entry. Signed-off-by:
-
Sean Young authored
The ir-kbd-i2c driver behaves like the lirc_zilog driver, except it can send raw IR and receives scancodes rather than lirccodes. The lirc_zilog driver only polls if the lirc chardev is opened; similarly the ir-kbd-i2c driver only polls if the corresponding input device is opened, or the lirc device. Polling is disabled during IR transmission through the mutex. The polling period is 402ms in the ir-kdb-i2c driver, and 260ms in the lirc_zilog driver. Signed-off-by:
-
