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: <5a4c5112-4934-c827-2a07-387e4555dc4b@arm.com>
Date:   Thu, 30 Mar 2017 17:04:42 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Leo Yan <leo.yan@...aro.org>
Cc:     Mathieu Poirier <mathieu.poirier@...aro.org>,
        Sudeep Holla <sudeep.holla@....com>,
        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>
Subject: Re: [PATCH v5 6/9] coresight: add support for CPU debug module



On 30/03/17 16:46, Mathieu Poirier wrote:
> 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 completely agree and just responded to the original patch.

>>
>> 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.
> 

+1, as I just mentioned on the patch, we can warn user to take action
when this feature gets enabled to get desired result and *nothing more*
than that. Please drop all these pm_qos stuff.

-- 
Regards,
Sudeep