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: <20251229135006.10133-1-wbg@kernel.org>
Date: Mon, 29 Dec 2025 22:50:01 +0900
From: William Breathitt Gray <wbg@...nel.org>
To: Daniel Lezcano <daniel.lezcano@...aro.org>
Cc: William Breathitt Gray <wbg@...nel.org>,
	robh@...nel.org,
	conor+dt@...nel.org,
	krzk+dt@...nel.org,
	s32@....com,
	devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-iio@...r.kernel.org,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 3/3] counter: Add STM based counter

On Sun, Dec 28, 2025 at 06:37:22PM +0100, Daniel Lezcano wrote:
> 
> Hi William,
> 
> On 12/28/25 07:52, William Breathitt Gray wrote:
> > On Wed, Dec 17, 2025 at 08:49:57AM +0100, Daniel Lezcano wrote:
> >> The NXP S32G2 automotive platform integrates four Cortex-A53 cores and
> >> three Cortex-M7 cores, along with a large number of timers and
> >> counters. These hardware blocks can be used as clocksources or
> >> clockevents, or as timestamp counters shared across the various
> >> subsystems running alongside the Linux kernel, such as firmware
> >> components. Their actual usage depends on the overall platform
> >> software design.
> >>
> >> In a Linux-based system, the kernel controls the counter, which is a
> >> read-only shared resource for the other subsystems. One of its primary
> >> purposes is to act as a common timestamp source for messages or
> >> traces, allowing correlation of events occurring in different
> >> operating system contexts.
> >>
> >> These changes introduce a basic counter driver that can start, stop,
> >> and reset the counter. It also handles overflow accounting and
> >> configures the prescaler value.
> >>
> >> Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>
> >
> > Hi Daniel,
> >
> > It sounds like you're trying to implement a clock for timestamping.
> 
> Well no, it is a counter which is used for timestamping. It is an
> automotive design.

I'm sorry, I misunderstood your device earlier. We'll continue with the
Counter driver implementation in that case.

> > Regardless, if you do pursue a Counter driver you'll need to follow the
> > Generic Counter paradigm[^1] and define at least three core components:
> > a Signal, a Synapse, and a Count. Resetting the Count is typically
> > implemented by defining a struct counter_ops counter_write()

Oops, I should have written count_write() there; when a user sets the
Count back to 0, it can be considered a reset.

> > callback[^2], while overflows are typically implemented by pushing
> > COUNTER_EVENT_OVERFLOW Counter events[^3] that can be watched by
> > userspace.
> 
> Yes, I think the Generic counter makes sense here for the goal to be
> achieved. Thanks for the pointers, I'll see how the counter fits with
> the paradigm.
> 
>    -- Daniel

I suspect you'll define a Signal after the peripheral clock input to the
counter device block; if it's possible to read the instataneous level of
this signal, define a signal_read() callback for it.

Your Synapse action is dependent on the edge sensitivity (i.e. rising,
falling, or both edges) of your counter device; e.g. a rising edge
configuration corresponds to a COUNTER_SYNAPSE_ACTION_RISING_EDGE action
in action_read(). If your counter only ever increases, then you can
report a COUNTER_FUNCTION_INCREASE function in the function_read()
callback.

Finally, the component names should be intuitive so give the Count a
more intuitive name than "stm-cnt". The same idea applies to the name
you give the Signal.

William Breathitt Gray

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ