Select Git revision
Search by author
- Any Author
- authors
-
Alessandro Pecugi alessandro.pecugi
-
Andrea Da Col
andrea.dacol
-
Andrii Sosiuk
andrii.sosiuk
-
Carlo Ferriolo carlo.ferriolo
-
Christian Stimming
christian.stimming
-
Christos Karampeazis
-
CI Variables Management Service Account service_account_ci_vars_management
-
Costanza Vasai costanza.vasai
-
Daniel Rinaldi daniel.rinaldi
-
Davide Cardillo
davide.cardillo
-
Dietmar Muscholik dietmar.muscholik
-
Dmitry Petrov dmitry.petrov
-
Elias Radi elias.radi
-
Ettore Chimenti
ektor5
-
Fabio Falsini
fabio.falsini
-
Fabrizio Benvenuti fabrizio.benvenuti
-
Felix Gerking felix.gerking
-
Gianfranco Mariotti
gianfranco.mariotti
-
GitBot
gitbot
-
Git Bot Service Account
service_account_gitbot
- May 14, 2021
-
-
kernel test robot authored
[ Upstream commit c4d74f0f ] Function "for_each_child_of_node" should have of_node_put() before goto. Generated by: scripts/coccinelle/iterators/for_each_child.cocci Fixes: 82c2d813 ("coccinelle: iterators: Add for_each_child.cocci script") CC: Sumera Priyadarsini <sylphrenadin@gmail.com> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Julia Lawall <julia.lawall@inria.fr> Reviewed-by:
Frank Rowand <frank.rowand@sony.com> Tested-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Felix Kuehling authored
[ Upstream commit 1e870685 ] Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link against the exported functions. If the GPU driver is built-in but the IOMMU driver is a loadable module, the kfd_iommu.c file is indeed built but does not work: x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_bind_process_to_device': kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid' x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_unbind_process': kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid' x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_suspend': kfd_iommu.c:(.text+0x966): undefined reference to `amd_iommu_set_invalidate_ctx_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to `amd_iommu_set_invalid_ppr_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to `amd_iommu_free_device' x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_resume': kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device' x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to `amd_iommu_set_invalidate_ctx_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to `amd_iommu_set_invalid_ppr_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to `amd_iommu_bind_pasid' x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to `amd_iommu_set_invalidate_ctx_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to `amd_iommu_set_invalid_ppr_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to `amd_iommu_free_device' Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols are reachable by the amdkfd driver. Output a warning if they are not, because that may not be what the user was expecting. Fixes: 64d1c3a4 ("drm/amdkfd: Centralize IOMMUv2 code and make it conditional") Reported-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit ba11bbf3 ] The "s3a_buf" is freed along with all the other items on the "asd->s3a_stats" list. It leads to a double free and a use after free. Link: https://lore.kernel.org/linux-media/X9dSO3RGf7r0pq2k@mwanda Fixes: ad85094b ("Revert "media: staging: atomisp: Remove driver"") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 9baa3d64 ] There a 3 array for-loops that don't check the upper bounds of the index into arrays and this may lead to potential out-of-bounds reads. Fix this by adding array size upper bounds checks to be full safe. Addresses-Coverity: ("Out-of-bounds read") Link: https://lore.kernel.org/linux-media/20201007121628.20676-1-colin.king@canonical.com Fixes: 33382911 ("[media] m88rs6000t: add new dvb-s/s2 tuner for integrated chip M88RS6000") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Souptick Joarder authored
[ Upstream commit 16a5dcf7 ] Inside alloc_user_pages() based on flag value either pin_user_pages() or get_user_pages_fast() will be called. However, these API might fail. But free_user_pages() called in error handling path doesn't bother about return value and will try to unpin bo->pgnr pages, which is incorrect. Fix this by passing the page_nr to free_user_pages(). If page_nr > 0 pages will be unpinned based on bo->mem_type. This will also take care of non error handling path. allocation") Link: https://lore.kernel.org/linux-media/1601219284-13275-1-git-send-email-jrdr.linux@gmail.com Fixes: 14a638ab ("media: atomisp: use pin_user_pages() for memory Signed-off-by:
Souptick Joarder <jrdr.linux@gmail.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Ira Weiny <ira.weiny@intel.com> Reviewed-by:
-
Colin Ian King authored
[ Upstream commit 6045b01d ] In the case where the call to lm3554_platform_data_func returns an error there is a memory leak on the error return path of object flash. Fix this by adding an error return path that will free flash and rename labels fail2 to fail3 and fail1 to fail2. Link: https://lore.kernel.org/linux-media/20200902165852.201155-1-colin.king@canonical.com Fixes: 9289cdf3 ("staging: media: atomisp: Convert to GPIO descriptors") Signed-off-by:
-
Liu Ying authored
[ Upstream commit c451ee14 ] The media bus bit width of MEDIA_BUS_FMT_RGB101010_1X30 is 30. So, 'Bit31' and 'Bit30' cells for the 'MEDIA_BUS_FMT_RGB101010_1X30' row should be spaces instead of '0's. Fixes: 54f38fca ("media: docs: move uAPI book to userspace-api/media") Signed-off-by:
Liu Ying <victor.liu@nxp.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Wei Yongjun authored
[ Upstream commit e61f9ea2 ] In case of error, the function i2c_new_dummy_device() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: e6089fec ("media: m88ds3103: Add support for ds3103b demod") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Jia-Ju Bai authored
[ Upstream commit f3d384e3 ] When sun6i_video_remote_subdev() returns NULL to subdev, no error return code of sun6i_video_start_streaming() is assigned. To fix this bug, ret is assigned with -EINVAL in this case. Reported-by:
TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Fixes: 5cc7522d ("media: sun6i: Add support for Allwinner CSI V3s") Acked-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 5a465c53 ] If an error occurs after a successful 'of_icc_get()' call, it must be undone. Use 'devm_of_icc_get()' instead of 'of_icc_get()' to avoid the leak. Update the remove function accordingly and axe the now unneeded 'icc_put()' calls. Fixes: 32f0a6dd ("media: venus: Use on-chip interconnect API") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by:
-
Noralf Trønnes authored
[ Upstream commit dc659a4e ] drm_helper_hpd_irq_event() checks the epoch counter to determine connector status change. This was introduced in commit 5186421c ("drm: Introduce epoch counter to drm_connector"). Do the same for output_poll_execute() so it can detect other changes beside connection status value changes. v2: - Add Fixes tag (Daniel) Fixes: 5186421c ("drm: Introduce epoch counter to drm_connector") Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210313112545.37527-3-noralf@tronnes.org Signed-off-by:
-
Jae Hyun Yoo authored
[ Upstream commit 3536169f ] Video engine uses eclk and vclk for its clock sources and its reset control is coupled with eclk so the current clock enabling sequence works like below. Enable eclk De-assert Video Engine reset 10ms delay Enable vclk It introduces improper reset on the Video Engine hardware and eventually the hardware generates unexpected DMA memory transfers that can corrupt memory region in random and sporadic patterns. This issue is observed very rarely on some specific AST2500 SoCs but it causes a critical kernel panic with making a various shape of signature so it's extremely hard to debug. Moreover, the issue is observed even when the video engine is not actively used because udevd turns on the video engine hardware for a short time to make a query in every boot. To fix this issue, this commit changes the clock handling logic to make the reset de-assertion triggered after enabling both eclk and vclk. Also, it adds clk_unprepare call for a case when probe fails. clk: ast2600: fix reset settings for eclk and vclk Video engine reset setting should be coupled with eclk to match it with the setting for previous Aspeed SoCs which is defined in clk-aspeed.c since all Aspeed SoCs are sharing a single video engine driver. Also, reset bit 6 is defined as 'Video Engine' reset in datasheet so it should be de-asserted when eclk is enabled. This commit fixes the setting. Fixes: d2b4387f ("media: platform: Add Aspeed Video Engine driver") Signed-off-by:
Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> Reviewed-by:
Joel Stanley <joel@jms.id.au> Reviewed-by:
Eddie James <eajames@linux.ibm.com> Fixes: d3d04f6c ("clk: Add support for AST2600 SoC") Reviewed-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Dafna Hirschfeld authored
[ Upstream commit cbe8373c ] When setting the source media bus code in the resizer, we first check that the current media bus code in the source is yuv encoded format. This is done by retrieving the data from the formats list of the isp entity. This cause a crash when the media bus code on the source is YUYV8_1_5X8 which is not supported by the isp entity. Instead we should test the sink format of the resizer which is guaranteed to be supported by the isp entity. Fixes: 251b6eeb ("media: staging: rkisp1: rsz: Add support to more YUV encoded mbus codes on src pad") Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Acked-by:
Helen Koike <helen.koike@collabora.com> Tested-by:
Sebastian Fricke <sebastian.fricke.linux@gmail.com> Signed-off-by:
-
Yang Yingliang authored
[ Upstream commit 8938c48f ] If omap4iss_get() failed, it need return error code in iss_probe(). Fixes: 59f0ad80 ("[media] v4l: omap4iss: Add support for OMAP4...") Reported-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Tasos Sahanidis authored
[ Upstream commit e56429b0 ] The new AMD IOMMU DMA implementation concatenates sglist entries under certain conditions, and because saa7146 accessed the length member directly, it did not support this scenario. This fixes IO_PAGE_FAULTs by using the sg_dma_len macro. Fixes: be62dbf5 ("iommu/amd: Convert AMD iommu driver to the dma-iommu api") Signed-off-by:
Tasos Sahanidis <tasos@tasossah.com> Signed-off-by:
-
Tasos Sahanidis authored
[ Upstream commit 4e1cb753 ] The new AMD IOMMU DMA implementation concatenates sglist entries under certain conditions, and because saa7134 accessed the length member directly, it did not support this scenario. This fixes IO_PAGE_FAULTs and choppy DMA audio by using the sg_dma_len macro. Fixes: be62dbf5 ("iommu/amd: Convert AMD iommu driver to the dma-iommu api") Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 5cde22fc ] Currently the chroma_flags and alpha_flags are being zero'd with a bit-wise mask and the following statement should be bit-wise or'ing in the new flag bits but instead is making a direct assignment. Fix this by using the |= operator rather than an assignment. Addresses-Coverity: ("Unused value") Fixes: ef834f78 ("[media] vivid: add the video capture and output parts") Signed-off-by:
-
Zhouyi Zhou authored
[ Upstream commit 6494ccb9 ] In rcu_nmi_enter(), there is an erroneous instrumentation_end() in the second branch of the "if" statement. Oddly enough, "objtool check -f vmlinux.o" fails to complain because it is unable to correctly cover all cases. Instead, objtool visits the third branch first, which marks following trace_rcu_dyntick() as visited. This commit therefore removes the spurious instrumentation_end(). Fixes: 04b25a49 ("rcu: Mark rcu_nmi_enter() call to rcu_cleanup_after_idle() noinstr") Reported-by Neeraj Upadhyay <neeraju@codeaurora.org> Signed-off-by:
Zhouyi Zhou <zhouzhouyi@gmail.com> Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Signed-off-by:
-
David Howells authored
[ Upstream commit 6e1eb04a ] Fix afs_apply_status() to mask off the irrelevant bits from status->mode when OR'ing them into i_mode. This can happen when a 3rd party chmod occurs. Also fix afs_inode_init_from_status() to mask off the mode bits when initialising i_mode. Fixes: 260a9803 ("[AFS]: Add "directory write" support.") Reported-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Valentin Schneider authored
[ Upstream commit 39a2a6eb ] Syzbot reported a handful of occurrences where an sd->nr_balance_failed can grow to much higher values than one would expect. A successful load_balance() resets it to 0; a failed one increments it. Once it gets to sd->cache_nice_tries + 3, this *should* trigger an active balance, which will either set it to sd->cache_nice_tries+1 or reset it to 0. However, in case the to-be-active-balanced task is not allowed to run on env->dst_cpu, then the increment is done without any further modification. This could then be repeated ad nauseam, and would explain the absurdly high values reported by syzbot (86, 149). VincentG noted there is value in letting sd->cache_nice_tries grow, so the shift itself should be fixed. That means preventing: """ If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. """ Thus we need to cap the shift exponent to BITS_PER_TYPE(typeof(lefthand)) - 1. I had a look around for other similar cases via coccinelle: @expr@ position pos; expression E1; expression E2; @@ ( E1 >> E2@pos | E1 >> E2@pos ) @cst depends on expr@ position pos; expression expr.E1; constant cst; @@ ( E1 >> cst@pos | E1 << cst@pos ) @script:python depends on !cst@ pos << expr.pos; exp << expr.E2; @@ # Dirty hack to ignore constexpr if exp.upper() != exp: coccilib.report.print_report(pos[0], "Possible UB shift here") The only other match in kernel/sched is rq_clock_thermal() which employs sched_thermal_decay_shift, and that exponent is already capped to 10, so that one is fine. Fixes: 5a7f5559 ("sched/fair: Relax constraint on task's load during load balance") Reported-by:
<syzbot+d7581744d5fd27c9fbe1@syzkaller.appspotmail.com> Signed-off-by:
Valentin Schneider <valentin.schneider@arm.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Link: http://lore.kernel.org/r/000000000000ffac1205b9a2112f@google.com Signed-off-by:
-
Linus Walleij authored
[ Upstream commit d0c5ac04 ] A recent patch renaming MIPI_DSI_MODE_EOT_PACKET to MIPI_DSI_MODE_NO_EOT_PACKET brought to light the misunderstanding in the current MCDE driver and all its associated panel drivers that MIPI_DSI_MODE_EOT_PACKET would mean "use EOT packet" when in fact it means the reverse. Fix it up by implementing the flag right in the MCDE DSI driver and remove the flag from panels that actually want the EOT packet. Suggested-by:
Nicolas Boichat <drinkcat@chromium.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
Dan Carpenter authored
[ Upstream commit 8e6fafd5 ] The hdcp_i2c_offsets[] array did not have an entry for HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one read overflow. I added an entry and copied the 0x0 value for the offset from similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c. I also declared several of these arrays as having HDCP_MESSAGE_ID_MAX entries. This doesn't change the code, but it's just a belt and suspenders approach to try future proof the code. Fixes: 4c283fda ("drm/amd/display: Add HDCP module") Reviewed-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
-
Marek Vasut authored
[ Upstream commit 99e36044 ] The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW or DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode. Therefore, no matter what polarity the next bridge or display might require, these flags are never set, and thus the LTDC GCR_DEPOL and GCR_PCPOL bits are never set and the LTDC behaves as if both DISPLAY_FLAGS_PIXDATA_POSEDGE and DISPLAY_FLAGS_DE_HIGH were always set. The fix for this problem is taken almost verbatim from MXSFB driver. In case there is a bridge attached to the LTDC, the bridge might have extra polarity requirements, so extract bus_flags from the bridge and use them for LTDC configuration. Otherwise, extract bus_flags from the connector, which is the display. Fixes: b759012c ("drm/stm: Add STM32 LTDC driver") Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Yannick Fertre <yannick.fertre@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Antonio Borneo <antonio.borneo@st.com> Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Philippe Cornu <philippe.cornu@st.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Yannick Fertre <yannick.fertre@st.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com To: dri-devel@lists.freedesktop.org Tested-by:
Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by:
Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210127110756.125570-1-marex@denx.de Signed-off-by:
-
Quanyang Wang authored
[ Upstream commit f1a75f4d ] When run xrandr to change resolution on Beaglebone Black board, it will print the error information: root@beaglebone:~# xrandr -display :0 --output HDMI-1 --mode 720x400 [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:32:tilcdc crtc] commit wait timed out [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:34:HDMI-A-1] commit wait timed out [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:31:plane-0] commit wait timed out tilcdc 4830e000.lcdc: already pending page flip! This is because there is operation sequence as below: drm_atomic_connector_commit_dpms(mode is DRM_MODE_DPMS_OFF): ... drm_atomic_helper_setup_commit <- init_completion(commit_A->flip_done) drm_atomic_helper_commit_tail tilcdc_crtc_atomic_disable tilcdc_plane_atomic_update <- drm_crtc_send_vblank_event in tilcdc_crtc_irq is skipped since tilcdc_crtc->enabled is 0 tilcdc_crtc_atomic_flush <- drm_crtc_send_vblank_event is skipped since crtc->state->event is set to be NULL in tilcdc_plane_atomic_update drm_mode_setcrtc: ... drm_atomic_helper_setup_commit <- init_completion(commit_B->flip_done) drm_atomic_helper_wait_for_dependencies drm_crtc_commit_wait <- wait for commit_A->flip_done completing Just as shown above, the steps which could complete commit_A->flip_done are all skipped and commit_A->flip_done will never be completed. This will result a time-out ERROR when drm_crtc_commit_wait check the commit_A->flip_done. So add drm_crtc_send_vblank_event in tilcdc_crtc_atomic_disable to complete commit_A->flip_done. Fixes: cb345dec ("drm/tilcdc: Use standard drm_atomic_helper_commit") Signed-off-by:
Quanyang Wang <quanyang.wang@windriver.com> Reviewed-by:
Jyri Sarha <jyri.sarha@iki.fi> Tested-by:
-
Dan Carpenter authored
[ Upstream commit 5ffa8285 ] The intent here was to return negative error codes but it actually returns positive values. The problem is that type promotion with ternary operations is quite complicated. "ret" is an int. "copied" is a u32. And the snoop_file_read() function returns long. What happens is that "ret" is cast to u32 and becomes positive then it's cast to long and it's still positive. Fix this by removing the ternary so that "ret" is type promoted directly to long. Fixes: 3772e5da ("drivers/misc: Aspeed LPC snoop output using misc chardev") Signed-off-by:
Patrick Venture <venture@google.com> Link: https://lore.kernel.org/r/YIE90PSXsMTa2Y8n@mwanda Link: https://lore.kernel.org/r/20210423000919.1249474-1-joel@jms.id.au ' Signed-off-by:
-
Paul Durrant authored
[ Upstream commit d75e7f63 ] Prior to commit 4a8c31a1 ("xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the behaviour of xen-blkback when connecting to a frontend was: - read 'ring-page-order' - if not present then expect a single page ring specified by 'ring-ref' - else expect a ring specified by 'ring-refX' where X is between 0 and 1 << ring-page-order This was correct behaviour, but was broken by the afforementioned commit to become: - read 'ring-page-order' - if not present then expect a single page ring (i.e. ring-page-order = 0) - expect a ring specified by 'ring-refX' where X is between 0 and 1 << ring-page-order - if that didn't work then see if there's a single page ring specified by 'ring-ref' This incorrect behaviour works most of the time but fails when a frontend that sets 'ring-page-order' is unloaded and replaced by one that does not because, instead of reading 'ring-ref', xen-blkback will read the stale 'ring-ref0' left around by the previous frontend will try to map the wrong grant reference. This patch restores the original behaviour. Fixes: 4a8c31a1 ("xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront") Signed-off-by:
Paul Durrant <pdurrant@amazon.com> Reviewed-by:
Dongli Zhang <dongli.zhang@oracle.com> Reviewed-by:
"Roger Pau Monné" <roger.pau@citrix.com> Link: https://lore.kernel.org/r/20210202175659.18452-1-paul@xen.org Signed-off-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
-
Dario Binacchi authored
[ Upstream commit e2a5e844 ] Data received during half-duplex transmission must be filtered. If the target device responds quickly, emptying the FIFO at the end of the transmission can erase not only the echo characters but also part of the response message. By keeping the receive interrupt enabled even during transmission, it allows you to filter each echo character and only in a number equal to those transmitted. The issue was generated by a target device that started responding 240us later having received a request in communication at 115200bps. Sometimes, some messages received by the target were missing some of the first bytes. Fixes: 3a13884a ("tty/serial: omap: empty the RX FIFO at the end of half-duplex TX") Signed-off-by:
Dario Binacchi <dariobin@libero.it> Link: https://lore.kernel.org/r/20210418094705.27014-1-dariobin@libero.it Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Dario Binacchi authored
[ Upstream commit 45f6b6db ] There are rs485 transceivers (e.g. MAX13487E/MAX13488E) which automatically disable or enable the driver and receiver to keep the bus in the correct state. In these cases we don't need a GPIO for flow control. Fixes: 4a0ac0f5 ("OMAP: add RS485 support") Signed-off-by:
-
Tetsuo Handa authored
[ Upstream commit c0070e1e ] syzbot is reporting hung task due to flood of tty_warn(tty, "%s: tty->count = 1 port count = %d\n", __func__, port->count); message [1], for ioctl(TIOCVHANGUP) prevents tty_port_close() from decrementing port->count due to tty_hung_up_p() == true. ---------- #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/ioctl.h> #include <unistd.h> int main(int argc, char *argv[]) { int i; int fd[10]; for (i = 0; i < 10; i++) fd[i] = open("/dev/ttyprintk", O_WRONLY); ioctl(fd[0], TIOCVHANGUP); for (i = 0; i < 10; i++) close(fd[i]); close(open("/dev/ttyprintk", O_WRONLY)); return 0; } ---------- When TTY hangup happens, port->count needs to be reset via "struct tty_operations"->hangup callback. [1] https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a Reported-by:
syzbot <syzbot+43e93968b964e369db0b@syzkaller.appspotmail.com> Reported-by:
syzbot <syzbot+3ed715090790806d8b18@syzkaller.appspotmail.com> Tested-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Fixes: 24b4b67d ("add ttyprintk driver") Link: https://lore.kernel.org/r/17e0652d-89b7-c8c0-fb53-e7566ac9add4@i-love.sakura.ne.jp Signed-off-by:
-
Artur Petrosyan authored
[ Upstream commit 24d209db ] When core is in hibernation in host mode and a device cable was connected then driver exited from device hibernation. However, registers saved for host mode and when exited from device hibernation register restore would be done for device register which was wrong because there was no device registers stored to restore. - Added dwc_handle_gpwrdn_disc_det() function which handles gpwrdn disconnect detect flow and exits hibernation without restoring the registers. - Updated exiting from hibernation in GPWRDN_STS_CHGINT with calling dwc_handle_gpwrdn_disc_det() function. Here no register is restored which is the solution described above. Fixes: 65c9c4c6 ("usb: dwc2: Add dwc2_handle_gpwrdn_intr() handler") Acked-by:
Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> Signed-off-by:
Artur Petrosyan <Arthur.Petrosyan@synopsys.com> Signed-off-by:
-
Artur Petrosyan authored
[ Upstream commit c2db8d7b ] Added setting "port_connect_status_change" flag to "1" in order to re-enumerate, because after exit from hibernation port connection status is not detected. Fixes: c5c403dc ("usb: dwc2: Add host/device hibernation functions") Acked-by:
-
Chris von Recklinghausen authored
[ Upstream commit f5d1499a ] Hibernation fails on a system in fips mode because md5 is used for the e820 integrity check and is not available. Use crc32 instead. The check is intended to detect whether the E820 memory map provided by the firmware after cold boot unexpectedly differs from the one that was in use when the hibernation image was created. In this case, the hibernation image cannot be restored, as it may cover memory regions that are no longer available to the OS. A non-cryptographic checksum such as CRC-32 is sufficient to detect such inadvertent deviations. Fixes: 62a03def ("PM / hibernate: Verify the consistent of e820 memory map by md5 digest") Reviewed-by:
Eric Biggers <ebiggers@google.com> Tested-by:
Dexuan Cui <decui@microsoft.com> Reviewed-by:
Chris von Recklinghausen <crecklin@redhat.com> [ rjw: Subject edit ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Michael Kelley authored
[ Upstream commit 77db0ec8 ] When running in Azure, disks may be connected to a Linux VM with read/write caching enabled. If a VM panics and issues a VMbus UNLOAD request to Hyper-V, the response is delayed until all dirty data in the disk cache is flushed. In extreme cases, this flushing can take 10's of seconds, depending on the disk speed and the amount of dirty data. If kdump is configured for the VM, the current 10 second timeout in vmbus_wait_for_unload() may be exceeded, and the UNLOAD complete message may arrive well after the kdump kernel is already running, causing problems. Note that no problem occurs if kdump is not enabled because Hyper-V waits for the cache flush before doing a reboot through the BIOS/UEFI code. Fix this problem by increasing the timeout in vmbus_wait_for_unload() to 100 seconds. Also output periodic messages so that if anyone is watching the serial console, they won't think the VM is completely hung. Fixes: 911e1987 ("Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload") Signed-off-by:
Michael Kelley <mikelley@microsoft.com> Reviewed-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Link: https://lore.kernel.org/r/1618894089-126662-1-git-send-email-mikelley@microsoft.com Signed-off-by:
Wei Liu <wei.liu@kernel.org> Signed-off-by:
-
Paul Fertser authored
[ Upstream commit f0253143 ] Certain VRs might be configured to use only the first output channel and so the mode for the second will be 0. Handle this gracefully. Fixes: b9fa0a3a ("hwmon: (pmbus/core) Add support for vid mode detection per page bases") Signed-off-by:
Paul Fertser <fercerpav@gmail.com> Link: https://lore.kernel.org/r/20210416102926.13614-1-fercerpav@gmail.com Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Ingo Molnar authored
[ Upstream commit c2209ea5 ] When KEXEC is disabled, the UV build fails: arch/x86/platform/uv/uv_nmi.c:875:14: error: ‘uv_nmi_kexec_failed’ undeclared (first use in this function) Since uv_nmi_kexec_failed is only defined in the KEXEC_CORE #ifdef branch, this code cannot ever have been build tested: if (main) pr_err("UV: NMI kdump: KEXEC not supported in this kernel\n"); atomic_set(&uv_nmi_kexec_failed, 1); Nor is this use possible in uv_handle_nmi(): atomic_set(&uv_nmi_kexec_failed, 0); These bugs were introduced in this commit: d0a9964e: ("x86/platform/uv: Implement simple dump failover if kdump fails") Which added the uv_nmi_kexec_failed assignments to !KEXEC code, while making the definition KEXEC-only - apparently without testing the !KEXEC case. Instead of complicating the #ifdef maze, simplify the code by requiring X86_UV to depend on KEXEC_CORE. This pattern is present in other architectures as well. ( We'll remove the untested, 7 years old !KEXEC complications from the file in a separate commit. ) Fixes: d0a9964e: ("x86/platform/uv: Implement simple dump failover if kdump fails") Signed-off-by:
-
Quanyang Wang authored
[ Upstream commit 126bdb60 ] The spi controller supports 44-bit address space on AXI in DMA mode, so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping. In addition, if dma_map_single fails, it should return immediately instead of continuing doing the DMA operation which bases on invalid address. This fixes the following crash which occurs in reading a big block from flash: [ 123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots) [ 123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped [ 123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0 [ 123.792536] Mem abort info: [ 123.795313] ESR = 0x96000145 [ 123.798351] EC = 0x25: DABT (current EL), IL = 32 bits [ 123.803655] SET = 0, FnV = 0 [ 123.806693] EA = 0, S1PTW = 0 [ 123.809818] Data abort info: [ 123.812683] ISV = 0, ISS = 0x00000145 [ 123.816503] CM = 1, WnR = 1 [ 123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000 [ 123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000 [ 123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP Fixes: 1c26372e ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework") Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Quanyang Wang authored
[ Upstream commit a2c5bedb ] When handling op->addr, it is using the buffer "tmpbuf" which has been freed. This will trigger a use-after-free KASAN warning. Let's use temporary variables to store op->addr.val and op->cmd.opcode to fix this issue. Fixes: 1c26372e ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework") Signed-off-by:
-
Quanyang Wang authored
[ Upstream commit 799f923f ] After calling platform_set_drvdata(pdev, xqspi) in probe, the return value of dev_get_drvdata(dev) is a pointer to struct zynqmp_qspi but not struct spi_controller. A wrong structure type passing to the functions spi_controller_suspend/resume will hang the system. And we should check the return value of spi_controller_suspend, if an error is returned, return it to PM subsystem to stop suspend. Also, GQSPI_EN_MASK should be written to GQSPI_EN_OFST to enable the spi controller in zynqmp_qspi_resume since it was disabled in zynqmp_qspi_suspend before. Fixes: 1c26372e ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework") Signed-off-by:
-
Quanyang Wang authored
[ Upstream commit c6bdae08 ] The clks "pclk" and "ref_clk" are enabled twice during the probe. The first time is in the function zynqmp_qspi_probe and the second time is in zynqmp_qspi_setup_op which is called by devm_spi_register_controller. Then calling zynqmp_qspi_remove (rmmod this module) to disable these clks will trigger a warning as below: [ 309.124604] Unpreparing enabled qspi_ref [ 309.128641] WARNING: CPU: 1 PID: 537 at drivers/clk/clk.c:824 clk_core_unprepare+0x108/0x110 Since pm_runtime works now, clks can be enabled/disabled by calling zynqmp_runtime_suspend/resume. So we don't need to enable these clks explicitly in zynqmp_qspi_setup_op. Remove them to fix this issue. And remove clk enabling/disabling in zynqmp_qspi_resume because there is no spi transfer operation so enabling ref_clk is redundant meanwhile pclk is not disabled for it is shared with other peripherals. Furthermore replace clk_enable/disable with clk_prepare_enable and clk_disable_unprepare in runtime_suspend/resume functions. Fixes: 1c26372e ("spi: spi-zynqmp-gqspi: Update driver to use spi-mem framework") Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 3e9bf43f ] The "open_info" variable is added to the &vmbus_connection.chn_msg_list, but the error handling frees "open_info" without removing it from the list. This will result in a use after free. First remove it from the list, and then free it. Fixes: 6f3d791f ("Drivers: hv: vmbus: Fix rescind handling issues") Signed-off-by:
Andrea Parri <parri.andrea@gmail.com> Link: https://lore.kernel.org/r/YHV3XLCot6xBS44r@mwanda Signed-off-by:
-
