kernel/linux.git/drivers/media/rc, branch v5.15.7

media: ir_toy: assignment to be16 should be of correct type

2021-11-18T18:16:34+00:00

[ Upstream commit febfe985fc2ea052a363f6525ff624b8efd5273c ] commit f0c15b360fb6 ("media: ir_toy: prevent device from hanging during transmit") removed a cpu_to_be16() cast, which causes a sparse warning. Fixes: f0c15b360fb6 ("media: ir_toy: prevent device from hanging during transmit") Reported-by: Hans Verkuil Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: mceusb: return without resubmitting URB in case of -EPROTO error.

2021-11-18T18:16:13+00:00

[ Upstream commit 476db72e521983ecb847e4013b263072bb1110fc ] Syzkaller reported a warning called "rcu detected stall in dummy_timer". The error seems to be an error in mceusb_dev_recv(). In the case of -EPROTO error, the routine immediately resubmits the URB. Instead it should return without resubmitting URB. Reported-by: syzbot+4d3749e9612c2cfab956@syzkaller.appspotmail.com Signed-off-by: Rajat Asthana Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin

media: ite-cir: IR receiver stop working after receive overflow

2021-11-18T18:15:53+00:00

commit fdc881783099c6343921ff017450831c8766d12a upstream. On an Intel NUC6iSYK, no IR is reported after a receive overflow. When a receiver overflow occurs, this condition is only cleared by reading the fifo. Make sure we read anything in the fifo. Fixes: 28c7afb07ccf ("media: ite-cir: check for receive overflow") Suggested-by: Bryan Pass Tested-by: Bryan Pass Cc: stable@vger.kernel.org> Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

media: ir_toy: prevent device from hanging during transmit

2021-09-19T09:19:37+00:00

If the IR Toy is receiving IR while a transmit is done, it may end up hanging. We can prevent this from happening by re-entering sample mode just before issuing the transmit command. Link: https://github.com/bengtmartensson/HarcHardware/discussions/25 Cc: stable@vger.kernel.org Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab

Merge tag 'media/v5.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

2021-09-01T17:34:52+00:00

Pull media updates from Mauro Carvalho Chehab: - new sensor drivers: imx335, imx412, ov9282 - new IR transmitter driver: meson-ir-tx - handro driver gained support for H.264 for Rockchip VDPU2 - imx gained support for i.MX8MQ - ti-vpe has gained support for other SoC variants - lots of cleanups, fixes, board additions and doc improvements * tag 'media/v5.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (195 commits) media: venus: venc: add support for V4L2_CID_MPEG_VIDEO_H264_8X8_TRANSFORM control media: venus: venc: Add support for intra-refresh period media: v4l2-ctrls: Add intra-refresh period control media: docs: ext-ctrls-codec: Document cyclic intra-refresh zero control value media: venus: helper: do not set constrained parameters for UBWC media: venus: venc: Fix potential null pointer dereference on pointer fmt media: venus: hfi: fix return value check in sys_get_prop_image_version() media: tegra-cec: Handle errors of clk_prepare_enable() media: cec-pin: rename timer overrun variables media: TDA1997x: report -ENOLINK after disconnecting HDMI source media: TDA1997x: fix tda1997x_query_dv_timings() return value media: Fix cosmetic error in TDA1997x driver media: v4l2-dv-timings.c: fix wrong condition in two for-loops media: imx: add a driver for i.MX8MQ mipi csi rx phy and controller media: dt-bindings: media: document the nxp,imx8mq-mipi-csi2 receiver phy and controller media: imx: imx7_mipi_csis: convert some switch cases to the default media: imx: imx7-media-csi: Fix buffer return upon stream start failure media: imx: imx7-media-csi: Don't set PIXEL_BIT in CSICR1 media: imx: imx7-media-csi: Set TWO_8BIT_SENSOR for >= 10-bit formats media: dt-bindings: media: nxp,imx7-csi: Add i.MX8MM support ...

bpf: Allow to specify user-provided bpf_cookie for BPF perf links

2021-08-16T22:45:07+00:00

Add ability for users to specify custom u64 value (bpf_cookie) when creating BPF link for perf_event-backed BPF programs (kprobe/uprobe, perf_event, tracepoints). This is useful for cases when the same BPF program is used for attaching and processing invocation of different tracepoints/kprobes/uprobes in a generic fashion, but such that each invocation is distinguished from each other (e.g., BPF program can look up additional information associated with a specific kernel function without having to rely on function IP lookups). This enables new use cases to be implemented simply and efficiently that previously were possible only through code generation (and thus multiple instances of almost identical BPF program) or compilation at runtime (BCC-style) on target hosts (even more expensive resource-wise). For uprobes it is not even possible in some cases to know function IP before hand (e.g., when attaching to shared library without PID filtering, in which case base load address is not known for a library). This is done by storing u64 bpf_cookie in struct bpf_prog_array_item, corresponding to each attached and run BPF program. Given cgroup BPF programs already use two 8-byte pointers for their needs and cgroup BPF programs don't have (yet?) support for bpf_cookie, reuse that space through union of cgroup_storage and new bpf_cookie field. Make it available to kprobe/tracepoint BPF programs through bpf_trace_run_ctx. This is set by BPF_PROG_RUN_ARRAY, used by kprobe/uprobe/tracepoint BPF program execution code, which luckily is now also split from BPF_PROG_RUN_ARRAY_CG. This run context will be utilized by a new BPF helper giving access to this user-provided cookie value from inside a BPF program. Generic perf_event BPF programs will access this value from perf_event itself through passed in BPF program context. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/bpf/20210815070609.987780-6-andrii@kernel.org

bpf: Refactor BPF_PROG_RUN into a function

2021-08-16T22:45:07+00:00

Turn BPF_PROG_RUN into a proper always inlined function. No functional and performance changes are intended, but it makes it much easier to understand what's going on with how BPF programs are actually get executed. It's more obvious what types and callbacks are expected. Also extra () around input parameters can be dropped, as well as `__` variable prefixes intended to avoid naming collisions, which makes the code simpler to read and write. This refactoring also highlighted one extra issue. BPF_PROG_RUN is both a macro and an enum value (BPF_PROG_RUN == BPF_PROG_TEST_RUN). Turning BPF_PROG_RUN into a function causes naming conflict compilation error. So rename BPF_PROG_RUN into lower-case bpf_prog_run(), similar to bpf_prog_run_xdp(), bpf_prog_run_pin_on_cpu(), etc. All existing callers of BPF_PROG_RUN, the macro, are switched to bpf_prog_run() explicitly. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20210815070609.987780-2-andrii@kernel.org

media: rc: introduce Meson IR TX driver

2021-08-04T12:43:49+00:00

This patch adds the driver for Amlogic Meson IR transmitter. Some Amlogic SoCs such as A311D and T950D4 have IR transmitter (also called blaster) controller onboard. It is capable of sending IR signals with arbitrary carrier frequency and duty cycle. The driver supports 2 modulation clock sources: - xtal3 clock (xtal divided by 3) - 1us clock Signed-off-by: Viktor Prutyanov Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab

media: rc: rename s_learning_mode() to s_wideband_receiver()

2021-07-22T06:21:53+00:00

The s_learning_mode() function is called in response to the ioctl LIRC_SET_WIDEBAND_RECEIVER, so rename it to s_wideband_receiver(). Learning mode is when both the wideband receiver is turned on and carrier reports are enabled. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab

media: rc-loopback: max_timeout of UINT_MAX does not work

2021-07-22T06:21:03+00:00

Any timeout larger than LIRC_VALUE_MASK cannot work for the lirc uapi. LIRC_VALUE_MASK is about 16 seconds which is more than enough. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab