linux-kernel - Re: [PATCH v5 6/9] coresight: add support for CPU debug module

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]

Message-ID: <CANLsYkwPYSvy2xjf8uuvx1WGWpGdMFy7kF=30VbvgW+jDvnFuw@mail.gmail.com>
Date:   Thu, 30 Mar 2017 09:46:21 -0600
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     Leo Yan <leo.yan@...aro.org>
Cc:     Jonathan Corbet <corbet@....net>, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Wei Xu <xuwei5@...ilicon.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Guodong Xu <guodong.xu@...aro.org>,
        John Stultz <john.stultz@...aro.org>,
        linux-doc@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        linux-clk@...r.kernel.org, Mike Leach <mike.leach@...aro.org>,
        "Suzuki K. Poulose" <Suzuki.Poulose@....com>,
        Sudeep Holla <sudeep.holla@....com>
Subject: Re: [PATCH v5 6/9] coresight: add support for CPU debug module

On 29 March 2017 at 19:59, Leo Yan <leo.yan@...aro.org> wrote:
> On Wed, Mar 29, 2017 at 10:55:35AM -0600, Mathieu Poirier wrote:
>
> [...]
>
>> > So this is why add "idle_constraint" as a central place to control
>> > power domain for CPU debug purpose and I also think this is more
>> > friendly for hardware design, e.g. some platforms can enable partial
>> > low power states to save power and avoid overheat after using this
>> > driver.
>> >
>> > How about you think for this?
>>
>> Like Sudeep pointed out we should concentrate on doing the right thing,
>> that is work with EDPRSR.PU, EDPRCR.COREPURQ and EDPRCR.CORENPDRQ.
>
> Agree, and I think we have aligned for this.
>
>> Anything outside of that becomes platform specific and can't be handled in
>> this driver.
>
> Sorry I argue a bit for this just want to make things more clear and
> if can have better method.
>
> Though the issue is platform specific, but the code is to seek common
> method to handle them. So the driver has no any platform specific code.

Seeking a common way to handle platform specific problems doesn't
scale and will never be encompassing.  There will always be a quirk
somewhere to deal with, hence the idea of keeping things separate.

>
> I read again for Suziki's suggestion: "4) Should document the fact that,
> on some platforms, the user may have to disable CPUidle explicitly to
> get the driver working. But let us not make it the default. The user
> with a not so ideal platform could add "nohlt" and get it working."

Suzuki and I are expressing the same view using different words.

>
> So I'm not strong to resist and if this is alignment yet, I should
> document well for this but doesn't handle it in driver (keep driver
> simple).
>
> Thanks,
> Leo Yan