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: <50D34EE5.8090407@ti.com>
Date:	Thu, 20 Dec 2012 11:46:13 -0600
From:	Jon Hunter <jon-hunter@...com>
To:	Pratik Patel <pratikp@...eaurora.org>
CC:	Will Deacon <will.deacon@....com>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"linus.walleij@...aro.org" <linus.walleij@...aro.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>,
	<linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: CoreSight framework and drivers

On 12/19/2012 03:24 PM, Pratik Patel wrote:

[snip]

> Currently we use the CoreSight virtual bus to conveniently list
> sysfs configuration attributes for all the registered CoreSight
> devices.
> 
> For eg:
> /sys/bus/coresight/devices/coresight-etm0/<attribute>
> /sys/bus/coresight/devices/coresight-etm1/<attribute>
> /sys/bus/coresight/devices/coresight-stm/<attribute>
> /sys/bus/coresight/devices/coresight-tmc-etf/<attribute>
> ...
> ...
> 
> Some of the attributes are based on device type (i.e. source,
> link or sink) so they will exist for all devices of that type
> while some are device specific.
> 
> Maybe I am misunderstanding the question but are you suggesting
> to register CoreSight devices to the AMBA bus instead of the
> CoreSight core layer code?

Yes exactly.

> Will Deacon mentioned earlier that AMBA framework can be changed
> to accomodate devices with a different class but I am more
> concerned with losing some of the stuff that the core layer code
> does (eg. coresight_register, coresight_enable, coresight_disable
> in coresight.c) if we register CoreSight drivers to the AMBA bus
> without letting the core layer know about the device connections.

I may be missing something, but couldn't you keep all the
register/enable/disable stuff but just register the device with the amba
bus? Obviously some changes would need to be made.

Personally, I don't have strong feeling either way, but we have ETM/ETB
drivers using AMBA today and so I am hoping we can come to agreement on
this going forward.

Russell, Will, what are your thoughts?

Otherwise, looking at the code, I like what you have implemented. I
still need to look closer, but I am struggling to figure out how a
coresight device such as the cross-trigger-interface fits with this
model. This model appears to be geared towards coresight devices used
for traces purposes and are either source, links or sinks. The
cross-trigger-interface is not a source or a sink. However, although you
it could be considered as a link (routing events), it is not really, as
it may not link to other coresight sinks/source.

In my case, I have PMU-IRQ --> CTI --> GIC. So a non-coresight source
and sink. In away the CTI looks more like a 2nd-level interrupt
controller than anything else. Hence, another type of coresight device
may be needed in addition to source, links and sinks. Or link is
extended in some way to connect to non-coresight sources/sinks.

Let me know if you have any thoughts.

Cheers
Jon
--
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/