- 31 Dec, 2019 40 commits
-
-
Benoit Parrot authored
[ Upstream commit 2444846c ] v4l2-compliance fails with this message: fail: v4l2-test-buffers.cpp(294): \ (int)g_sequence() < seq.last_seq + 1 fail: v4l2-test-buffers.cpp(740): \ buf.check(m2m_q, last_m2m_seq) fail: v4l2-test-buffers.cpp(974): \ captureBufs(node, q, m2m_q, frame_count, true) test MMAP: FAIL The driver is failing to update the source frame sequence number in the vb2 buffer object. Only the destination frame sequence was being updated. This is only a reporting issue if the user space app actually cares about the frame sequence number. But it is fixed nonetheless. Signed-off-by:
Benoit Parrot <bparrot@ti.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Benoit Parrot authored
[ Upstream commit 06bec72b ] v4l2-compliance warns with this message: warn: v4l2-test-formats.cpp(717): \ TRY_FMT cannot handle an invalid pixelformat. warn: v4l2-test-formats.cpp(718): \ This may or may not be a problem. For more information see: warn: v4l2-test-formats.cpp(719): \ http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html ... test VIDIOC_TRY_FMT: FAIL We need to make sure that the returns a valid pixel format in all instance. Based on the v4l2 framework convention drivers must return a valid pixel format when the requested pixel format is either invalid or not supported. Signed-off-by:
-
Benoit Parrot authored
[ Upstream commit 102af9b9 ] commit 3dc2046c ("[media] media: ti-vpe: vpe: allow use of user specified stride") and commit da4414ea ("[media] media: ti-vpe: vpdma: add support for user specified stride") resulted in the Motion Vector stride to be the same as the image stride. This caused memory corruption in the output image as mentioned in commit 00db9699 ("[media] media: ti-vpe: vpe: Fix line stride for output motion vector"). Fixes: 3dc2046c ("[media] media: ti-vpe: vpe: allow use of user specified stride") Fixes: da4414ea ("[media] media: ti-vpe: vpdma: add support for user specified stride") Signed-off-by:
Nikhil Devshatwar <nikhil.nd@ti.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit e1444e9b ] A call to 'pci_disable_device()' is missing in the error handling path. In some cases, a call to 'free_irq()' may also be missing. Reorder the error handling path, add some new labels and fix the 2 issues mentionned above. This way, the error handling path in more in line with 'cx8800_finidev()' (i.e. the remove function) Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Rodrigo Siqueira authored
[ Upstream commit aed6105b ] For historical reasons, the function drm_wait_vblank_ioctl always return -EINVAL if something gets wrong. This scenario limits the flexibility for the userspace to make detailed verification of any problem and take some action. In particular, the validation of “if (!dev->irq_enabled)” in the drm_wait_vblank_ioctl is responsible for checking if the driver support vblank or not. If the driver does not support VBlank, the function drm_wait_vblank_ioctl returns EINVAL, which does not represent the real issue; this patch changes this behavior by return EOPNOTSUPP. Additionally, drm_crtc_get_sequence_ioctl and drm_crtc_queue_sequence_ioctl, also returns EINVAL if vblank is not supported; this patch also changes the return value to EOPNOTSUPP in these functions. Lastly, these functions are invoked by libdrm, which is used by many compositors; because of this, it is important to check if this change breaks any compositor. In this sense, the following projects were examined: * Drm-hwcomposer * Kwin * Sway * Wlroots * Wayland * Weston * Mutter * Xorg (67 different drivers) For each repository the verification happened in three steps: * Update the main branch * Look for any occurrence of "drmCrtcQueueSequence", "drmCrtcGetSequence", and "drmWaitVBlank" with the command git grep -n "STRING". * Look in the git history of the project with the command git log -S<STRING> None of the above projects validate the use of EINVAL when using drmWaitVBlank(), which make safe, at least for these projects, to change the return values. On the other hand, mesa and xserver project uses drmCrtcQueueSequence() and drmCrtcGetSequence(); this change is harmless for both projects. Change since V5 (Pekka Paalanen): - Check if the change also affects Mutter Change since V4 (Daniel): - Also return EOPNOTSUPP in drm_crtc_[get|queue]_sequence_ioctl Change since V3: - Return EINVAL for _DRM_VBLANK_SIGNAL (Daniel) Change since V2: Daniel Vetter and Chris Wilson - Replace ENOTTY by EOPNOTSUPP - Return EINVAL if the parameters are wrong Cc: Keith Packard <keithp@keithp.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191002140516.adeyj3htylimmlmg@smtp.gmail.comSigned-off-by:
-
Navid Emamdoost authored
[ Upstream commit d10dcb61 ] In mwifiex_pcie_init_evt_ring, a new skb is allocated which should be released if mwifiex_map_pci_memory() fails. The release for skb and card->evtbd_ring_vbase is added. Fixes: 0732484b ("mwifiex: separate ring initialization and ring creation routines") Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Acked-by:
Ganapathi Bhat <gbhat@marvell.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit 1d200e9d ] Fix the following compiler warnings: In file included from ./include/linux/bitmap.h:9, from ./include/linux/cpumask.h:12, from ./arch/x86/include/asm/cpumask.h:5, from ./arch/x86/include/asm/msr.h:11, from ./arch/x86/include/asm/processor.h:21, from ./arch/x86/include/asm/cpufeature.h:5, from ./arch/x86/include/asm/thread_info.h:53, from ./include/linux/thread_info.h:38, from ./arch/x86/include/asm/preempt.h:7, from ./include/linux/preempt.h:78, from ./include/linux/spinlock.h:51, from ./include/linux/mmzone.h:8, from ./include/linux/gfp.h:6, from ./include/linux/mm.h:10, from ./include/linux/bvec.h:13, from ./include/linux/blk_types.h:10, from block/blk-wbt.c:23: In function 'strncpy', inlined from 'perf_trace_wbt_stat' at ./include/trace/events/wbt.h:15:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'perf_trace_wbt_lat' at ./include/trace/events/wbt.h:58:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'perf_trace_wbt_step' at ./include/trace/events/wbt.h:87:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'perf_trace_wbt_timer' at ./include/trace/events/wbt.h:126:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'trace_event_raw_event_wbt_stat' at ./include/trace/events/wbt.h:15:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'trace_event_raw_event_wbt_lat' at ./include/trace/events/wbt.h:58:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'trace_event_raw_event_wbt_timer' at ./include/trace/events/wbt.h:126:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'trace_event_raw_event_wbt_step' at ./include/trace/events/wbt.h:87:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cc: Christoph Hellwig <hch@infradead.org> Cc: Ming Lei <ming.lei@redhat.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Johannes Thumshirn <jthumshirn@suse.de> Fixes: e34cbd30 ("blk-wbt: add general throttling mechanism"; v4.10). Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Daniel T. Lee authored
[ Upstream commit 3cad8f91 ] Currently, proc_cmd is used to dispatch command to 'pg_ctrl', 'pg_thread', 'pg_set'. proc_cmd is designed to check command result with grep the "Result:", but this might fail since this string is only shown in 'pg_thread' and 'pg_set'. This commit fixes this logic by grep-ing the "Result:" string only when the command is not for 'pg_ctrl'. For clarity of an execution flow, 'errexit' flag has been set. To cleanup pktgen on exit, trap has been added for EXIT signal. Signed-off-by:
Daniel T. Lee <danieltimlee@gmail.com> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Matthias Kaehlcke authored
[ Upstream commit bee447e2 ] The DDC/CI protocol involves sending a multi-byte request to the display via I2C, which is typically followed by a multi-byte response. The internal I2C controller only allows single byte reads/writes or reads of 8 sequential bytes, hence DDC/CI is not supported when the internal I2C controller is used. The I2C transfers complete without errors, however the data in the response is garbage. Abort transfers to/from slave address 0x37 (DDC) with -EOPNOTSUPP, to make it evident that the communication is failing. Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Sean Paul <sean@poorly.run> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit 9b211f9c ] The CEC_MSG_GIVE_DECK_STATUS and CEC_MSG_GIVE_TUNER_DEVICE_STATUS commands both have a status_req argument: ON, OFF, ONCE. If ON or ONCE, then the follower will reply with a STATUS message. Either once or whenever the status changes (status_req == ON). If status_req == OFF, then it will stop sending continuous status updates, but the follower will *not* send a STATUS message in that case. This means that if status_req == OFF, then msg->reply should be 0 as well since no reply is expected in that case. Signed-off-by:
-
Yang Yingliang authored
[ Upstream commit 649cd16c ] If usb_set_interface() failed, iface->cur_altsetting will not be assigned and it will be used in flexcop_usb_transfer_init() It may lead a NULL pointer dereference. Check usb_set_interface() return value in flexcop_usb_init() and return failed to avoid using this NULL pointer. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Yizhuo authored
[ Upstream commit 472b39c3 ] Inside function max8907_regulator_probe(), variable val could be uninitialized if regmap_read() fails. However, val is used later in the if statement to decide the content written to "pmic", which is potentially unsafe. Signed-off-by:
Yizhuo <yzhai003@ucr.edu> Link: https://lore.kernel.org/r/20191003175813.16415-1-yzhai003@ucr.eduSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit eaecce12 ] When unloading omap3-rom-rng, we'll get the following: WARNING: CPU: 0 PID: 100 at drivers/clk/clk.c:948 clk_core_disable This is because the clock may be already disabled by omap3_rom_rng_idle(). Let's fix the issue by checking for rng_idle on exit. Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Adam Ford <aford173@gmail.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Fixes: 1c6b7c21 ("hwrng: OMAP3 ROM Random Number Generator support") Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Veeraiyan Chidambaram authored
[ Upstream commit 39abcc84 ] When R-Car Gen3 USB 2.0 is in Gadget mode, if host is detached an interrupt will be generated and Suspended state bit is set in interrupt status register. Interrupt handler will call driver->suspend(composite_suspend) if suspended state bit is set. composite_suspend will call ffs_func_suspend which will post FUNCTIONFS_SUSPEND and will be consumed by user space application via /dev/ep0. To be able to detect host detach, extend the DVSQ_MASK to cover the Suspended bit of the DVSQ[2:0] bitfield from the Interrupt Status Register 0 (INTSTS0) register and perform appropriate action in the DVST interrupt handler (usbhsg_irq_dev_state). Without this commit, disconnection of the phone from R-Car-H3 ES2.0 Salvator-X CN9 port is not recognized and reverse role switch does not happen. If phone is connected again it does not enumerate. With this commit, disconnection will be recognized and reverse role switch will happen by a user space application. If phone is connected again it will enumerate properly and will become visible in the output of 'lsusb'. Signed-off-by:
Veeraiyan Chidambaram <veeraiyan.chidambaram@in.bosch.com> Signed-off-by:
Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Stanimir Varbanov authored
[ Upstream commit 8dbebb2b ] Failure to suspend (venus_suspend_3xx) happens when the system is fresh booted and loading venus driver. This happens once and after reload the venus driver modules the problem disrepair. Fix the failure by skipping the check for WFI and IDLE bits if PC_READY is on in control status register. Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by:
-
Ivan Khoronzhuk authored
[ Upstream commit c5881463 ] The "path" buf is supposed to contain path + printf msg up to 24 bytes. It will be cut anyway, but compiler generates truncation warns like: " samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c: In function ‘setup_cgroup_environment’: samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c:52:34: warning: ‘/cgroup.controllers’ directive output may be truncated writing 19 bytes into a region of size between 1 and 4097 [-Wformat-truncation=] snprintf(path, sizeof(path), "%s/cgroup.controllers", cgroup_path); ^~~~~~~~~~~~~~~~~~~ samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c:52:2: note: ‘snprintf’ output between 20 and 4116 bytes into a destination of size 4097 snprintf(path, sizeof(path), "%s/cgroup.controllers", cgroup_path); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c:72:34: warning: ‘/cgroup.subtree_control’ directive output may be truncated writing 23 bytes into a region of size between 1 and 4097 [-Wformat-truncation=] snprintf(path, sizeof(path), "%s/cgroup.subtree_control", ^~~~~~~~~~~~~~~~~~~~~~~ cgroup_path); samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c:72:2: note: ‘snprintf’ output between 24 and 4120 bytes into a destination of size 4097 snprintf(path, sizeof(path), "%s/cgroup.subtree_control", cgroup_path); " In order to avoid warns, lets decrease buf size for cgroup workdir on 24 bytes with assumption to include also "/cgroup.subtree_control" to the address. The cut will never happen anyway. Signed-off-by:
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Song Liu <songliubraving@fb.com> Link: https://lore.kernel.org/bpf/20191002120404.26962-3-ivan.khoronzhuk@linaro.orgSigned-off-by:
-
Allen Pais authored
[ Upstream commit 81de29d8 ] alloc_workqueue is not checked for errors and as a result, a potential NULL dereference could occur. v2 (Felix Kuehling): * Fix compile error (kfifo_free instead of fifo_free) * Return proper error code Signed-off-by:
Allen Pais <allen.pais@oracle.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Will Deacon authored
[ Upstream commit be4c60b5 ] When populating the pinctrl mapping table entries for a device, the 'dev_name' field for each entry is initialised to point directly at the string returned by 'dev_name()' for the device and subsequently used by 'create_pinctrl()' when looking up the mappings for the device being probed. This is unreliable in the presence of calls to 'dev_set_name()', which may reallocate the device name string leaving the pinctrl mappings with a dangling reference. This then leads to a use-after-free every time the name is dereferenced by a device probe: | BUG: KASAN: invalid-access in strcmp+0x20/0x64 | Read of size 1 at addr 13ffffc153494b00 by task modprobe/590 | Pointer tag: [13], memory tag: [fe] | | Call trace: | __kasan_report+0x16c/0x1dc | kasan_report+0x10/0x18 | check_memory_region | __hwasan_load1_noabort+0x4c/0x54 | strcmp+0x20/0x64 | create_pinctrl+0x18c/0x7f4 | pinctrl_get+0x90/0x114 | devm_pinctrl_get+0x44/0x98 | pinctrl_bind_pins+0x5c/0x450 | really_probe+0x1c8/0x9a4 | driver_probe_device+0x120/0x1d8 Follow the example of sysfs, and duplicate the device name string before stashing it away in the pinctrl mapping entries. Cc: Linus Walleij <linus.walleij@linaro.org> Reported-by:
Elena Petrova <lenaptr@google.com> Tested-by:
Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20191002124206.22928-1-will@kernel.orgSigned-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Ben Greear authored
[ Upstream commit cc6df017 ] Offchannel management frames were failing: [18099.253732] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18102.293686] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18105.333653] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18108.373712] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18111.413687] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e36c0 [18114.453726] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3f00 [18117.493773] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e36c0 [18120.533631] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3f00 This bug appears to have been added between 4.0 (which works for us), and 4.4, which does not work. I think this is because the tx-offchannel logic gets in a loop when ath10k_mac_tx_frm_has_freq(ar) is false, so pkt is never actually sent to the firmware for transmit. This patch fixes the problem on 4.9 for me, and now HS20 clients can work again with my firmware. Antonio: tested with 10.4-3.5.3-00057 on QCA4019 and QCA9888 Signed-off-by:
Ben Greear <greearb@candelatech.com> Tested-by:
Antonio Quartulli <antonio.quartulli@kaiwoo.ai> [kvalo@codeaurora.org: improve commit log, remove unneeded parenthesis] Signed-off-by:
-
Loic Poulain authored
[ Upstream commit c690435e ] In downstream driver, there are two frequency tables defined, one for the encoder and one for the decoder: /* Encoders / <972000 490000000 0x55555555>, / 4k UHD @ 30 / <489600 320000000 0x55555555>, / 1080p @ 60 / <244800 150000000 0x55555555>, / 1080p @ 30 / <108000 75000000 0x55555555>, / 720p @ 30 */ /* Decoders / <1944000 490000000 0xffffffff>, / 4k UHD @ 60 / < 972000 320000000 0xffffffff>, / 4k UHD @ 30 / < 489600 150000000 0xffffffff>, / 1080p @ 60 / < 244800 75000000 0xffffffff>; / 1080p @ 30 */ It shows that encoder always needs a higher clock than decoder. In current venus driver, the unified frequency table is aligned with the downstream decoder table which causes performance issues in encoding scenarios. Fix that by aligning frequency table on worst case (encoding). Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 7e5705c6 ] When building cpupower with clang, the following warning appears: utils/idle_monitor/hsw_ext_idle.c:42:16: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] .desc = N_("Processor Package C2"), ^~~~~~~~~~~~~~~~~~~~~~ ./utils/helpers/helpers.h:25:33: note: expanded from macro 'N_' #define N_(String) gettext_noop(String) ^~~~~~ ./utils/helpers/helpers.h:23:30: note: expanded from macro 'gettext_noop' #define gettext_noop(String) String ^~~~~~ utils/idle_monitor/hsw_ext_idle.c:41:16: note: previous initialization is here .desc = N_("Processor Package C9"), ^~~~~~~~~~~~~~~~~~~~~~ ./utils/helpers/helpers.h:25:33: note: expanded from macro 'N_' #define N_(String) gettext_noop(String) ^~~~~~ ./utils/helpers/helpers.h:23:30: note: expanded from macro 'gettext_noop' #define gettext_noop(String) String ^~~~~~ 1 warning generated. This appears to be a copy and paste or merge mistake because the name and id fields both have PC9 in them, not PC2. Remove the second assignment to fix the warning. Fixes: 7ee767b6 ("cpupower: Add Haswell family 0x45 specific idle monitor to show PC8,9,10 states") Link: https://github.com/ClangBuiltLinux/linux/issues/718Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Janusz Krzysztofik authored
[ Upstream commit 1463b371 ] The driver stores crop rectangle settings supposed to be in line with hardware state in a device private structure. Since the driver initial submission, crop rectangle width and height settings are not updated correctly when rectangle offset settings are applied on hardware. If an error occurs while the device is updated, the stored settings my no longer reflect hardware state and consecutive calls to .get_selection() as well as .get/set_fmt() may return incorrect information. That in turn may affect ability of a bridge device to use correct DMA transfer settings if such incorrect informamtion on active frame format returned by .get/set_fmt() is used. Assuming a failed update of the device means its actual settings haven't changed, update crop rectangle width and height settings stored in the device private structure correctly while the rectangle offset is successfully applied on hardware so the stored values always reflect actual hardware state to the extent possible. Fixes: 2f6e2404 ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by:
Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Janusz Krzysztofik authored
[ Upstream commit 3143b459 ] The driver stores frame format settings supposed to be in line with hardware state in a device private structure. Since the driver initial submission, those settings are updated before they are actually applied on hardware. If an error occurs on device update, the stored settings my not reflect hardware state anymore and consecutive calls to .get_fmt() may return incorrect information. That in turn may affect ability of a bridge device to use correct DMA transfer settings if such incorrect informmation on active frame format returned by .get_fmt() is used. Assuming a failed device update means its state hasn't changed, update frame format related settings stored in the device private structure only after they are successfully applied so the stored values always reflect hardware state as closely as possible. Fixes: 2f6e2404 ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by:
-
Benoit Parrot authored
[ Upstream commit 9d669fbf ] The initial registers sequence is only loaded at probe time. Afterward only the resolution and format specific register are modified. Care must be taken to make sure registers modified by one resolution setting are reverted back when another resolution is programmed. This was not done properly for the 720p case. Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Janusz Krzysztofik authored
[ Upstream commit 7b188d6b ] Commit 4f996594 ("[media] v4l2: make vidioc_s_crop const") introduced a writable copy of constified user requested crop rectangle in order to be able to perform hardware alignments on it. Later on, commit 10d5509c ("[media] v4l2: remove g/s_crop from video ops") replaced s_crop() video operation using that const argument with set_selection() pad operation which had a corresponding argument not constified, however the original behavior of the driver was not restored. Since that time, any hardware alignment applied on a user requested crop rectangle is not passed back to the user calling .set_selection() as it should be. Fix the issue by dropping the copy and replacing all references to it with references to the crop rectangle embedded in the user argument. Fixes: 10d5509c ("[media] v4l2: remove g/s_crop from video ops") Signed-off-by:
-
Benoit Parrot authored
[ Upstream commit 85c4043f ] In ov2659_s_stream() return value for invoked function should be checked and propagated. Signed-off-by:
-
Benoit Parrot authored
[ Upstream commit 13aa21cf ] VIDIOC_S_STD should not return an error if the value is identical to the current one. This error was highlighted by the v4l2-compliance test. Signed-off-by:
-
Max Gurtovoy authored
[ Upstream commit 7718cf03 ] In case we don't set the sg_prot_tablesize, the scsi layer assign the default size (65535 entries). We should limit this size since we should take into consideration the underlaying device capability. This cap is considered when calculating the sg_tablesize. Otherwise, for example, we can get that /sys/block/sdb/queue/max_segments is 128 and /sys/block/sdb/queue/max_integrity_segments is 65535. Link: https://lore.kernel.org/r/1569359027-10987-1-git-send-email-maxg@mellanox.comSigned-off-by:
Max Gurtovoy <maxg@mellanox.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Anilkumar Kolli authored
[ Upstream commit d98ddae8 ] In a multiradio board with one QCA9984 and one AR9987 after enabling the crashdump with module parameter coredump_mask=7, below backtrace is seen. vmalloc: allocation failure: 0 bytes kworker/u4:0: page allocation failure: order:0, mode:0x80d2 CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 3.14.77 #130 Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] (unwind_backtrace) from [<c021abf8>] (show_stack+0x10/0x14) (dump_stack+0x80/0xa0) (warn_alloc_failed+0xd0/0xfc) (__vmalloc_node_range+0x1b4/0x1d8) (__vmalloc_node+0x34/0x40) (vzalloc+0x24/0x30) (ath10k_coredump_register+0x6c/0x88 [ath10k_core]) (ath10k_core_register_work+0x350/0xb34 [ath10k_core]) (process_one_work+0x20c/0x32c) (worker_thread+0x228/0x360) This is due to ath10k_hw_mem_layout is not defined for AR9987. For coredump undefined hw ramdump_size is 0. Check for the ramdump_size before allocation memory. Tested on: AR9987, QCA9984 FW version: 10.4-3.9.0.2-00044 Signed-off-by:
Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by:
-
Allen Pais authored
[ Upstream commit 7da413a1 ] alloc_workqueue is not checked for errors and as a result, a potential NULL dereference could occur. Signed-off-by:
-
Navid Emamdoost authored
[ Upstream commit 3f936169 ] In rtl_usb_probe if allocation for usb_data fails the allocated hw should be released. In addition the allocated rtlpriv->usb_data should be released on error handling path. Signed-off-by:
-
Connor Kuehl authored
[ Upstream commit 22824194 ] Inside a nested 'else' block at the beginning of this function is a call that assigns 'psta' to the return value of 'rtw_get_stainfo()'. If 'rtw_get_stainfo()' returns NULL and the flow of control reaches the 'else if' where 'psta' is dereferenced, then we will dereference a NULL pointer. Fix this by checking if 'psta' is not NULL before reading its 'psta->qos_option' data member. Addresses-Coverity: ("Dereference null return value") Signed-off-by:
Connor Kuehl <connor.kuehl@canonical.com> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Link: https://lore.kernel.org/r/20190926150317.5894-1-connor.kuehl@canonical.comSigned-off-by:
-
Navid Emamdoost authored
[ Upstream commit ca312438 ] In rtl8192_tx on error handling path allocated urbs and also skb should be released. Signed-off-by:
-
Lukasz Majewski authored
[ Upstream commit 9f918a72 ] This change is necessary for spidev devices (e.g. /dev/spidev3.0) working in the slave mode (like NXP's dspi driver for Vybrid SoC). When SPI HW works in this mode - the master is responsible for providing CS and CLK signals. However, when some fault happens - like for example distortion on SPI lines - the SPI Linux driver needs a chance to recover from this abnormal situation and prepare itself for next (correct) transmission. This change doesn't pose any threat on drivers working in master mode as spi_slave_abort() function checks if SPI slave mode is supported. Signed-off-by:
Lukasz Majewski <lukma@denx.de> Link: https://lore.kernel.org/r/20190924110547.14770-2-lukma@denx.deSigned-off-by:
kbuild test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20190925091143.15468-2-lukma@denx.deSigned-off-by:
-
Christian König authored
[ Upstream commit 6817bf28 ] Need to make sure that we actually dropping the right fence. Could be done with RCU as well, but to complicated for a fix. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Chunming Zhou <david1.zhou@amd.com> Signed-off-by:
-
Krzysztof Wilczynski authored
[ Upstream commit f552fde9 ] Separate the declaration of struct bh1750_chip_info from definition of bh1750_chip_info_tbl[] in a single statement as it makes the code hard to read, and with the extra newline it makes it look as if the bh1750_chip_info_tbl[] had no explicit type. This change also resolves the following compiler warning about the unusual position of the static keyword that can be seen when building with warnings enabled (W=1): drivers/iio/light/bh1750.c:64:1: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration] Related to commit 3a11fbb0 ("iio: light: add support for ROHM BH1710/BH1715/BH1721/BH1750/BH1751 ambient light sensors"). Signed-off-by:
Krzysztof Wilczynski <kw@linux.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Brian Masney authored
[ Upstream commit 2708e876 ] Silence two warning messages that occur due to -EPROBE_DEFER errors to help cleanup the system boot log. Signed-off-by:
Brian Masney <masneyb@onstation.org> Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190815004854.19860-4-masneyb@onstation.orgSigned-off-by:
-
Laurent Pinchart authored
[ Upstream commit 65abbda8 ] Panels must be initialised with drm_panel_init(). Add the missing function call in the panel-raspberrypi-touchscreen.c and panel-sitronix-st7789v.c drivers. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190823193245.23876-2-laurent.pinchart@ideasonboard.comSigned-off-by:
-
Sean Paul authored
[ Upstream commit 268de653 ] Spec says[1] Allocated_PBN is 16 bits [1]- DisplayPort 1.2 Spec, Section 2.11.9.8, Table 2-98 Fixes: ad7f8a1f ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Lyude Paul <lyude@redhat.com> Cc: Todd Previte <tprevite@gmail.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190829165223.129662-1-sean@poorly.runSigned-off-by:
-
Takashi Iwai authored
commit 42fb6b1d upstream. CA0132 has the delayed HP jack detection code that is invoked from the unsol handler, but it does a few weird things: it contains the cancel of a work inside the work handler, and yet it misses the cancel-sync call at (runtime-)suspend. This patch addresses those issues. Fixes: 15c2b3cc ("ALSA: hda/ca0132 - Fix possible workqueue stall") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191213085111.22855-4-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
