--- /dev/null
+From d288bddd8374e0a043ac9dde64a1ae6a09411d74 Mon Sep 17 00:00:00 2001
+From: Martin Fuzzey <martin.fuzzey@flowbird.group>
+Date: Wed, 29 Jan 2020 14:40:06 +0100
+Subject: dmaengine: imx-sdma: fix context cache
+
+From: Martin Fuzzey <martin.fuzzey@flowbird.group>
+
+commit d288bddd8374e0a043ac9dde64a1ae6a09411d74 upstream.
+
+There is a DMA problem with the serial ports on i.MX6.
+
+When the following sequence is performed:
+
+1) Open a port
+2) Write some data
+3) Close the port
+4) Open a *different* port
+5) Write some data
+6) Close the port
+
+The second write sends nothing and the second close hangs.
+If the first close() is omitted it works.
+
+Adding logs to the the UART driver shows that the DMA is being setup but
+the callback is never invoked for the second write.
+
+This used to work in 4.19.
+
+Git bisect leads to:
+ ad0d92d: "dmaengine: imx-sdma: refine to load context only once"
+
+This commit adds a "context_loaded" flag used to avoid unnecessary context
+setups.
+However the flag is only reset in sdma_channel_terminate_work(),
+which is only invoked in a worker triggered by sdma_terminate_all() IF
+there is an active descriptor.
+
+So, if no active descriptor remains when the channel is terminated, the
+flag is not reset and, when the channel is later reused the old context
+is used.
+
+Fix the problem by always resetting the flag in sdma_free_chan_resources().
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
+Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once")
+Reviewed-by: Fabio Estevam <festevam@gmail.com>
+Link: https://lore.kernel.org/r/1580305274-27274-1-git-send-email-martin.fuzzey@flowbird.group
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/dma/imx-sdma.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/dma/imx-sdma.c
++++ b/drivers/dma/imx-sdma.c
+@@ -1335,6 +1335,7 @@ static void sdma_free_chan_resources(str
+
+ sdmac->event_id0 = 0;
+ sdmac->event_id1 = 0;
++ sdmac->context_loaded = false;
+
+ sdma_set_channel_priority(sdmac, 0);
+
--- /dev/null
+From 25962e1a7f1d522f1b57ead2f266fab570042a70 Mon Sep 17 00:00:00 2001
+From: Frieder Schrempf <frieder.schrempf@kontron.de>
+Date: Tue, 25 Feb 2020 08:23:20 +0000
+Subject: dmaengine: imx-sdma: Fix the event id check to include RX event for UART6
+
+From: Frieder Schrempf <frieder.schrempf@kontron.de>
+
+commit 25962e1a7f1d522f1b57ead2f266fab570042a70 upstream.
+
+On i.MX6UL/ULL and i.MX6SX the DMA event id for the RX channel of
+UART6 is '0'. To fix the broken DMA support for UART6, we change
+the check for event_id0 to include '0' as a valid id.
+
+Fixes: 1ec1e82f2510 ("dmaengine: Add Freescale i.MX SDMA support")
+Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
+Reviewed-by: Fabio Estevam <festevam@gmail.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20200225082139.7646-1-frieder.schrempf@kontron.de
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/dma/imx-sdma.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/dma/imx-sdma.c
++++ b/drivers/dma/imx-sdma.c
+@@ -1328,7 +1328,7 @@ static void sdma_free_chan_resources(str
+
+ sdma_channel_synchronize(chan);
+
+- if (sdmac->event_id0)
++ if (sdmac->event_id0 >= 0)
+ sdma_event_disable(sdmac, sdmac->event_id0);
+ if (sdmac->event_id1)
+ sdma_event_disable(sdmac, sdmac->event_id1);
+@@ -1629,7 +1629,7 @@ static int sdma_config(struct dma_chan *
+ memcpy(&sdmac->slave_config, dmaengine_cfg, sizeof(*dmaengine_cfg));
+
+ /* Set ENBLn earlier to make sure dma request triggered after that */
+- if (sdmac->event_id0) {
++ if (sdmac->event_id0 >= 0) {
+ if (sdmac->event_id0 >= sdmac->sdma->drvdata->num_events)
+ return -EINVAL;
+ sdma_event_enable(sdmac, sdmac->event_id0);
--- /dev/null
+From d171c45da874e3858a83e6377e00280a507fe2f2 Mon Sep 17 00:00:00 2001
+From: Ezequiel Garcia <ezequiel@collabora.com>
+Date: Tue, 4 Feb 2020 20:38:37 +0100
+Subject: media: hantro: Fix broken media controller links
+
+From: Ezequiel Garcia <ezequiel@collabora.com>
+
+commit d171c45da874e3858a83e6377e00280a507fe2f2 upstream.
+
+The driver currently creates a broken topology,
+with a source-to-source link and a sink-to-sink
+link instead of two source-to-sink links.
+
+Reported-by: Nicolas Dufresne <nicolas@ndufresne.ca>
+Cc: <stable@vger.kernel.org> # for v5.3 and up
+Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
+Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/media/hantro/hantro_drv.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/staging/media/hantro/hantro_drv.c
++++ b/drivers/staging/media/hantro/hantro_drv.c
+@@ -553,13 +553,13 @@ static int hantro_attach_func(struct han
+ goto err_rel_entity1;
+
+ /* Connect the three entities */
+- ret = media_create_pad_link(&func->vdev.entity, 0, &func->proc, 1,
++ ret = media_create_pad_link(&func->vdev.entity, 0, &func->proc, 0,
+ MEDIA_LNK_FL_IMMUTABLE |
+ MEDIA_LNK_FL_ENABLED);
+ if (ret)
+ goto err_rel_entity2;
+
+- ret = media_create_pad_link(&func->proc, 0, &func->sink, 0,
++ ret = media_create_pad_link(&func->proc, 1, &func->sink, 0,
+ MEDIA_LNK_FL_IMMUTABLE |
+ MEDIA_LNK_FL_ENABLED);
+ if (ret)
--- /dev/null
+From 044041cd5227ec9ccf969f4bf1cc08bffe13b9d3 Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Date: Tue, 4 Feb 2020 19:19:22 +0100
+Subject: media: mc-entity.c: use & to check pad flags, not ==
+
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+commit 044041cd5227ec9ccf969f4bf1cc08bffe13b9d3 upstream.
+
+These are bits so to test if a pad is a sink you use & but not ==.
+
+It looks like the only reason this hasn't caused problems before is that
+media_get_pad_index() is currently only used with pads that do not set the
+MEDIA_PAD_FL_MUST_CONNECT flag. So a pad really had only the SINK or SOURCE
+flag set and nothing else.
+
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Cc: <stable@vger.kernel.org> # for v5.3 and up
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/mc/mc-entity.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/mc/mc-entity.c
++++ b/drivers/media/mc/mc-entity.c
+@@ -639,9 +639,9 @@ int media_get_pad_index(struct media_ent
+ return -EINVAL;
+
+ for (i = 0; i < entity->num_pads; i++) {
+- if (entity->pads[i].flags == MEDIA_PAD_FL_SINK)
++ if (entity->pads[i].flags & MEDIA_PAD_FL_SINK)
+ pad_is_sink = true;
+- else if (entity->pads[i].flags == MEDIA_PAD_FL_SOURCE)
++ else if (entity->pads[i].flags & MEDIA_PAD_FL_SOURCE)
+ pad_is_sink = false;
+ else
+ continue; /* This is an error! */
--- /dev/null
+From 316e730f1d8bb029fe6cec2468fb2a50424485b3 Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Date: Tue, 4 Feb 2020 19:13:06 +0100
+Subject: media: v4l2-mem2mem.c: fix broken links
+
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+commit 316e730f1d8bb029fe6cec2468fb2a50424485b3 upstream.
+
+The topology that v4l2_m2m_register_media_controller() creates for a
+processing block actually created a source-to-source link and a sink-to-sink
+link instead of two source-to-sink links.
+
+Unfortunately v4l2-compliance never checked for such bad links, so this
+went unreported for quite some time.
+
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Reported-by: Nicolas Dufresne <nicolas@ndufresne.ca>
+Cc: <stable@vger.kernel.org> # for v4.19 and up
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/v4l2-core/v4l2-mem2mem.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
++++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
+@@ -809,12 +809,12 @@ int v4l2_m2m_register_media_controller(s
+ goto err_rel_entity1;
+
+ /* Connect the three entities */
+- ret = media_create_pad_link(m2m_dev->source, 0, &m2m_dev->proc, 1,
++ ret = media_create_pad_link(m2m_dev->source, 0, &m2m_dev->proc, 0,
+ MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED);
+ if (ret)
+ goto err_rel_entity2;
+
+- ret = media_create_pad_link(&m2m_dev->proc, 0, &m2m_dev->sink, 0,
++ ret = media_create_pad_link(&m2m_dev->proc, 1, &m2m_dev->sink, 0,
+ MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED);
+ if (ret)
+ goto err_rm_links0;
--- /dev/null
+From 49a56266f96f2c6608373464af8755b431ef1513 Mon Sep 17 00:00:00 2001
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Date: Tue, 4 Feb 2020 13:45:04 +0100
+Subject: media: vicodec: process all 4 components for RGB32 formats
+
+From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+
+commit 49a56266f96f2c6608373464af8755b431ef1513 upstream.
+
+Only ARGB32-type pixelformat were assumed to have 4 components, which is
+wrong since RGB32-type pixelformats may have an alpha channel, so they
+should also assume 4 color components.
+
+The XRGB32-type pixelformats really have only 3 color components, but this
+complicated matters since that creates strides that are sometimes width * 3
+and sometimes width * 4, and in fact this can result in buffer overflows.
+
+Keep things simple by just always processing all 4 color components.
+
+In the future we might want to optimize this again for the XRGB32-type
+pixelformats, but for now keep it simple and robust.
+
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Cc: <stable@vger.kernel.org> # for v5.4 and up
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/platform/vicodec/codec-v4l2-fwht.c | 34 ++++++-----------------
+ 1 file changed, 9 insertions(+), 25 deletions(-)
+
+--- a/drivers/media/platform/vicodec/codec-v4l2-fwht.c
++++ b/drivers/media/platform/vicodec/codec-v4l2-fwht.c
+@@ -27,17 +27,17 @@ static const struct v4l2_fwht_pixfmt_inf
+ { V4L2_PIX_FMT_BGR24, 3, 3, 1, 3, 3, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
+ { V4L2_PIX_FMT_RGB24, 3, 3, 1, 3, 3, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
+ { V4L2_PIX_FMT_HSV24, 3, 3, 1, 3, 3, 1, 1, 3, 1, FWHT_FL_PIXENC_HSV},
+- { V4L2_PIX_FMT_BGR32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
+- { V4L2_PIX_FMT_XBGR32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
++ { V4L2_PIX_FMT_BGR32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
++ { V4L2_PIX_FMT_XBGR32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+ { V4L2_PIX_FMT_ABGR32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+- { V4L2_PIX_FMT_RGB32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
+- { V4L2_PIX_FMT_XRGB32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
++ { V4L2_PIX_FMT_RGB32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
++ { V4L2_PIX_FMT_XRGB32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+ { V4L2_PIX_FMT_ARGB32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+- { V4L2_PIX_FMT_BGRX32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
++ { V4L2_PIX_FMT_BGRX32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+ { V4L2_PIX_FMT_BGRA32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+- { V4L2_PIX_FMT_RGBX32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_RGB},
++ { V4L2_PIX_FMT_RGBX32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+ { V4L2_PIX_FMT_RGBA32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_RGB},
+- { V4L2_PIX_FMT_HSV32, 4, 4, 1, 4, 4, 1, 1, 3, 1, FWHT_FL_PIXENC_HSV},
++ { V4L2_PIX_FMT_HSV32, 4, 4, 1, 4, 4, 1, 1, 4, 1, FWHT_FL_PIXENC_HSV},
+ { V4L2_PIX_FMT_GREY, 1, 1, 1, 1, 0, 1, 1, 1, 1, FWHT_FL_PIXENC_RGB},
+ };
+
+@@ -175,22 +175,14 @@ static int prepare_raw_frame(struct fwht
+ case V4L2_PIX_FMT_RGB32:
+ case V4L2_PIX_FMT_XRGB32:
+ case V4L2_PIX_FMT_HSV32:
+- rf->cr = rf->luma + 1;
+- rf->cb = rf->cr + 2;
+- rf->luma += 2;
+- break;
+- case V4L2_PIX_FMT_BGR32:
+- case V4L2_PIX_FMT_XBGR32:
+- rf->cb = rf->luma;
+- rf->cr = rf->cb + 2;
+- rf->luma++;
+- break;
+ case V4L2_PIX_FMT_ARGB32:
+ rf->alpha = rf->luma;
+ rf->cr = rf->luma + 1;
+ rf->cb = rf->cr + 2;
+ rf->luma += 2;
+ break;
++ case V4L2_PIX_FMT_BGR32:
++ case V4L2_PIX_FMT_XBGR32:
+ case V4L2_PIX_FMT_ABGR32:
+ rf->cb = rf->luma;
+ rf->cr = rf->cb + 2;
+@@ -198,10 +190,6 @@ static int prepare_raw_frame(struct fwht
+ rf->alpha = rf->cr + 1;
+ break;
+ case V4L2_PIX_FMT_BGRX32:
+- rf->cb = rf->luma + 1;
+- rf->cr = rf->cb + 2;
+- rf->luma += 2;
+- break;
+ case V4L2_PIX_FMT_BGRA32:
+ rf->alpha = rf->luma;
+ rf->cb = rf->luma + 1;
+@@ -209,10 +197,6 @@ static int prepare_raw_frame(struct fwht
+ rf->luma += 2;
+ break;
+ case V4L2_PIX_FMT_RGBX32:
+- rf->cr = rf->luma;
+- rf->cb = rf->cr + 2;
+- rf->luma++;
+- break;
+ case V4L2_PIX_FMT_RGBA32:
+ rf->alpha = rf->luma + 3;
+ rf->cr = rf->luma;
--- /dev/null
+From d6bc34c5ec18c3544c4b0d85963768dfbcd24184 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Fri, 14 Feb 2020 15:26:53 +0200
+Subject: perf arm-spe: Fix endless record after being terminated
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit d6bc34c5ec18c3544c4b0d85963768dfbcd24184 upstream.
+
+In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will
+be set and the event list will be disabled by evlist__disable() once.
+
+While in auxtrace_record.read_finish(), the related events will be
+enabled again, if they are continuous, the recording seems to be
+endless.
+
+If the event is disabled, don't enable it again here.
+
+Based-on-patch-by: Wei Li <liwei391@huawei.com>
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Tan Xiaojun <tanxiaojun@huawei.com>
+Cc: stable@vger.kernel.org # 5.4+
+Link: http://lore.kernel.org/lkml/20200214132654.20395-5-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/arch/arm64/util/arm-spe.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/arch/arm64/util/arm-spe.c
++++ b/tools/perf/arch/arm64/util/arm-spe.c
+@@ -165,9 +165,12 @@ static int arm_spe_read_finish(struct au
+ struct evsel *evsel;
+
+ evlist__for_each_entry(sper->evlist, evsel) {
+- if (evsel->core.attr.type == sper->arm_spe_pmu->type)
++ if (evsel->core.attr.type == sper->arm_spe_pmu->type) {
++ if (evsel->disabled)
++ return 0;
+ return perf_evlist__enable_event_idx(sper->evlist,
+ evsel, idx);
++ }
+ }
+ return -EINVAL;
+ }
--- /dev/null
+From c9f2833cb472cf9e0a49b7bcdc210a96017a7bfd Mon Sep 17 00:00:00 2001
+From: Wei Li <liwei391@huawei.com>
+Date: Fri, 14 Feb 2020 15:26:52 +0200
+Subject: perf cs-etm: Fix endless record after being terminated
+
+From: Wei Li <liwei391@huawei.com>
+
+commit c9f2833cb472cf9e0a49b7bcdc210a96017a7bfd upstream.
+
+In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will
+be set and the event list will be disabled by evlist__disable() once.
+
+While in auxtrace_record.read_finish(), the related events will be
+enabled again, if they are continuous, the recording seems to be
+endless.
+
+If the cs_etm event is disabled, we don't enable it again here.
+
+Note: This patch is NOT tested since i don't have such a machine with
+coresight feature, but the code seems buggy same as arm-spe and
+intel-pt.
+
+Tester notes:
+
+Thanks for looping, Adrian. Applied this patch and tested with
+CoreSight on juno board, it works well.
+
+Signed-off-by: Wei Li <liwei391@huawei.com>
+Reviewed-by: Leo Yan <leo.yan@linaro.org>
+Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Tested-by: Leo Yan <leo.yan@linaro.org>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Tan Xiaojun <tanxiaojun@huawei.com>
+Cc: stable@vger.kernel.org # 5.4+
+Link: http://lore.kernel.org/lkml/20200214132654.20395-4-adrian.hunter@intel.com
+[ahunter: removed redundant 'else' after 'return']
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/arch/arm/util/cs-etm.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/arch/arm/util/cs-etm.c
++++ b/tools/perf/arch/arm/util/cs-etm.c
+@@ -865,9 +865,12 @@ static int cs_etm_read_finish(struct aux
+ struct evsel *evsel;
+
+ evlist__for_each_entry(ptr->evlist, evsel) {
+- if (evsel->core.attr.type == ptr->cs_etm_pmu->type)
++ if (evsel->core.attr.type == ptr->cs_etm_pmu->type) {
++ if (evsel->disabled)
++ return 0;
+ return perf_evlist__enable_event_idx(ptr->evlist,
+ evsel, idx);
++ }
+ }
+
+ return -EINVAL;
--- /dev/null
+From 783fed2f35e2a6771c8dc6ee29b8c4b9930783ce Mon Sep 17 00:00:00 2001
+From: Wei Li <liwei391@huawei.com>
+Date: Fri, 14 Feb 2020 15:26:51 +0200
+Subject: perf intel-bts: Fix endless record after being terminated
+
+From: Wei Li <liwei391@huawei.com>
+
+commit 783fed2f35e2a6771c8dc6ee29b8c4b9930783ce upstream.
+
+In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will
+be set and the event list will be disabled by evlist__disable() once.
+
+While in auxtrace_record.read_finish(), the related events will be
+enabled again, if they are continuous, the recording seems to be
+endless.
+
+If the intel_bts event is disabled, we don't enable it again here.
+
+Note: This patch is NOT tested since i don't have such a machine with
+intel_bts feature, but the code seems buggy same as arm-spe and
+intel-pt.
+
+Signed-off-by: Wei Li <liwei391@huawei.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Tan Xiaojun <tanxiaojun@huawei.com>
+Cc: stable@vger.kernel.org # 5.4+
+Link: http://lore.kernel.org/lkml/20200214132654.20395-3-adrian.hunter@intel.com
+[ahunter: removed redundant 'else' after 'return']
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/arch/x86/util/intel-bts.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/arch/x86/util/intel-bts.c
++++ b/tools/perf/arch/x86/util/intel-bts.c
+@@ -415,9 +415,12 @@ static int intel_bts_read_finish(struct
+ struct evsel *evsel;
+
+ evlist__for_each_entry(btsr->evlist, evsel) {
+- if (evsel->core.attr.type == btsr->intel_bts_pmu->type)
++ if (evsel->core.attr.type == btsr->intel_bts_pmu->type) {
++ if (evsel->disabled)
++ return 0;
+ return perf_evlist__enable_event_idx(btsr->evlist,
+ evsel, idx);
++ }
+ }
+ return -EINVAL;
+ }
--- /dev/null
+From 2da4dd3d6973ffdfba4fa07f53240fda7ab22929 Mon Sep 17 00:00:00 2001
+From: Wei Li <liwei391@huawei.com>
+Date: Fri, 14 Feb 2020 15:26:50 +0200
+Subject: perf intel-pt: Fix endless record after being terminated
+
+From: Wei Li <liwei391@huawei.com>
+
+commit 2da4dd3d6973ffdfba4fa07f53240fda7ab22929 upstream.
+
+In __cmd_record(), when receiving SIGINT(ctrl + c), a 'done' flag will
+be set and the event list will be disabled by evlist__disable() once.
+
+While in auxtrace_record.read_finish(), the related events will be
+enabled again, if they are continuous, the recording seems to be endless.
+
+If the intel_pt event is disabled, we don't enable it again here.
+
+Before the patch:
+
+ huawei@huawei-2288H-V5:~/linux-5.5-rc4/tools/perf$ ./perf record -e \
+ intel_pt//u -p 46803
+ ^C^C^C^C^C^C
+
+After the patch:
+
+ huawei@huawei-2288H-V5:~/linux-5.5-rc4/tools/perf$ ./perf record -e \
+ intel_pt//u -p 48591
+ ^C[ perf record: Woken up 0 times to write data ]
+ Warning:
+ AUX data lost 504 times out of 4816!
+
+ [ perf record: Captured and wrote 2024.405 MB perf.data ]
+
+Signed-off-by: Wei Li <liwei391@huawei.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Tan Xiaojun <tanxiaojun@huawei.com>
+Cc: stable@vger.kernel.org # 5.4+
+Link: http://lore.kernel.org/lkml/20200214132654.20395-2-adrian.hunter@intel.com
+[ ahunter: removed redundant 'else' after 'return' ]
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/arch/x86/util/intel-pt.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/tools/perf/arch/x86/util/intel-pt.c
++++ b/tools/perf/arch/x86/util/intel-pt.c
+@@ -1099,9 +1099,12 @@ static int intel_pt_read_finish(struct a
+ struct evsel *evsel;
+
+ evlist__for_each_entry(ptr->evlist, evsel) {
+- if (evsel->core.attr.type == ptr->intel_pt_pmu->type)
++ if (evsel->core.attr.type == ptr->intel_pt_pmu->type) {
++ if (evsel->disabled)
++ return 0;
+ return perf_evlist__enable_event_idx(ptr->evlist, evsel,
+ idx);
++ }
+ }
+ return -EINVAL;
+ }
--- /dev/null
+From 582b4e55403e053d8a48ff687a05174da9cc3fb0 Mon Sep 17 00:00:00 2001
+From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
+Date: Thu, 27 Feb 2020 12:56:42 +0100
+Subject: s390/mm: fix panic in gup_fast on large pud
+
+From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
+
+commit 582b4e55403e053d8a48ff687a05174da9cc3fb0 upstream.
+
+On s390 there currently is no implementation of pud_write(). That was ok
+as long as we had our own implementation of get_user_pages_fast() which
+checked for pud protection by testing the bit directly w/o using
+pud_write(). The other callers of pud_write() are not reachable on s390.
+
+After commit 1a42010cdc26 ("s390/mm: convert to the generic
+get_user_pages_fast code") we use the generic get_user_pages_fast(), which
+does call pud_write() in pud_access_permitted() for FOLL_WRITE access on
+a large pud. Without an s390 specific pud_write(), the generic version is
+called, which contains a BUG() statement to remind us that we don't have a
+proper implementation. This results in a kernel panic.
+
+Fix this by providing an implementation of pud_write().
+
+Cc: <stable@vger.kernel.org> # 5.2+
+Fixes: 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast code")
+Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
+Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/include/asm/pgtable.h | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/arch/s390/include/asm/pgtable.h
++++ b/arch/s390/include/asm/pgtable.h
+@@ -756,6 +756,12 @@ static inline int pmd_write(pmd_t pmd)
+ return (pmd_val(pmd) & _SEGMENT_ENTRY_WRITE) != 0;
+ }
+
++#define pud_write pud_write
++static inline int pud_write(pud_t pud)
++{
++ return (pud_val(pud) & _REGION3_ENTRY_WRITE) != 0;
++}
++
+ static inline int pmd_dirty(pmd_t pmd)
+ {
+ int dirty = 1;
--- /dev/null
+From df057c914a9c219ac8b8ed22caf7da2f80c1fe26 Mon Sep 17 00:00:00 2001
+From: Niklas Schnelle <schnelle@linux.ibm.com>
+Date: Thu, 27 Feb 2020 12:17:18 +0100
+Subject: s390/pci: Fix unexpected write combine on resource
+
+From: Niklas Schnelle <schnelle@linux.ibm.com>
+
+commit df057c914a9c219ac8b8ed22caf7da2f80c1fe26 upstream.
+
+In the initial MIO support introduced in
+
+commit 71ba41c9b1d9 ("s390/pci: provide support for MIO instructions")
+
+zpci_map_resource() and zpci_setup_resources() default to using the
+mio_wb address as the resource's start address. This means users of the
+mapping, which includes most drivers, will get write combining on PCI
+Stores. This may lead to problems when drivers expect write through
+behavior when not using an explicit ioremap_wc().
+
+Cc: stable@vger.kernel.org
+Fixes: 71ba41c9b1d9 ("s390/pci: provide support for MIO instructions")
+Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
+Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/s390/pci/pci.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/s390/pci/pci.c
++++ b/arch/s390/pci/pci.c
+@@ -423,7 +423,7 @@ static void zpci_map_resources(struct pc
+
+ if (zpci_use_mio(zdev))
+ pdev->resource[i].start =
+- (resource_size_t __force) zdev->bars[i].mio_wb;
++ (resource_size_t __force) zdev->bars[i].mio_wt;
+ else
+ pdev->resource[i].start = (resource_size_t __force)
+ pci_iomap_range_fh(pdev, i, 0, 0);
+@@ -530,7 +530,7 @@ static int zpci_setup_bus_resources(stru
+ flags |= IORESOURCE_MEM_64;
+
+ if (zpci_use_mio(zdev))
+- addr = (unsigned long) zdev->bars[i].mio_wb;
++ addr = (unsigned long) zdev->bars[i].mio_wt;
+ else
+ addr = ZPCI_ADDR(entry);
+ size = 1UL << zdev->bars[i].size;
serial-8250_exar-add-support-for-acces-cards.patch
vt-selection-close-sel_buffer-race.patch
vt-selection-push-console-lock-down.patch
+vt-selection-push-sel_lock-up.patch
+media-hantro-fix-broken-media-controller-links.patch
+media-mc-entity.c-use-to-check-pad-flags-not.patch
+media-vicodec-process-all-4-components-for-rgb32-formats.patch
+media-v4l2-mem2mem.c-fix-broken-links.patch
+perf-intel-pt-fix-endless-record-after-being-terminated.patch
+perf-intel-bts-fix-endless-record-after-being-terminated.patch
+perf-cs-etm-fix-endless-record-after-being-terminated.patch
+perf-arm-spe-fix-endless-record-after-being-terminated.patch
+spi-spidev-fix-cs-polarity-if-gpio-descriptors-are-used.patch
+x86-pkeys-manually-set-x86_feature_ospke-to-preserve-existing-changes.patch
+s390-pci-fix-unexpected-write-combine-on-resource.patch
+s390-mm-fix-panic-in-gup_fast-on-large-pud.patch
+dmaengine-imx-sdma-fix-context-cache.patch
+dmaengine-imx-sdma-fix-the-event-id-check-to-include-rx-event-for-uart6.patch
--- /dev/null
+From 138c9c32f090894614899eca15e0bb7279f59865 Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Tue, 18 Feb 2020 13:08:00 +0100
+Subject: spi: spidev: Fix CS polarity if GPIO descriptors are used
+
+From: Lukas Wunner <lukas@wunner.de>
+
+commit 138c9c32f090894614899eca15e0bb7279f59865 upstream.
+
+Commit f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
+amended of_spi_parse_dt() to always set SPI_CS_HIGH for SPI slaves whose
+Chip Select is defined by a "cs-gpios" devicetree property.
+
+This change broke userspace applications which issue an SPI_IOC_WR_MODE
+ioctl() to an spidev: Chip Select polarity will be incorrect unless the
+application is changed to set SPI_CS_HIGH. And once changed, it will be
+incompatible with kernels not containing the commit.
+
+Fix by setting SPI_CS_HIGH in spidev_ioctl() (under the same conditions
+as in of_spi_parse_dt()).
+
+Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
+Reported-by: Simon Han <z.han@kunbus.com>
+Signed-off-by: Lukas Wunner <lukas@wunner.de>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Link: https://lore.kernel.org/r/fca3ba7cdc930cd36854666ceac4fbcf01b89028.1582027457.git.lukas@wunner.de
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Cc: stable@vger.kernel.org # v5.1+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spidev.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/spi/spidev.c
++++ b/drivers/spi/spidev.c
+@@ -394,6 +394,7 @@ spidev_ioctl(struct file *filp, unsigned
+ else
+ retval = get_user(tmp, (u32 __user *)arg);
+ if (retval == 0) {
++ struct spi_controller *ctlr = spi->controller;
+ u32 save = spi->mode;
+
+ if (tmp & ~SPI_MODE_MASK) {
+@@ -401,6 +402,10 @@ spidev_ioctl(struct file *filp, unsigned
+ break;
+ }
+
++ if (ctlr->use_gpio_descriptors && ctlr->cs_gpiods &&
++ ctlr->cs_gpiods[spi->chip_select])
++ tmp |= SPI_CS_HIGH;
++
+ tmp |= spi->mode & ~SPI_MODE_MASK;
+ spi->mode = (u16)tmp;
+ retval = spi_setup(spi);
--- /dev/null
+From e8c75a30a23c6ba63f4ef6895cbf41fd42f21aa2 Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Fri, 28 Feb 2020 12:54:06 +0100
+Subject: vt: selection, push sel_lock up
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+commit e8c75a30a23c6ba63f4ef6895cbf41fd42f21aa2 upstream.
+
+sel_lock cannot nest in the console lock. Thanks to syzkaller, the
+kernel states firmly:
+
+> WARNING: possible circular locking dependency detected
+> 5.6.0-rc3-syzkaller #0 Not tainted
+> ------------------------------------------------------
+> syz-executor.4/20336 is trying to acquire lock:
+> ffff8880a2e952a0 (&tty->termios_rwsem){++++}, at: tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
+>
+> but task is already holding lock:
+> ffffffff89462e70 (sel_lock){+.+.}, at: paste_selection+0x118/0x470 drivers/tty/vt/selection.c:374
+>
+> which lock already depends on the new lock.
+>
+> the existing dependency chain (in reverse order) is:
+>
+> -> #2 (sel_lock){+.+.}:
+> mutex_lock_nested+0x1b/0x30 kernel/locking/mutex.c:1118
+> set_selection_kernel+0x3b8/0x18a0 drivers/tty/vt/selection.c:217
+> set_selection_user+0x63/0x80 drivers/tty/vt/selection.c:181
+> tioclinux+0x103/0x530 drivers/tty/vt/vt.c:3050
+> vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364
+
+This is ioctl(TIOCL_SETSEL).
+Locks held on the path: console_lock -> sel_lock
+
+> -> #1 (console_lock){+.+.}:
+> console_lock+0x46/0x70 kernel/printk/printk.c:2289
+> con_flush_chars+0x50/0x650 drivers/tty/vt/vt.c:3223
+> n_tty_write+0xeae/0x1200 drivers/tty/n_tty.c:2350
+> do_tty_write drivers/tty/tty_io.c:962 [inline]
+> tty_write+0x5a1/0x950 drivers/tty/tty_io.c:1046
+
+This is write().
+Locks held on the path: termios_rwsem -> console_lock
+
+> -> #0 (&tty->termios_rwsem){++++}:
+> down_write+0x57/0x140 kernel/locking/rwsem.c:1534
+> tty_unthrottle+0x22/0x100 drivers/tty/tty_ioctl.c:136
+> mkiss_receive_buf+0x12aa/0x1340 drivers/net/hamradio/mkiss.c:902
+> tty_ldisc_receive_buf+0x12f/0x170 drivers/tty/tty_buffer.c:465
+> paste_selection+0x346/0x470 drivers/tty/vt/selection.c:389
+> tioclinux+0x121/0x530 drivers/tty/vt/vt.c:3055
+> vt_ioctl+0x3f1/0x3a30 drivers/tty/vt/vt_ioctl.c:364
+
+This is ioctl(TIOCL_PASTESEL).
+Locks held on the path: sel_lock -> termios_rwsem
+
+> other info that might help us debug this:
+>
+> Chain exists of:
+> &tty->termios_rwsem --> console_lock --> sel_lock
+
+Clearly. From the above, we have:
+ console_lock -> sel_lock
+ sel_lock -> termios_rwsem
+ termios_rwsem -> console_lock
+
+Fix this by reversing the console_lock -> sel_lock dependency in
+ioctl(TIOCL_SETSEL). First, lock sel_lock, then console_lock.
+
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Reported-by: syzbot+26183d9746e62da329b8@syzkaller.appspotmail.com
+Fixes: 07e6124a1a46 ("vt: selection, close sel_buffer race")
+Cc: stable <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200228115406.5735-2-jslaby@suse.cz
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/vt/selection.c | 16 +++++++---------
+ 1 file changed, 7 insertions(+), 9 deletions(-)
+
+--- a/drivers/tty/vt/selection.c
++++ b/drivers/tty/vt/selection.c
+@@ -214,7 +214,6 @@ static int __set_selection_kernel(struct
+ if (ps > pe) /* make sel_start <= sel_end */
+ swap(ps, pe);
+
+- mutex_lock(&sel_lock);
+ if (sel_cons != vc_cons[fg_console].d) {
+ clear_selection();
+ sel_cons = vc_cons[fg_console].d;
+@@ -260,10 +259,9 @@ static int __set_selection_kernel(struct
+ break;
+ case TIOCL_SELPOINTER:
+ highlight_pointer(pe);
+- goto unlock;
++ return 0;
+ default:
+- ret = -EINVAL;
+- goto unlock;
++ return -EINVAL;
+ }
+
+ /* remove the pointer */
+@@ -285,7 +283,7 @@ static int __set_selection_kernel(struct
+ else if (new_sel_start == sel_start)
+ {
+ if (new_sel_end == sel_end) /* no action required */
+- goto unlock;
++ return 0;
+ else if (new_sel_end > sel_end) /* extend to right */
+ highlight(sel_end + 2, new_sel_end);
+ else /* contract from right */
+@@ -313,8 +311,7 @@ static int __set_selection_kernel(struct
+ if (!bp) {
+ printk(KERN_WARNING "selection: kmalloc() failed\n");
+ clear_selection();
+- ret = -ENOMEM;
+- goto unlock;
++ return -ENOMEM;
+ }
+ kfree(sel_buffer);
+ sel_buffer = bp;
+@@ -339,8 +336,7 @@ static int __set_selection_kernel(struct
+ }
+ }
+ sel_buffer_lth = bp - sel_buffer;
+-unlock:
+- mutex_unlock(&sel_lock);
++
+ return ret;
+ }
+
+@@ -348,9 +344,11 @@ int set_selection_kernel(struct tiocl_se
+ {
+ int ret;
+
++ mutex_lock(&sel_lock);
+ console_lock();
+ ret = __set_selection_kernel(v, tty);
+ console_unlock();
++ mutex_unlock(&sel_lock);
+
+ return ret;
+ }
--- /dev/null
+From 735a6dd02222d8d070c7bb748f25895239ca8c92 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+Date: Wed, 26 Feb 2020 15:16:15 -0800
+Subject: x86/pkeys: Manually set X86_FEATURE_OSPKE to preserve existing changes
+
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+
+commit 735a6dd02222d8d070c7bb748f25895239ca8c92 upstream.
+
+Explicitly set X86_FEATURE_OSPKE via set_cpu_cap() instead of calling
+get_cpu_cap() to pull the feature bit from CPUID after enabling CR4.PKE.
+Invoking get_cpu_cap() effectively wipes out any {set,clear}_cpu_cap()
+changes that were made between this_cpu->c_init() and setup_pku(), as
+all non-synthetic feature words are reinitialized from the CPU's CPUID
+values.
+
+Blasting away capability updates manifests most visibility when running
+on a VMX capable CPU, but with VMX disabled by BIOS. To indicate that
+VMX is disabled, init_ia32_feat_ctl() clears X86_FEATURE_VMX, using
+clear_cpu_cap() instead of setup_clear_cpu_cap() so that KVM can report
+which CPU is misconfigured (KVM needs to probe every CPU anyways).
+Restoring X86_FEATURE_VMX from CPUID causes KVM to think VMX is enabled,
+ultimately leading to an unexpected #GP when KVM attempts to do VMXON.
+
+Arguably, init_ia32_feat_ctl() should use setup_clear_cpu_cap() and let
+KVM figure out a different way to report the misconfigured CPU, but VMX
+is not the only feature bit that is affected, i.e. there is precedent
+that tweaking feature bits via {set,clear}_cpu_cap() after ->c_init()
+is expected to work. Most notably, x86_init_rdrand()'s clearing of
+X86_FEATURE_RDRAND when RDRAND malfunctions is also overwritten.
+
+Fixes: 0697694564c8 ("x86/mm/pkeys: Actually enable Memory Protection Keys in the CPU")
+Reported-by: Jacob Keller <jacob.e.keller@intel.com>
+Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
+Tested-by: Jacob Keller <jacob.e.keller@intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20200226231615.13664-1-sean.j.christopherson@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/common.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/cpu/common.c
++++ b/arch/x86/kernel/cpu/common.c
+@@ -464,7 +464,7 @@ static __always_inline void setup_pku(st
+ * cpuid bit to be set. We need to ensure that we
+ * update that bit in this CPU's "cpu_info".
+ */
+- get_cpu_cap(c);
++ set_cpu_cap(c, X86_FEATURE_OSPKE);
+ }
+
+ #ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
projects / thirdparty / kernel / stable-queue.git / commitdiff
