linux-kernel - Re: [Q] Frequency & duty cycle measurement?

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] [day] [month] [year] [list]

Message-ID: <c68777f2-b053-4320-aabe-f95a9796b016@prolan.hu>
Date: Wed, 5 Feb 2025 10:58:45 +0100
From: Csókás Bence <csokas.bence@...lan.hu>
To: William Breathitt Gray <wbg@...nel.org>
CC: <linux-iio@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<timestamp@...ts.linux.dev>, Jonathan Cameron <jic23@...nel.org>, "Lars-Peter
 Clausen" <lars@...afoo.de>, Daniel Lezcano <daniel.lezcano@...aro.org>,
	"Thomas Gleixner" <tglx@...utronix.de>, Dipen Patel <dipenp@...dia.com>,
	<dlechner@...libre.com>
Subject: Re: [Q] Frequency & duty cycle measurement?

Hi,

On 2025. 02. 05. 10:30, Csókás Bence wrote:
> Hi,
> 
> On 2025. 02. 05. 0:37, William Breathitt Gray wrote:
>> The first step is to decide which event we'll monitor and on which
>> channel: we want to monitor Capture events so that's
>> COUNTER_EVENT_CAPTURE, and we want event channel 0 (n.b. 0 because
>> that's the channel parameter value passed to counter_push_event() in the
>> driver).

Ah, I push 0 and 1 for the two interrupts... So that's why `channel` has 
to be 0 and 1 as well. Does it make sense to do it this way, or should I 
push on event channel 0 always?

> I had no success using `channel = 0`, only data from `capture0` comes 
> back. If I set both `channel` AND `component.id` to X, then I start to 
> see similar values than what I get from reading sysfs. (For now I 
> hard-coded all values; I agree that the correct way would be to read 
> component IDs from sysfs, but this is still a PoC...)
> 
> Did I do something wrong in implementing the driver maybe? (See the 
> submitted patches.) And any idea as to why I might be seeing the slowdown?

The slowdown is still a mystery though...

Bence