linux-kernel - Re: [PATCH v2 1/2] clocksource/drivers/exynos_mct_v2: introduce Exynos MCT version 2 driver for next Exynos SoC

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] [day] [month] [year] [list]

Message-ID: <20211105093117.GA32036@willie-the-truck>
Date:   Fri, 5 Nov 2021 09:31:17 +0000
From:   Will Deacon <will@...nel.org>
To:     Youngmin Nam <youngmin.nam@...sung.com>
Cc:     Mark Rutland <mark.rutland@....com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        daniel.lezcano@...aro.org, tglx@...utronix.de,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-samsung-soc@...r.kernel.org, pullip.cho@...sung.com,
        hoony.yu@...sung.com, hajun.sung@...sung.com,
        myung-su.cha@...sung.com, kgene@...nel.org, kwoo.kang@...sung.com
Subject: Re: [PATCH v2 1/2] clocksource/drivers/exynos_mct_v2: introduce
 Exynos MCT version 2 driver for next Exynos SoC

On Fri, Nov 05, 2021 at 09:46:27AM +0900, Youngmin Nam wrote:
> On Thu, Nov 04, 2021 at 09:44:53AM +0000, Mark Rutland wrote:
> > Hi,
> > 
> > On Thu, Nov 04, 2021 at 09:21:02AM +0900, Youngmin Nam wrote:
> > > On Wed, Nov 03, 2021 at 10:04:18AM +0000, Mark Rutland wrote:
> > > > On Wed, Nov 03, 2021 at 06:57:28PM +0900, Youngmin Nam wrote:
> > > > > On Wed, Nov 03, 2021 at 10:04:36AM +0100, Krzysztof Kozlowski wrote:
> > > > > > On 03/11/2021 10:24, Youngmin Nam wrote:
> > > > > > > On Wed, Nov 03, 2021 at 09:18:07AM +0100, Krzysztof Kozlowski wrote:
> > > > > > >> On 03/11/2021 01:09, Youngmin Nam wrote:
> > > > > > >>> On Tue, Nov 02, 2021 at 10:28:10AM +0000, Mark Rutland wrote:
> > 
> > > > > > >>>> Previously Will asked you to try CLOCK_EVT_FEAT_PERCPU here, and to set
> > > > > > >>>> the C3STOP flag on the arch timer via the DT when necessary, rather than
> > > > > > >>>> trying to override the arch timer like this:
> > 
> > > > > > >>> Yes, I believe Will's suggestion definitely will work.
> > 
> > > > > So, how about we control timer rating value with DT ?
> > > > > Of course the default rating value should be lower than arm arch timer's.
> > > > > Do you agree with this?
> > > > 
> > > > No; placing a rating value in the DT is a hack. That should *not* live
> > > > in the DT because it's linux-internal detail and not a description of
> > > > the HW.
> > > 
> > > So, how do we use MCTv2 only for clock event device if there are some
> > > limitations caused by SoC design implemention ?
> > 
> > What limitations? Are you thinking of a known issue, or just in case
> > there is a bug in future HW?
> > 
> > If there is a problem, we'll need to describe that in the DT somehow,
> > and we need to know speciifcally what that limitation is.
> > 
> > Above you said that Will's suggestion will definitely work, which
> > implies no such limitations.
> > 
> 
> Using arch timer for event device is highly related with Core power down feature so that it is also related with
> power saving scheme in SoC.
> Core power down and power saving depend on SoC design implemention.
> We can't confirm that using only arch timer can cover all scenario at production level.

Why not and what are we supposed to do about that? It's probably worth
pointing out that the majority of arm64-based SoCs have been using the arch
timer for *years* without problems. So I reckon you can make it work too.

> So we should be able to use MCTv2 as well.
> 
> Why do you enforce using *only* arch timer ?
> Why aren't we allowed to use own timer of our SoC ?

You can do whatever you like downstream, but the upstream position is that
the arch timer is preferred: it's an architected solution from Arm which
supports things like virtualisation and userspace access. It's also a damn
sight quicker to access than the MCT.

On the downside, it's not usually possible to use it as a wakeup source,
so that's a great place for the MCT to shine. I've literally written the
code for you to do this.

Anyway, this MCTv2 driver is a dead duck whatever we do. Extend the existing
driver please.

Will