Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

CAN Bus hardware timestamps don't come from the hardware

Open
  • Is something wrong?
#122 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
c
Domain
embedded-iot, operating-systems

Research direction

Start with drivers/net/can/spi/mcp251xfd/mcp251xfd-timestamp.c and mcp251xfd.h, reading the timestamp initialization and skb timestamp helper. Trace how the mcp2518fd hardware timestamp reaches the socket buffer and compare the clock bases used there. Done means the hardware timestamp is preserved, the time base is monotonic, and the previous receive-time replacement is removed.

Written by the indexing model from the issue text.

Description

Limelight

The mcp251xfd driver has been patched to have the "hardware" timestamps be based on the monotonic clock, except it wipes away the hardware timestamp completely and replaces it with the current monotonic time at the time the packet is received by the driver:

diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd.h b/drivers/net/can/spi/mcp251xfd/mcp251xfd.h
index dcbbd2b2fae8273844bd1843209ecd5a2ed3a43c..5ee4672e48136f7de6bf06be0a14fe5d6468a1d3 100644
--- a/drivers/net/can/spi/mcp251xfd/mcp251xfd.h
+++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd.h
@@ -825,7 +825,7 @@ static inline void mcp251xfd_skb_set_timestamp(struct sk_buff *skb, u64 ns)
 {
        struct skb_shared_hwtstamps *hwtstamps = skb_hwtstamps(skb);

-       hwtstamps->hwtstamp = ns_to_ktime(ns);
+       hwtstamps->hwtstamp = ktime_get_raw();
 }

 static inline

This means that there is nondeterministic latency between the actual reception time and the reported timestamp. Instead, the driver should be patched to keep the timestamp from the mcp2518fd hardware but switch the time base to the monotonic clock (and the previous patch should be reverted):

diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-timestamp.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-timestamp.c
index 202ca0d24d03b9f5bebba23a9f8d0e6f6422c728..3b6b47cb09a4e09f1b25a8a339d7a837a527806a 100644
--- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-timestamp.c
+++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-timestamp.c
@@ -53,7 +53,7 @@ void mcp251xfd_timestamp_init(struct mcp251xfd_priv *priv)

 void mcp251xfd_timestamp_start(struct mcp251xfd_priv *priv)
 {
-       timecounter_init(&priv->tc, &priv->cc, ktime_get_real_ns());
+       timecounter_init(&priv->tc, &priv->cc, ktime_get_ns());
        schedule_delayed_work(&priv->timestamp,
                              MCP251XFD_TIMESTAMP_WORK_DELAY_SEC * HZ);
 }

This patch also uses CLOCK_MONOTONIC, not CLOCK_MONOTONIC_RAW as the current patch does, since we're using CLOCK_MONOTONIC everywhere else.

Dominant language
Java
Stars
190
Forks
25
Avg merge
6h 7m
Merged PRs (30d)
13

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from wpilibsuite/SystemcoreTesting

All issues in wpilibsuite/SystemcoreTesting

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.