linux-kernel - Re: [PATCH 5/8] counter/ti-eqep: add support for latched position

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: <444960b4-1120-26fa-bd00-dfbe3c13cf23@lechnology.com>
Date:   Wed, 27 Oct 2021 10:40:15 -0500
From:   David Lechner <david@...hnology.com>
To:     William Breathitt Gray <vilhelm.gray@...il.com>
Cc:     linux-iio@...r.kernel.org, Robert Nelson <robertcnelson@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/8] counter/ti-eqep: add support for latched position

On 10/27/21 2:44 AM, William Breathitt Gray wrote:
> On Sat, Oct 16, 2021 at 08:33:40PM -0500, David Lechner wrote:
>> This adds support to the TI eQEP counter driver for a latched position.
>> This is a new extension that gets the counter count that was recorded
>> when an event was triggered. A new device-level latch_mode attribute is
>> added to select the trigger. Edge capture unit support will be needed
>> to make full use of this, but "Unit timeout" mode can already be used
>> to calculate high speeds.
>>
>> The unit timer could also have attributes for latched_time and
>> latched_period that use the same trigger. However this is not a use
>> case at this time, so they can be added later if needed.
> 
> I see that "latched_count" holds the captured counter count; would this
> "latched_time" hold the captured unit timer time? If so, does that mean
> setting the latch mode to "Unit timeout" always results in a
> "latched_time" equal to 0 (assuming that's when the timeout event
> triggers)?
> 

Some `latched_*` attributes will only be useful for one `latched_mode`
selection but not the other.

These latched registers are used to measure speed. There are two ways
to do this. A) measuring the change in position over a fixed time and
B) measuring the change in time for a fixed change in position. So for
A) latched_mode would be set to trigger on timeout and we would use
the latched_position for the measurement. For B) we would set the
latched_mode to trigger on reading the count register and use the
latched_time as the measurement.

...

>>   static struct counter_comp ti_eqep_device_ext[] = {
>> +	COUNTER_COMP_DEVICE_ENUM("latch_mode", ti_eqep_latch_mode_read,
>> +				ti_eqep_latch_mode_write, ti_eqep_latch_modes),
> 
> It seems more appropriate to move this alongside "latched_count" as
> Count extension because this is setting the trigger mode to latch the
> respective Count's count. Or does this particular extension also affect
> the "latched_time" capture for the unit timer?
> 

In hardware, there are at least 3 registers that get latched that I
recall. They are in different subsystems (main count, unit timer,
edge capture). So as you have guessed, that is the reason for having
the trigger selection at the device level.