linux-kernel - Re: [PATCH v3 3/5] coresight: add support for 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: <d976bae5-0b81-e47c-4f41-eb240bea7827@arm.com>
Date:   Wed, 22 Mar 2017 16:53:32 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Leo Yan <leo.yan@...aro.org>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        Mike Leach <mike.leach@...aro.org>,
        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>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        John Stultz <john.stultz@...aro.org>,
        Guodong Xu <guodong.xu@...aro.org>,
        Haojian Zhuang <haojian.zhuang@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org
Subject: Re: [PATCH v3 3/5] coresight: add support for debug module



On 22/03/17 16:01, Leo Yan wrote:
> On Wed, Mar 22, 2017 at 02:07:47PM +0000, Sudeep Holla wrote:

[...]

>>
>> We can always do that unconditionally. If implementations don't honor
>> those bits, it's different. If they hang on accessing something which is
>> on debug power domain and not on core power domain, then you have much
>> bigger issue to solve. How can you even trust and make any other
>> register accesses that are in debug power domain then ?
> 
> So we can add below code before really access another other registers
> are possible in CPU power domain:
> 
>         /*
>          * Force to power on CPU power domain and assert
>          * DBGPWRUPREQ signal
>          */
>         val = readl(drvdata->base + EDPRCR);
>         val |= BIT(3);
>         writel(val, drvdata->base + EDPRCR);
> 

Yes worth trying it out.

[...]

> 
> I tried to digest these info and below are my understanding from your
> suggestion:
> 
> ### For boot time: add two command line flags
> 

I am not really sure about boot flags as there are dependency on power
domains and expecting them to be powered on quite earlier is too much to
ask. I am not sure if we need special case for boot time. But that's
just my opinion. If someone has found it *really* useful and no other
alternative exists, then go for it.

[...]

> ### For runtime: use one sysfs node
> 
> - Create sysfs node:
>   /sys/kernel/debug/coresight_cpu_debug/enable_debug
> 
>   echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable_debug: same
>   functionality with boot time's 'coresight.cpu_debug';
> 

My argument was this to be default without any need for flags.
We can skip it as and when we find broken implementation if required.

>   echo 2 > /sys/kernel/debug/coresight_cpu_debug/enable_debug: same
>   functionality with boot time's 'coresight.cpu_debug_pwrup';
> 
>   echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable_debug: disable
>   debug functionality.
>

So it can be simple boolean to force setup the power domain requirements
for it to work whenever you need to activate it. I may be missing some
use-case, but IIUC simple boolean flag should be fine as suggested
initially.

-- 
Regards,
Sudeep