lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 17 Apr 2023 11:09:49 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
Cc:     walter.chang@...iatek.com,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Mark Rutland <mark.rutland@....com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        wsd_upstream@...iatek.com, stanley.chu@...iatek.com,
        Chun-hung.Wu@...iatek.com, Freddy.Hsin@...iatek.com,
        linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH] clocksource/drivers/arm_arch_timer: Add workaround for MediaTek MMIO timer

On Mon, 17 Apr 2023 11:01:15 +0100,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com> wrote:
> 
> Il 17/04/23 11:06, walter.chang@...iatek.com ha scritto:
> > From: Walter Chang <walter.chang@...iatek.com>
> > 
> > The MT69XX series SoCs have the incomplete implementation issue in the
> > mmio timer. Specifically, the hardware only implements the TVAL
> > functionality, but not the CVAL functionality. This hardware limitation
> > will cause set_next_event_mem() fail to set the actual expiration time
> > when writing a value to the CVAL. On these platforms, the mmio timer's
> > internal expiration time will still be judged as 0 (the value of TVAL),
> > resulting in the mmio timer not functioning as intended.
> > 
> > The workaround is to use TVAL in addition to CVAL for these affected
> > platforms.
> > 
> > Signed-off-by: Walter Chang <walter.chang@...iatek.com>
> > ---
> >   Documentation/arm64/silicon-errata.rst |  4 ++++
> >   drivers/clocksource/Kconfig            |  9 ++++++++
> >   drivers/clocksource/arm_arch_timer.c   | 29 ++++++++++++++++++++++++++
> >   3 files changed, 42 insertions(+)
> > 
> > diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst
> > index ec5f889d7681..ca1893713a4c 100644
> > --- a/Documentation/arm64/silicon-errata.rst
> > +++ b/Documentation/arm64/silicon-errata.rst
> > @@ -209,3 +209,7 @@ stable kernels.
> >   +----------------+-----------------+-----------------+-----------------------------+
> >   | Fujitsu        | A64FX           | E#010001        | FUJITSU_ERRATUM_010001      |
> >   +----------------+-----------------+-----------------+-----------------------------+
> > +
> > ++----------------+-----------------+-----------------+-----------------------------+
> > +| MediaTek       | MT69XX series   | #690001         | MEDIATEK_ERRATUM_690001     |
> > ++----------------+-----------------+-----------------+-----------------------------+
> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> > index 5fc8f0e7fb38..475356b8dbdc 100644
> > --- a/drivers/clocksource/Kconfig
> > +++ b/drivers/clocksource/Kconfig
> > @@ -368,6 +368,15 @@ config SUN50I_ERRATUM_UNKNOWN1
> >   	  the Allwinner A64 SoC. The workaround will only be active if the
> >   	  allwinner,erratum-unknown1 property is found in the timer node.
> >   +config MEDIATEK_ERRATUM_690001
> > +	bool "Workaround for MediaTek MT69XX erratum 690001"
> > +	depends on ARM_ARCH_TIMER && ARM64
> > +	help
> > +	  This option enables a workaround for incomplete implementation
> > +	  in the MMIO timer on the MediaTek MT69XX SoCs. The workaround
> > +	  will only be active if mediatek,erratum-690001 property is
> > +	  found in the timer node.
> > +
> >   config ARM_GLOBAL_TIMER
> >   	bool "Support for the ARM global timer" if COMPILE_TEST
> >   	select TIMER_OF if OF
> > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> > index e09d4427f604..920570d57fc0 100644
> > --- a/drivers/clocksource/arm_arch_timer.c
> > +++ b/drivers/clocksource/arm_arch_timer.c
> > @@ -389,6 +389,10 @@ static u64 notrace sun50i_a64_read_cntvct_el0(void)
> >   }
> >   #endif
> >   +#ifdef CONFIG_MEDIATEK_ERRATUM_690001
> > +static bool arch_timer_mem_sne_use_tval __ro_after_init;
> 
> What about reusing part of the CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND logic and
> adding something like CONFIG_ARM_ARCH_TIMER_MEM_WORKAROUND?

I don't think there is *any* need for the out-of-line stuff on any of
the memory-mapped accesses, if only because they are not inlined the
first place, and that there is no performance requirements around this
timer (it should hardly ever be used as the sched clock, for example).

Despite being part of the same driver, the sysreg and MMIO timers are
vastly different and keeping them together has only been a nuisance.
Someone should throw an axe at this stuff.

	M.

-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ