The TVE200 will occasionally print a bunch of lost interrupts
and similar dmesg messages, sometimes during boot and sometimes
after disabling and coming back to enablement. This is probably
because the hardware is left in an unknown state by the boot
loader that displays a logo.
This can be fixed by bringing the controller into a known state
by resetting the controller while enabling it. We retry reset 5
times like the vendor driver does. We also put the controller
into reset before de-clocking it and clear all interrupts before
enabling the vblank IRQ.
This makes the video enable/disable/enable cycle rock solid
on the D-Link DIR-685. Tested extensively.
Cc: stable(a)vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
---
drivers/gpu/drm/tve200/tve200_display.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tve200/tve200_display.c b/drivers/gpu/drm/tve200/tve200_display.c
index d733bbc4ac0e..17ff24d999d1 100644
--- a/drivers/gpu/drm/tve200/tve200_display.c
+++ b/drivers/gpu/drm/tve200/tve200_display.c
@@ -14,6 +14,7 @@
#include <linux/version.h>
#include <linux/dma-buf.h>
#include <linux/of_graph.h>
+#include <linux/delay.h>
#include <drm/drm_fb_cma_helper.h>
#include <drm/drm_fourcc.h>
@@ -130,9 +131,25 @@ static void tve200_display_enable(struct drm_simple_display_pipe *pipe,
struct drm_connector *connector = priv->connector;
u32 format = fb->format->format;
u32 ctrl1 = 0;
+ int retries;
clk_prepare_enable(priv->clk);
+ /* Reset the TVE200 and wait for it to come back online */
+ writel(TVE200_CTRL_4_RESET, priv->regs + TVE200_CTRL_4);
+ for (retries = 0; retries < 5; retries++) {
+ usleep_range(30000, 50000);
+ if (readl(priv->regs + TVE200_CTRL_4) & TVE200_CTRL_4_RESET)
+ continue;
+ else
+ break;
+ }
+ if (retries == 5 &&
+ readl(priv->regs + TVE200_CTRL_4) & TVE200_CTRL_4_RESET) {
+ dev_err(drm->dev, "can't get hardware out of reset\n");
+ return;
+ }
+
/* Function 1 */
ctrl1 |= TVE200_CTRL_CSMODE;
/* Interlace mode for CCIR656: parameterize? */
@@ -230,8 +247,9 @@ static void tve200_display_disable(struct drm_simple_display_pipe *pipe)
drm_crtc_vblank_off(crtc);
- /* Disable and Power Down */
+ /* Disable put into reset and Power Down */
writel(0, priv->regs + TVE200_CTRL);
+ writel(TVE200_CTRL_4_RESET, priv->regs + TVE200_CTRL_4);
clk_disable_unprepare(priv->clk);
}
@@ -279,6 +297,8 @@ static int tve200_display_enable_vblank(struct drm_simple_display_pipe *pipe)
struct drm_device *drm = crtc->dev;
struct tve200_drm_dev_private *priv = drm->dev_private;
+ /* Clear any IRQs and enable */
+ writel(0xFF, priv->regs + TVE200_INT_CLR);
writel(TVE200_INT_V_STATUS, priv->regs + TVE200_INT_EN);
return 0;
}
--
2.26.2
Hi,
I have attached the follow up fix that checks for the proto index during
conntrack creation.
Thanks,
Will
On 07/31/2020, William Mcvicker wrote:
> Hi Pablo,
>
> > Note that this code does not exist in the tree anymore. I'm not sure
> > if this problem still exists upstream, this patch does not apply to
> > nf.git. This fix should only go for -stable maintainers.
>
> Right, the vulnerability has been fixed by the refactor commit fe2d0020994cd
> ("netfilter: nat: remove l4proto->in_range"), but this patch is a part of
> a full re-work of the code and doesn't backport very cleanly to the LTS
> branches. So this fix is only applicable to the 4.19, 4.14, 4.9, and 4.4 LTS
> branches. I missed the -stable email, but will re-add it to this thread with
> the re-worked patch.
>
> Thanks,
> Will
>
> On 07/31/2020, Pablo Neira Ayuso wrote:
> > Hi William,
> >
> > On Fri, Jul 31, 2020 at 12:26:11AM +0000, William Mcvicker wrote:
> > > Hi Pablo,
> > >
> > > Yes, I believe this oops is only triggered by userspace when the user
> > > specifically passes in an invalid nf_nat_l3protos index. I'm happy to re-work
> > > the patch to check for this in ctnetlink_create_conntrack().
> >
> > Great.
> >
> > Note that this code does not exist in the tree anymore. I'm not sure
> > if this problem still exists upstream, this patch does not apply to
> > nf.git. This fix should only go for -stable maintainers.
> >
> > > > BTW, do you have a Fixes: tag for this? This will be useful for
> > > > -stable maintainer to pick up this fix.
> > >
> > > Regarding the Fixes: tag, I don't have one offhand since this bug was reported
> > > to me, but I can search through the code history to find the commit that
> > > exposed this vulnerability.
> >
> > That would be great.
> >
> > Thank you.
Tegra210/Tegra186/Tegra194 has incorrectly enabled
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK from the beginning of their support.
Tegra210 and later SDMMC hardware default uses sdmmc_legacy_tm (TMCLK)
all the time for hardware data timeout instead of SDCLK and this TMCLK
need to be kept enabled by Tegra sdmmc driver.
This series includes manual backport patches to fix this for stable
kernel #4.19
Note:
Patch series v2 is same as v1 except updated commit message in all patches
properly for backporting.
Sowjanya Komatineni (7):
sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210
sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186
dt-bindings: mmc: tegra: Add tmclk for Tegra210 and Tegra186
arm64: tegra: Add missing timeout clock to Tegra210 SDMMC
arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes
arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes
sdhci: tegra: Add missing TMCLK for data timeout
.../bindings/mmc/nvidia,tegra20-sdhci.txt | 23 +++++++++-
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 20 +++++----
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 15 ++++---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 28 ++++++------
drivers/mmc/host/sdhci-tegra.c | 50 +++++++++++++++++++++-
5 files changed, 106 insertions(+), 30 deletions(-)
--
2.7.4
On Tue, Aug 13, 2019 at 02:27:52PM -0700, Andrew Morton wrote:
> On Mon, 12 Aug 2019 15:29:10 -0700 Roman Gushchin <guro(a)fb.com> wrote:
>
> > Percpu caching of local vmstats with the conditional propagation
> > by the cgroup tree leads to an accumulation of errors on non-leaf
> > levels.
> >
> > Let's imagine two nested memory cgroups A and A/B. Say, a process
> > belonging to A/B allocates 100 pagecache pages on the CPU 0.
> > The percpu cache will spill 3 times, so that 32*3=96 pages will be
> > accounted to A/B and A atomic vmstat counters, 4 pages will remain
> > in the percpu cache.
> >
> > Imagine A/B is nearby memory.max, so that every following allocation
> > triggers a direct reclaim on the local CPU. Say, each such attempt
> > will free 16 pages on a new cpu. That means every percpu cache will
> > have -16 pages, except the first one, which will have 4 - 16 = -12.
> > A/B and A atomic counters will not be touched at all.
> >
> > Now a user removes A/B. All percpu caches are freed and corresponding
> > vmstat numbers are forgotten. A has 96 pages more than expected.
> >
> > As memory cgroups are created and destroyed, errors do accumulate.
> > Even 1-2 pages differences can accumulate into large numbers.
> >
> > To fix this issue let's accumulate and propagate percpu vmstat
> > values before releasing the memory cgroup. At this point these
> > numbers are stable and cannot be changed.
> >
> > Since on cpu hotplug we do flush percpu vmstats anyway, we can
> > iterate only over online cpus.
> >
> > Fixes: 42a300353577 ("mm: memcontrol: fix recursive statistics correctness & scalabilty")
>
> Is this not serious enough for a cc:stable?
I hope the "Fixes" tag will work, but yeah, my bad, cc:stable is definitely
a good idea here.
Added stable@ to cc.
Thanks!