- 05 Oct, 2019 40 commits
-
-
Shengjiu Wang authored
[ Upstream commit 696d0522 ] The test case is arecord -Dhw:0 -d 10 -f S16_LE -r 48000 -c 2 temp.wav & aplay -Dhw:0 -d 30 -f S16_LE -r 48000 -c 2 test.wav There will be error after end of arecord: aplay: pcm_write:2051: write error: Input/output error Capture and Playback work in parallel in master mode, one substream stops, the other substream is impacted, the reason is that clock is disabled wrongly. The clock's reference count is not increased when second substream starts, the hw_param() function returns in the beginning because first substream is enabled, then in end of first substream, the hw_free() disables the clock. This patch is to move the clock enablement to the place before checking of the device enablement in hw_param(). Signed-off-by:
Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1567012817-12625-1-git-send-email-shengjiu.wang@nxp.comSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Thomas Gleixner authored
[ Upstream commit 990784b5 ] When PTI is disabled at boot time either because the CPU is not affected or PTI has been disabled on the command line, the boot code still calls into pti_finalize() which then unconditionally invokes: pti_clone_entry_text() pti_clone_kernel_text() pti_clone_kernel_text() was called unconditionally before the 32bit support was added and 32bit added the call to pti_clone_entry_text(). The call has no side effects as cloning the page tables into the available second one, which was allocated for PTI does not create damage. But it does not make sense either and in case that this functionality would be extended later this might actually lead to hard to diagnose issues. Neither function should be called when PTI is runtime disabled. Make the invocation conditional. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Dave Hansen <dave.hansen@linux.intel.com> Acked-by:
Ingo Molnar <mingo@kernel.org> Acked-by:
Song Liu <songliubraving@fb.com> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20190828143124.063353972@linutronix.deSigned-off-by:
-
Mark Rutland authored
[ Upstream commit f32c7a8e ] While the MMUs is disabled, I-cache speculation can result in instructions being fetched from the PoC. During boot we may patch instructions (e.g. for alternatives and jump labels), and these may be dirty at the PoU (and stale at the PoC). Thus, while the MMU is disabled in the KPTI pagetable fixup code we may load stale instructions into the I-cache, potentially leading to subsequent crashes when executing regions of code which have been modified at runtime. Similarly to commit: 8ec41987 ("arm64: mm: ensure patched kernel text is fetched from PoU") ... we can invalidate the I-cache after enabling the MMU to prevent such issues. The KPTI pagetable fixup code itself should be clean to the PoC per the boot protocol, so no maintenance is required for this code. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by:
James Morse <james.morse@arm.com> Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Neil Horman authored
[ Upstream commit 743dac49 ] On x86, CPUs are limited in the number of interrupts they can have affined to them as they only support 256 interrupt vectors per CPU. 32 vectors are reserved for the CPU and the kernel reserves another 22 for internal purposes. That leaves 202 vectors for assignement to devices. When an interrupt is set up or the affinity is changed by the kernel or the administrator, the vector assignment code attempts to honor the requested affinity mask. If the vector space on the CPUs in that affinity mask is exhausted the code falls back to a wider set of CPUs and assigns a vector on a CPU outside of the requested affinity mask silently. While the effective affinity is reflected in the corresponding /proc/irq/$N/effective_affinity* files the silent breakage of the requested affinity can lead to unexpected behaviour for administrators. Add a pr_warn() when this happens so that adminstrators get at least informed about it in the syslog. [ tglx: Massaged changelog and made the pr_warn() more informative ] Reported-by: djuran@redhat.com Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Douglas RAILLARD authored
[ Upstream commit 77c84dd1 ] Fast switching path only emits an event for the CPU of interest, whereas the regular path emits an event for all the CPUs that had their frequency changed, i.e. all the CPUs sharing the same policy. With the current behavior, looking at cpu_frequency event for a given CPU that is using the fast switching path will not give the correct frequency signal. Signed-off-by:
Douglas RAILLARD <douglas.raillard@arm.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Al Stone authored
[ Upstream commit 4c4cdc4c ] According to the ACPI 6.3 specification, the _PSD method is optional when using CPPC. The underlying assumption is that each CPU can change frequency independently from all other CPUs; _PSD is provided to tell the OS that some processors can NOT do that. However, the acpi_get_psd() function returns ENODEV if there is no _PSD method present, or an ACPI error status if an error occurs when evaluating _PSD, if present. This makes _PSD mandatory when using CPPC, in violation of the specification, and only on Linux. This has forced some firmware writers to provide a dummy _PSD, even though it is irrelevant, but only because Linux requires it; other OSPMs follow the spec. We really do not want to have OS specific ACPI tables, though. So, correct acpi_get_psd() so that it does not return an error if there is no _PSD method present, but does return a failure when the method can not be executed properly. This allows _PSD to be optional as it should be. Signed-off-by:
Al Stone <ahs3@redhat.com> Signed-off-by:
-
Katsuhiro Suzuki authored
[ Upstream commit f972d02f ] This patch fix setting table of Headphone mixer volume. Current code uses 4 ... 7 values but these values are prohibited. Correct settings are the following: 0000 -12dB 0001 -10.5dB 0010 -9dB 0011 -7.5dB 0100 -6dB 1000 -4.5dB 1001 -3dB 1010 -1.5dB 1011 0dB Signed-off-by:
Katsuhiro Suzuki <katsuhiro@katsuster.net> Reviewed-by:
Daniel Drake <drake@endlessm.com> Link: https://lore.kernel.org/r/20190826153900.25969-1-katsuhiro@katsuster.netSigned-off-by:
-
Mauro Carvalho Chehab authored
[ Upstream commit 093347ab ] As pointed by cppcheck: [drivers/media/i2c/ov9650.c:706]: (error) Shifting by a negative value is undefined behaviour [drivers/media/i2c/ov9650.c:707]: (error) Shifting by a negative value is undefined behaviour [drivers/media/i2c/ov9650.c:721]: (error) Shifting by a negative value is undefined behaviour Prevent mangling with gains with invalid values. As pointed by Sylvester, this should never happen in practice, as min value of V4L2_CID_GAIN control is 16 (gain is always >= 16 and m is always >= 0), but it is too hard for a static analyzer to get this, as the logic with validates control min/max is elsewhere inside V4L2 core. Reviewed-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Benjamin Peterson authored
[ Upstream commit b92675f4 ] While tracing a program that calls isatty(3), I noticed that strace reported TCGETS for the request argument of the underlying ioctl(2) syscall while perf trace reported TCSETS. strace is corrrect. The bug in perf was due to the tty ioctl beauty table starting at 0x5400 rather than 0x5401. Committer testing: Using augmented_raw_syscalls.o and settings to make 'perf trace' use strace formatting, i.e. with this in ~/.perfconfig # cat ~/.perfconfig [trace] add_events = /home/acme/git/linux/tools/perf/examples/bpf/augmented_raw_syscalls.c show_zeros = yes show_duration = no no_inherit = yes show_timestamp = no show_arg_names = no args_alignment = 40 show_prefix = yes # strace -e ioctl stty > /dev/null ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, TIOCGWINSZ, 0x7fff8a9b0860) = -1 ENOTTY (Inappropriate ioctl for device) ioctl(1, TCGETS, 0x7fff8a9b0540) = -1 ENOTTY (Inappropriate ioctl for device) +++ exited with 0 +++ # Before: # perf trace -e ioctl stty > /dev/null ioctl(0, TCSETS, 0x7fff2cf79f20) = 0 ioctl(1, TIOCSWINSZ, 0x7fff2cf79f40) = -1 ENOTTY (Inappropriate ioctl for device) ioctl(1, TCSETS, 0x7fff2cf79c20) = -1 ENOTTY (Inappropriate ioctl for device) # After: # perf trace -e ioctl stty > /dev/null ioctl(0, TCGETS, 0x7ffed0763920) = 0 ioctl(1, TIOCGWINSZ, 0x7ffed0763940) = -1 ENOTTY (Inappropriate ioctl for device) ioctl(1, TCGETS, 0x7ffed0763620) = -1 ENOTTY (Inappropriate ioctl for device) # Signed-off-by:
Benjamin Peterson <benjamin@python.org> Tested-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Fixes: 1cc47f2d ("perf trace beauty ioctl: Improve 'cmd' beautifier") Link: http://lkml.kernel.org/r/20190823033625.18814-1-benjamin@python.orgSigned-off-by:
-
Maciej S. Szmigiero authored
[ Upstream commit 9d802222 ] saa7134_i2c_eeprom_md7134_gate() function and the associated comment uses an inverted i2c gate open / closed terminology. Let's fix this. Signed-off-by:
Maciej S. Szmigiero <mail@maciej.szmigiero.name> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> [hverkuil-cisco@xs4all.nl: fix alignment checkpatch warning] Signed-off-by:
-
Wenwen Wang authored
[ Upstream commit 1c770f0f ] In submit_urbs(), 'cam->sbuf[i].data' is allocated through kmalloc_array(). However, it is not deallocated if the following allocation for urbs fails. To fix this issue, free 'cam->sbuf[i].data' if usb_alloc_urb() fails. Signed-off-by:
Wenwen Wang <wenwen@cs.uga.edu> Signed-off-by:
-
Wenwen Wang authored
[ Upstream commit 42e64117 ] If saa7146_register_device() fails, no cleanup is executed, leading to memory/resource leaks. To fix this issue, perform necessary cleanup work before returning the error. Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit 14d55116 ] If cec_notifier_cec_adap_unregister() is called before cec_unregister_adapter() then everything is OK (and this is the case today). But if it is the other way around, then cec_notifier_unregister() is called first, and that doesn't set n->cec_adap to NULL. So if e.g. cec_notifier_set_phys_addr() is called after cec_notifier_unregister() but before cec_unregister_adapter() then n->cec_adap points to an unregistered and likely deleted cec adapter. So just set n->cec_adap->notifier and n->cec_adap to NULL for rubustness. Eventually cec_notifier_unregister will disappear and this will be simplified substantially. Signed-off-by:
-
Kamil Konieczny authored
[ Upstream commit 2c2b20e0 ] Regulators should be enabled before clocks to avoid h/w hang. This require change in exynos_bus_probe() to move exynos_bus_parse_of() after exynos_bus_parent_parse_of() and change in error handling. Similar change is needed in exynos_bus_exit() where clock should be disabled before regulators. Signed-off-by:
Kamil Konieczny <k.konieczny@partner.samsung.com> Acked-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by:
MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by:
-
Leonard Crestez authored
[ Upstream commit 0ef7c7cc ] The devfreq passive governor registers and unregisters devfreq transition notifiers on DEVFREQ_GOV_START/GOV_STOP using devm wrappers. If devfreq itself is registered with devm then a warning is triggered on rmmod from devm_devfreq_unregister_notifier. Call stack looks like this: devm_devfreq_unregister_notifier+0x30/0x40 devfreq_passive_event_handler+0x4c/0x88 devfreq_remove_device.part.8+0x6c/0x9c devm_devfreq_dev_release+0x18/0x20 release_nodes+0x1b0/0x220 devres_release_all+0x78/0x84 device_release_driver_internal+0x100/0x1c0 driver_detach+0x4c/0x90 bus_remove_driver+0x7c/0xd0 driver_unregister+0x2c/0x58 platform_driver_unregister+0x10/0x18 imx_devfreq_platdrv_exit+0x14/0xd40 [imx_devfreq] This happens because devres_release_all will first remove all the nodes into a separate todo list so the nested devres_release from devm_devfreq_unregister_notifier won't find anything. Fix the warning by calling the non-devm APIS for frequency notification. Using devm wrappers is not actually useful for a governor anyway: it relies on the devfreq core to correctly match the GOV_START/GOV_STOP notifications. Fixes: 99613311 ("PM / devfreq: Add new passive governor") Signed-off-by:
Leonard Crestez <leonard.crestez@nxp.com> Acked-by:
-
Yazen Ghannam authored
[ Upstream commit 8a2eaab7 ] AMD Family 17h systems currently require address translation in order to report the system address of a DRAM ECC error. This is currently done before decoding the syndrome information. The syndrome information does not depend on the address translation, so the proper EDAC csrow/channel reporting can function without the address. However, the syndrome information will not be decoded if the address translation fails. Decode the syndrome information before doing the address translation. The syndrome information is architecturally defined in MCA_SYND and can be considered robust. The address translation is system-specific and may fail on newer systems without proper updates to the translation algorithm. Fixes: 713ad546 ("EDAC, amd64: Define and register UMC error decode function") Signed-off-by:
Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Tony Luck <tony.luck@intel.com> Link: https://lkml.kernel.org/r/20190821235938.118710-6-Yazen.Ghannam@amd.comSigned-off-by:
-
Yazen Ghannam authored
[ Upstream commit f8be8e56 ] AMD Family 17h systems support x4 and x16 DRAM devices. However, the device type is not checked when setting mci.edac_ctl_cap. Set the appropriate capability flag based on the device type. Default to x8 DRAM device when neither the x4 or x16 bits are set. [ bp: reverse cpk_en check to save an indentation level. ] Fixes: 2d09d8f3 ("EDAC, amd64: Determine EDAC MC capabilities on Fam17h") Signed-off-by:
-
Gerald BAEZA authored
[ Upstream commit d9c5c083 ] Following the patch 'perf stat: Fix --no-scale', an alignment trap happens in process_counter_values() on ARMv7 platforms due to the attempt to copy non 64 bits aligned double words (pointed by 'count') via a NEON vectored instruction ('vld1' with 64 bits alignment constraint). This patch sets a 64 bits alignment constraint on 'contents[]' field in 'struct xyarray' since the 'count' pointer used above points to such a structure. Signed-off-by:
Gerald Baeza <gerald.baeza@st.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1566464769-16374-1-git-send-email-gerald.baeza@st.comSigned-off-by:
-
Wenwen Wang authored
[ Upstream commit fcd5ce4b ] In dvb_create_media_entity(), 'dvbdev->entity' is allocated through kzalloc(). Then, 'dvbdev->pads' is allocated through kcalloc(). However, if kcalloc() fails, the allocated 'dvbdev->entity' is not deallocated, leading to a memory leak bug. To fix this issue, free 'dvbdev->entity' before returning -ENOMEM. Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Thomas Gleixner authored
[ Upstream commit 692117c1 ] Warning when p == NULL and then proceeding and dereferencing p does not make any sense as the kernel will crash with a NULL pointer dereference right away. Bailing out when p == NULL and returning an error code does not cure the underlying problem which caused p to be NULL. Though it might allow to do proper debugging. Same applies to the clock id check in set_process_cpu_timer(). Clean them up and make them return without trying to do further damage. Signed-off-by:
Frederic Weisbecker <frederic@kernel.org> Link: https://lkml.kernel.org/r/20190819143801.846497772@linutronix.deSigned-off-by:
-
Sean Young authored
[ Upstream commit c268e7ad ] KASAN: global-out-of-bounds Read in dvb_pll_attach Syzbot reported global-out-of-bounds Read in dvb_pll_attach, while accessing id[dvb_pll_devcount], because dvb_pll_devcount was 65, that is more than size of 'id' which is DVB_PLL_MAX(64). Rather than increasing dvb_pll_devcount every time, use ida so that numbers are allocated correctly. This does mean that no more than 64 devices can be attached at the same time, but this is more than sufficient. usb 1-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer dvbdev: DVB: registering new adapter (774 Friio White ISDB-T USB2.0) usb 1-1: media controller created dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered. tc90522 0-0018: Toshiba TC90522 attached. usb 1-1: DVB: registering adapter 0 frontend 0 (Toshiba TC90522 ISDB-T module)... dvbdev: dvb_create_media_entity: media entity 'Toshiba TC90522 ISDB-T module' registered. ================================================================== BUG: KASAN: global-out-of-bounds in dvb_pll_attach+0x6c5/0x830 drivers/media/dvb-frontends/dvb-pll.c:798 Read of size 4 at addr ffffffff89c9e5e0 by task kworker/0:1/12 CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.2.0-rc6+ #13 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 print_address_description+0x67/0x231 mm/kasan/report.c:188 __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317 kasan_report+0xe/0x20 mm/kasan/common.c:614 dvb_pll_attach+0x6c5/0x830 drivers/media/dvb-frontends/dvb-pll.c:798 dvb_pll_probe+0xfe/0x174 drivers/media/dvb-frontends/dvb-pll.c:877 i2c_device_probe+0x790/0xaa0 drivers/i2c/i2c-core-base.c:389 really_probe+0x281/0x660 drivers/base/dd.c:509 driver_probe_device+0x104/0x210 drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 __device_attach+0x217/0x360 drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 device_add+0xae6/0x16f0 drivers/base/core.c:2111 i2c_new_client_device+0x5b3/0xc40 drivers/i2c/i2c-core-base.c:778 i2c_new_device+0x19/0x50 drivers/i2c/i2c-core-base.c:821 dvb_module_probe+0xf9/0x220 drivers/media/dvb-core/dvbdev.c:985 friio_tuner_attach+0x125/0x1d0 drivers/media/usb/dvb-usb-v2/gl861.c:536 dvb_usbv2_adapter_frontend_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:675 [inline] dvb_usbv2_adapter_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:804 [inline] dvb_usbv2_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:865 [inline] dvb_usbv2_probe.cold+0x24dc/0x255d drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:980 usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 really_probe+0x281/0x660 drivers/base/dd.c:509 driver_probe_device+0x104/0x210 drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 __device_attach+0x217/0x360 drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 device_add+0xae6/0x16f0 drivers/base/core.c:2111 usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023 generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210 usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266 really_probe+0x281/0x660 drivers/base/dd.c:509 driver_probe_device+0x104/0x210 drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 __device_attach+0x217/0x360 drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 device_add+0xae6/0x16f0 drivers/base/core.c:2111 usb_new_device.cold+0x8c1/0x1016 drivers/usb/core/hub.c:2534 hub_port_connect drivers/usb/core/hub.c:5089 [inline] hub_port_connect_change drivers/usb/core/hub.c:5204 [inline] port_event drivers/usb/core/hub.c:5350 [inline] hub_event+0x1ada/0x3590 drivers/usb/core/hub.c:5432 process_one_work+0x905/0x1570 kernel/workqueue.c:2269 process_scheduled_works kernel/workqueue.c:2331 [inline] worker_thread+0x7ab/0xe20 kernel/workqueue.c:2417 kthread+0x30b/0x410 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 The buggy address belongs to the variable: id+0x100/0x120 Memory state around the buggy address: ffffffff89c9e480: fa fa fa fa 00 00 fa fa fa fa fa fa 00 00 00 00 ffffffff89c9e500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffffffff89c9e580: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa ^ ffffffff89c9e600: 04 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa ffffffff89c9e680: 04 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa ================================================================== Reported-by: syzbot+8a8f48672560c8ca59dd@syzkaller.appspotmail.com Signed-off-by:
-
A Sun authored
[ Upstream commit 9fc3ce31 ] Fix and eliminate mceusb's IR length limit for IR signals transmitted to the MCE IR blaster ports. An IR signal TX exceeding 306 pulse/space samples presently causes -EINVAL return error. There's no such limitation nor error with the MCE device hardware. And valid IR signals exist with more than 400 pulse/space for the control of certain appliances (eg Panasonic ACXA75C00600 air conditioner). The scope of this patch is limited to the mceusb driver. There are still IR signal TX length and time constraints that related modules of rc core (eg LIRC) impose, further up the driver stack. Changes for mceusb_tx_ir(): Converts and sends LIRC IR pulse/space sequence to MCE device IR pulse/space format. Break long length LIRC sequence into multiple (unlimited number of) parts for sending to the MCE device. Reduce kernel stack IR buffer size: 128 (was 384) Increase MCE IR data packet size: 31 (was 5) Zero time LIRC pulse/space no longer copied to MCE IR data. Eliminate overwriting the source/input LIRC IR data in txbuf[]. Eliminate -EINVAL return; return number of IR samples sent (>0) or MCE write error code (<0). New mce_write() and mce_write_callback(): Implements synchronous blocking I/O, with timeout, for writing/sending data to the MCE device. An unlimited multipart IR signal sent to the MCE device faster than real time requires flow control absent with the original mce_request_packet() and mce_async_callback() asynchronous I/O implementation. Also absent is TX error feedback. mce_write() combines and replaces mce_request_packet() and mce_async_callback() with conversion to synchronous I/O. mce_write() returns bytes sent (>0) or MCE device write error (<0). Debug hex dump TX data before processing. Rename mce_async_out() -> mce_command_out(): The original name is misleading with underlying synchronous I/O implementation. Function renamed to mce_command_out(). Changes in mceusb_handle_command(): Add support for MCE device error case MCE_RSP_TX_TIMEOUT "IR TX timeout (TX buffer underrun)" Changes in mceusb_dev_printdata(): Changes support test and debug of multipart TX IR. Add buffer boundary information (offset and buffer size) to TX hex dump. Correct TX trace bug "Raw IR data, 0 pulse/space samples" Add trace for MCE_RSP_TX_TIMEOUT "IR TX timeout (TX buffer underrun)" Other changes: The driver's write to USB device architecture change (async to sync I/O) is significant so we bump DRIVER_VERSION to "1.95" (from "1.94"). Tests: $ cat -n irdata1 | head -3 1 carrier 36000 2 pulse 6350 3 space 6350 $ cat -n irdata1 | tail -3 76 pulse 6350 77 space 6350 78 pulse 6350 $ ir-ctl -s irdata1 [1549021.073612] mceusb 1-1.3:1.0: requesting 36000 HZ carrier [1549021.073635] mceusb 1-1.3:1.0: tx data[0]: 9f 06 01 45 (len=4 sz=4) [1549021.073649] mceusb 1-1.3:1.0: Request carrier of 35714 Hz (period 28us) [1549021.073848] mceusb 1-1.3:1.0: tx done status = 4 (wait = 100, expire = 100 (1000ms), urb->actual_length = 4, urb->status = 0) [1549021.074689] mceusb 1-1.3:1.0: rx data[0]: 9f 06 01 45 (len=4 sz=4) [1549021.074701] mceusb 1-1.3:1.0: Got carrier of 35714 Hz (period 28us) [1549021.102023] mceusb 1-1.3:1.0: tx data[0]: 9f 08 03 (len=3 sz=3) [1549021.102036] mceusb 1-1.3:1.0: Request transmit blaster mask of 0x03 [1549021.102219] mceusb 1-1.3:1.0: tx done status = 3 (wait = 100, expire = 100 (1000ms), urb->actual_length = 3, urb->status = 0) [1549021.131979] mceusb 1-1.3:1.0: tx data[0]: 9e ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f 9e ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f ff 7f 91 ff (len=81 sz=81) [1549021.131992] mceusb 1-1.3:1.0: Raw IR data, 30 pulse/space samples [1549021.133592] mceusb 1-1.3:1.0: tx done status = 81 (wait = 100, expire = 100 (1000ms), urb->actual_length = 81, urb->status = 0) Hex dumps limited to 64 bytes. 0xff is MCE maximum time pulse, 0x7f is MCE maximum time space. $ cat -n irdata2 | head -3 1 carrier 36000 2 pulse 50 3 space 50 $ cat -n irdata2 | tail -3 254 pulse 50 255 space 50 256 pulse 50 $ ir-ctl -s irdata2 [1549306.586998] mceusb 1-1.3:1.0: tx data[0]: 9f 08 03 (len=3 sz=3) [1549306.587015] mceusb 1-1.3:1.0: Request transmit blaster mask of 0x03 [1549306.587252] mceusb 1-1.3:1.0: tx done status = 3 (wait = 100, expire = 100 (1000ms), urb->actual_length = 3, urb->status = 0) [1549306.613275] mceusb 1-1.3:1.0: tx data[0]: 9e 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 9e 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 9e 81 (len=128 sz=128) [1549306.613291] mceusb 1-1.3:1.0: Raw IR data, 30 pulse/space samples [1549306.614837] mceusb 1-1.3:1.0: tx done status = 128 (wait = 100, expire = 100 (1000ms), urb->actual_length = 128, urb->status = 0) [1549306.614861] mceusb 1-1.3:1.0: tx data[0]: 9e 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 9e 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 01 81 9e 01 (len=128 sz=128) [1549306.614869] mceusb 1-1.3:1.0: Raw IR data, 30 pulse/space samples [1549306.620199] mceusb 1-1.3:1.0: tx done status = 128 (wait = 100, expire = 100 (1000ms), urb->actual_length = 128, urb->status = 0) [1549306.620212] mceusb 1-1.3:1.0: tx data[0]: 89 81 01 81 01 81 01 81 01 81 80 (len=11 sz=11) [1549306.620221] mceusb 1-1.3:1.0: Raw IR data, 9 pulse/space samples [1549306.633294] mceusb 1-1.3:1.0: tx done status = 11 (wait = 98, expire = 100 (1000ms), urb->actual_length = 11, urb->status = 0) Hex dumps limited to 64 bytes. 0x81 is MCE minimum time pulse, 0x01 is MCE minimum time space. TX IR part 3 sz=11 shows 20msec I/O blocking delay (100expire - 98wait = 2jiffies) Signed-off-by:
A Sun <as1033x@comcast.net> Signed-off-by:
-
Mike Christie authored
[ Upstream commit 887e975c ] Fix bug added with the patch: commit 8f3ea359 Author: Josef Bacik <josef@toxicpanda.com> Date: Mon Jul 16 12:11:35 2018 -0400 nbd: handle unexpected replies better where if the timeout handler runs when the completion path is and we fail to grab the mutex in the timeout handler we will leave a config reference and cannot free the config later. Reviewed-by:
Josef Bacik <josef@toxicpanda.com> Signed-off-by:
Mike Christie <mchristi@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Wenwen Wang authored
[ Upstream commit 60e2dde1 ] In led_trigger_set(), 'event' is allocated in kasprintf(). However, it is not deallocated in the following execution if the label 'err_activate' or 'err_add_groups' is entered, leading to memory leaks. To fix this issue, free 'event' before returning the error. Fixes: 52c47742 ("leds: triggers: send uevent when changing triggers") Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by:
-
Maxime Ripard authored
[ Upstream commit 7df8f9a2 ] The BCLK divider should be calculated using the parameters that actually make the BCLK rate: the number of channels, the sampling rate and the sample width. We've been using the oversample_rate previously because in the former SoCs, the BCLK's parent is MCLK, which in turn is being used to generate the oversample rate, so we end up with something like this: oversample = mclk_rate / sampling_rate bclk_div = oversample / word_size / channels So, bclk_div = mclk_rate / sampling_rate / word_size / channels. And this is actually better, since the oversampling ratio only plays a role because the MCLK is its parent, not because of what BCLK is supposed to be. Furthermore, that assumption of MCLK being the parent has been broken on newer SoCs, so let's use the proper formula, and have the parent rate as an argument. Fixes: 7d299381 ("ASoC: sun4i-i2s: Add support for H3") Fixes: 21faaea1 ("ASoC: sun4i-i2s: Add support for A83T") Fixes: 66ecce33 ("ASoC: sun4i-i2s: Add compatibility with A64 codec I2S") Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://lore.kernel.org/r/c3595e3a9788c2ef2dcc30aa3c8c4953bb5cc249.1566242458.git-series.maxime.ripard@bootlin.comSigned-off-by:
-
Arnaldo Carvalho de Melo authored
[ Upstream commit 42fc2e9e ] We were getting the file by luck, from one of the paths in -I, fix it to get it from the proper place: $ cd tools/include/uapi/asm/ [acme@quaco asm]$ grep include bitsperlong.h #include "../../arch/x86/include/uapi/asm/bitsperlong.h" #include "../../arch/arm64/include/uapi/asm/bitsperlong.h" #include "../../arch/powerpc/include/uapi/asm/bitsperlong.h" #include "../../arch/s390/include/uapi/asm/bitsperlong.h" #include "../../arch/sparc/include/uapi/asm/bitsperlong.h" #include "../../arch/mips/include/uapi/asm/bitsperlong.h" #include "../../arch/ia64/include/uapi/asm/bitsperlong.h" #include "../../arch/riscv/include/uapi/asm/bitsperlong.h" #include "../../arch/alpha/include/uapi/asm/bitsperlong.h" #include <asm-generic/bitsperlong.h> $ ls -la ../../arch/x86/include/uapi/asm/bitsperlong.h ls: cannot access '../../arch/x86/include/uapi/asm/bitsperlong.h': No such file or directory $ ls -la ../../../arch/*/include/uapi/asm/bitsperlong.h -rw-rw-r--. 1 237 ../../../arch/alpha/include/uapi/asm/bitsperlong.h -rw-rw-r--. 1 841 ../../../arch/arm64/include/uapi/asm/bitsperlong.h -rw-rw-r--. 1 966 ../../../arch/hexagon/include/uapi/asm/bitsperlong.h -rw-rw-r--. 1 234 ../../../arch/ia64/include/uapi/asm/bitsperlong.h -rw-rw-r--. 1 100 ../../../arch/microblaze/include/uapi/asm/bitsperlong.h -rw-rw-r--. 1 244 ../../../arch/mips/include/uapi/asm/bitsperlong.h -rw-rw-r--. 1 352 ../../../arch/parisc/include/uapi/asm/bitsperlong.h -rw-rw-r--. 1 312 ../../../arch/powerpc/include/uapi/asm/bitsperlong.h -rw-rw-r--. 1 353 ../../../arch/riscv/include/uapi/asm/bitsperlong.h -rw-rw-r--. 1 292 ../../../arch/s390/include/uapi/asm/bitsperlong.h -rw-rw-r--. 1 323 ../../../arch/sparc/include/uapi/asm/bitsperlong.h -rw-rw-r--. 1 320 ../../../arch/x86/include/uapi/asm/bitsperlong.h $ Found while fixing some other problem, before it was escaping the tools/ chroot and using stuff in the kernel sources: CC /tmp/build/perf/util/find_bit.o In file included from /git/linux/tools/include/../../arch/x86/include/uapi/asm/bitsperlong.h:11, from /git/linux/tools/include/uapi/asm/bitsperlong.h:3, from /git/linux/tools/include/linux/bits.h:6, from /git/linux/tools/include/linux/bitops.h:13, from ../lib/find_bit.c:17: # cd /git/linux/tools/include/../../arch/x86/include/uapi/asm/ # pwd /git/linux/arch/x86/include/uapi/asm # Now it is getting the one we want it to, i.e. the one inside tools/: CC /tmp/build/perf/util/find_bit.o In file included from /git/linux/tools/arch/x86/include/uapi/asm/bitsperlong.h:11, from /git/linux/tools/include/linux/bits.h:6, from /git/linux/tools/include/linux/bitops.h:13, Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lkml.kernel.org/n/tip-8f8cfqywmf6jk8a3ucr0ixhu@git.kernel.orgSigned-off-by:
-
Kunihiko Hayashi authored
[ Upstream commit c372a355 ] When transitioning to supend state, uniphier_aio_dai_suspend() is called and asserts reset lines and disables clocks. However, if there are two or more DAIs, uniphier_aio_dai_suspend() are called multiple times, and double reset assersion will cause. This patch defines the counter that has the number of DAIs at first, and whenever uniphier_aio_dai_suspend() are called, it decrements the counter. And only if the counter is zero, it asserts reset lines and disables clocks. In the same way, uniphier_aio_dai_resume() are called, it increments the counter after deasserting reset lines and enabling clocks. Fixes: 139a3420 ("ASoC: uniphier: add support for UniPhier AIO CPU DAI driver") Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1566281764-14059-1-git-send-email-hayashi.kunihiko@socionext.comSigned-off-by:
-
Hans Verkuil authored
[ Upstream commit 8b8900b7 ] dev->usbc_buf was passed as argument for %s, but it was not safeguarded by a terminating 0. This caused this syzbot issue: https://syzkaller.appspot.com/bug?extid=79d18aac4bf1770dd050 Reported-and-tested-by: syzbot+79d18aac4bf1770dd050@syzkaller.appspotmail.com Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit 0d616f2a ] In the probe() function radio->int_in_urb was not killed if an error occurred in the probe sequence. It was also missing in the disconnect. This caused this syzbot issue: https://syzkaller.appspot.com/bug?extid=2d4fc2a0c45ad8da7e99 Reported-and-tested-by: syzbot+2d4fc2a0c45ad8da7e99@syzkaller.appspotmail.com Signed-off-by:
-
Stefan Agner authored
[ Upstream commit a95fbda0 ] Force HS200 by masking bit 63 of the SDHCI capability register. The i.MX ESDHC driver uses SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400. With that the stack checks bit 63 to descide whether HS400 is available. Using sdhci-caps-mask allows to mask bit 63. The stack then selects HS200 as operating mode. This prevents rare communication errors with minimal effect on performance: sdhci-esdhc-imx 30b60000.usdhc: warning! HS400 strobe DLL status REF not lock! Signed-off-by:
Stefan Agner <stefan.agner@toradex.com> Signed-off-by:
Philippe Schenker <philippe.schenker@toradex.com> Reviewed-by:
Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
André Draszik authored
[ Upstream commit 9846a452 ] Recent changes to the atheros at803x driver caused ethernet to stop working on this board. In particular commit 6d4cd041 ("net: phy: at803x: disable delay only for RGMII mode") and commit cd28d1d6 ("net: phy: at803x: Disable phy delay for RGMII mode") fix the AR8031 driver to configure the phy's (RX/TX) delays as per the 'phy-mode' in the device tree. This now prevents ethernet from working on this board. It used to work before those commits, because the AR8031 comes out of reset with RX delay enabled, and the at803x driver didn't touch the delay configuration at all when "rgmii" mode was selected, and because arch/arm/mach-imx/mach-imx7d.c:ar8031_phy_fixup() unconditionally enables TX delay. Since above commits ar8031_phy_fixup() also has no effect anymore, and the end-result is that all delays are disabled in the phy, no ethernet. Update the device tree to restore functionality. Signed-off-by:
André Draszik <git@andred.net> CC: Ilya Ledvich <ilya@compulab.co.il> CC: Igor Grinberg <grinberg@compulab.co.il> CC: Rob Herring <robh+dt@kernel.org> CC: Mark Rutland <mark.rutland@arm.com> CC: Shawn Guo <shawnguo@kernel.org> CC: Sascha Hauer <s.hauer@pengutronix.de> CC: Pengutronix Kernel Team <kernel@pengutronix.de> CC: Fabio Estevam <festevam@gmail.com> CC: NXP Linux Team <linux-imx@nxp.com> CC: devicetree@vger.kernel.org CC: linux-arm-kernel@lists.infradead.org Signed-off-by:
-
Finn Thain authored
[ Upstream commit 94c04390 ] Since commit d3b41b6b ("m68k: Dispatch nvram_ops calls to Atari or Mac functions"), Coldfire builds generate compiler warnings due to the unconditional inclusion of asm/atarihw.h and asm/macintosh.h. The inclusion of asm/atarihw.h causes warnings like this: In file included from ./arch/m68k/include/asm/atarihw.h:25:0, from arch/m68k/kernel/setup_mm.c:41, from arch/m68k/kernel/setup.c:3: ./arch/m68k/include/asm/raw_io.h:39:0: warning: "__raw_readb" redefined #define __raw_readb in_8 In file included from ./arch/m68k/include/asm/io.h:6:0, from arch/m68k/kernel/setup_mm.c:36, from arch/m68k/kernel/setup.c:3: ./arch/m68k/include/asm/io_no.h:16:0: note: this is the location of the previous definition #define __raw_readb(addr) \ ... This issue is resolved by dropping the asm/raw_io.h include. It turns out that asm/io_mm.h already includes that header file. Moving the relevant macro definitions helps to clarify this dependency and make it safe to include asm/atarihw.h. The other warnings look like this: In file included from arch/m68k/kernel/setup_mm.c:48:0, from arch/m68k/kernel/setup.c:3: ./arch/m68k/include/asm/macintosh.h:19:35: warning: 'struct irq_data' declared inside parameter list will not be visible outside of this definition or declaration extern void mac_irq_enable(struct irq_data *data); ^~~~~~~~ ... This issue is resolved by adding the missing linux/irq.h include. Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Acked-by:
Greg Ungerer <gerg@linux-m68k.org> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit de6f97b2 ] compile-testing this driver on other architectures showed multiple warnings: drivers/net/ethernet/nxp/lpc_eth.c: In function 'lpc_eth_drv_probe': drivers/net/ethernet/nxp/lpc_eth.c:1337:19: warning: format '%d' expects argument of type 'int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=] drivers/net/ethernet/nxp/lpc_eth.c:1342:19: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=] Use format strings that work on all architectures. Link: https://lore.kernel.org/r/20190809144043.476786-10-arnd@arndb.deReported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Ezequiel Garcia authored
[ Upstream commit 0d5078c7 ] Not all sensors will be able to guarantee a proper initial state. This may be either because the driver is not properly written, or (probably unlikely) because the hardware won't support it. While the right solution in the former case is to fix the sensor driver, the real world not always allows right solutions, due to lack of available documentation and support on these sensors. Let's relax this requirement, and allow the driver to support stream start, even if the sensor initial sequence wasn't the expected. Also improve the warning message to better explain the problem and provide a hint that the sensor driver needs to be fixed. Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Fabio Estevam <festevam@gmail.com> Reviewed-by:
Steve Longerbeam <slongerbeam@gmail.com> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Sakari Ailus authored
[ Upstream commit 7ef57be0 ] The streaming state should be set to the first upstream sub-device only, not everywhere, for a sub-device driver itself knows how to best control the streaming state of its own upstream sub-devices. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Ezequiel Garcia authored
[ Upstream commit 092e8eb9 ] This is mostly a port of Jacopo's fix: commit aa4bb8b8 Author: Jacopo Mondi <jacopo@jmondi.org> Date: Fri Jul 6 05:51:52 2018 -0400 media: ov5640: Re-work MIPI startup sequence In the OV5645 case, the changes are: - At set_power(1) time power up MIPI Tx/Rx and set data and clock lanes in LP11 during 'sleep' and 'idle' with MIPI clock in non-continuous mode. - At set_power(0) time power down MIPI Tx/Rx (in addition to the current power down of regulators and clock gating). - At s_stream time enable/disable the MIPI interface output. With this commit the sensor is able to enter LP-11 mode during power up, as expected by some CSI-2 controllers. Many thanks to Fabio Estevam for his help debugging this issue. Tested-by:
Jacopo Mondi <jacopo@jmondi.org> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 70c55c1a ] Currently when the call vsp1_dl_body_get fails and returns null the error return path leaks the allocation of dl. Fix this by kfree'ing dl before returning. Addresses-Coverity: ("Resource leak") Fixes: 5d7936b8 ("media: vsp1: Convert display lists to use new body pool") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Tan Xiaojun authored
[ Upstream commit 0a4d8fb2 ] Same as in the commit 01766229 ("perf record: Support s390 random socket_id assignment"), aarch64 also have this problem. Without this fix: [root@localhost perf]# ./perf report --header -I -v ... socket_id number is too big.You may need to upgrade the perf tool. # ======== # captured on : Thu Aug 1 22:58:38 2019 # header version : 1 ... # Core ID and Socket ID information is not available ... With this fix: [root@localhost perf]# ./perf report --header -I -v ... cpumask list: 0-31 cpumask list: 32-63 cpumask list: 64-95 cpumask list: 96-127 # ======== # captured on : Thu Aug 1 22:58:38 2019 # header version : 1 ... # CPU 0: Core ID 0, Socket ID 36 # CPU 1: Core ID 1, Socket ID 36 ... # CPU 126: Core ID 126, Socket ID 8442 # CPU 127: Core ID 127, Socket ID 8442 ... Signed-off-by:
Tan Xiaojun <tanxiaojun@huawei.com> Acked-by:
Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexey Budankov <alexey.budankov@linux.intel.com> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Song Liu <songliubraving@fb.com> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com> Link: http://lkml.kernel.org/r/1564717737-21602-1-git-send-email-tanxiaojun@huawei.comSigned-off-by:
-
Arnd Bergmann authored
[ Upstream commit 00c97555 ] When compile-testing on other architectures, we get lots of warnings about incorrect format strings, like: drivers/dma/iop-adma.c: In function 'iop_adma_alloc_slots': drivers/dma/iop-adma.c:307:6: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=] drivers/dma/iop-adma.c: In function 'iop_adma_prep_dma_memcpy': >> drivers/dma/iop-adma.c:518:40: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'size_t {aka long unsigned int}' [-Wformat=] Use %zu for printing size_t as required, and cast the dma_addr_t arguments to 'u64' for printing with %llx. Ideally this should use the %pad format string, but that requires an lvalue argument that doesn't work here. Link: https://lore.kernel.org/r/20190809163334.489360-3-arnd@arndb.deSigned-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Darius Rad authored
[ Upstream commit b20a6e29 ] Allow selecting the IR protocol, MCE or iMON, for a device that identifies as follows (with config id 0x7e): 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller As the driver is structured to default to iMON when both RC protocols are supported, existing users of this device (using MCE protocol) will need to manually switch to MCE (RC-6) protocol from userspace (with ir-keytable, sysfs). Signed-off-by:
Darius Rad <alpha@area49.net> Signed-off-by:
-
