linux-kernel - Re: CoreSight framework and drivers

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: <20121220234011.GE14363@n2100.arm.linux.org.uk>
Date:	Thu, 20 Dec 2012 23:40:11 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Jon Hunter <jon-hunter@...com>
Cc:	Pratik Patel <pratikp@...eaurora.org>,
	linux-arm-msm@...r.kernel.org,
	"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
	Will Deacon <will.deacon@....com>,
	linux-kernel@...r.kernel.org,
	"magnus.p.persson@...ricsson.com" <magnus.p.persson@...ricsson.com>,
	"david.rusling@...aro.org" <david.rusling@...aro.org>,
	"arve@...roid.com" <arve@...roid.com>,
	"dsaxena@...aro.org" <dsaxena@...aro.org>,
	"john.stultz@...aro.org" <john.stultz@...aro.org>,
	"d-deao@...com" <d-deao@...com>,
	"christian.bejram@...ricsson.com" <christian.bejram@...ricsson.com>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: CoreSight framework and drivers

On Thu, Dec 20, 2012 at 04:54:38PM -0600, Jon Hunter wrote:
> On 12/20/2012 01:51 PM, Pratik Patel wrote:
> > Ok, so are you referring to making CoreSight devices register
> > with AMBA bus instead of platform bus keeping everything else
> > intact?
> 
> Yes exactly. However, please note I am not saying that we should do
> this, and I asking what direction does the community want us to take
> here? Platform bus or AMBA bus?

One of the issues which worries me about mixing peripheral drivers on
random different buses is... what happens when we end up with a SoC
which gates the APB clock at bus level (there are SoCs which gate the
APB clock at peripheral level.)  In other words, an APB bus only gets
clocked upon request.

We can deal with that with the infrastructure we have in place in the
AMBA bus layer, but not with the platform bus - we'd have to teach the
platform bus driver about the special APB clock instead of having it
handled primerily at the bus layer.

At least the coresight ETM peripherals make use of the APB bus.  They
have a whole pile of registers on the APB bus, and they have the
primecell IDs stored in the last words of the peripheral, again just
like the other primecell devices we have using the AMBA bus layer.

What I'd say is... why stick it on a different bus type from the other
peripherals which might make things harder in the future?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/