wifi: ath9k: Add PTP patch from wifi-ptp project by 6by9 · Pull Request #6882 · raspberrypi/linux

6by9 · 2025-06-04T17:30:05Z

Applies and updates the patch from
https://github.com/zlab-pub/wifi-ptp/blob/main/ath9k.diff

6by9 · 2025-06-04T17:34:34Z

I am NOT proposing that this gets merged here, but created it for #4358

jacob-keller

Here's what I think you want to implement, assuming sc->cc_mult is the base multiplier. I also suggested converting the ath_warn to ath_dbg so that its not spammy unless enabled as frequency can be adjusted multiple times per second depending on the synchronization rate. Hope this helps!

jacob-keller · 2025-06-12T02:36:09Z

drivers/net/wireless/ath/ath9k/ptp.c

+    mult = sc->cc_mult;
+    adj = mult;
+    adj *= scaled_ppm;
+    diff = div_u64(adj, 1000000000ULL);


The mistake here is still using 1,000,000,000 (1 billion). You need to use 1million * 2^16, but you can actually just replace this all with adjust_by_scaled_ppm.

jacob-keller · 2025-06-12T02:45:34Z

drivers/net/wireless/ath/ath9k/ptp.c

+#if 0
+    struct ath_softc *sc = container_of(ptp, struct ath_softc, ptp_clock_info);
+    unsigned long flags;
+    int neg_adj = 0;
+    u32 mult, diff;
+    u64 adj;
+
+    if (scaled_ppm < 0) {
+        neg_adj = -1;
+        scaled_ppm = -scaled_ppm;
+    }
+    mult = sc->cc_mult;
+    adj = mult;
+    adj *= scaled_ppm;
+    diff = div_u64(adj, 1000000000ULL);
+
+    spin_lock_irqsave(&sc->systim_lock, flags);
+    timecounter_read(&sc->tc);
+    sc->cc.mult = neg_adj ? mult - diff : mult + diff;
+    spin_unlock_irqrestore(&sc->systim_lock, flags);
+
+    ath_warn(ath9k_hw_common(sc->sc_ah), "phc adjust adj=%llu freq=%u\n", adj, diff);
+#endif
+
+    return 0;


Suggested change

#if 0

struct ath_softc *sc = container_of(ptp, struct ath_softc, ptp_clock_info);

unsigned long flags;

int neg_adj = 0;

u32 mult, diff;

u64 adj;

if (scaled_ppm < 0) {

neg_adj = -1;

scaled_ppm = -scaled_ppm;

}

mult = sc->cc_mult;

adj = mult;

adj *= scaled_ppm;

diff = div_u64(adj, 1000000000ULL);

spin_lock_irqsave(&sc->systim_lock, flags);

timecounter_read(&sc->tc);

sc->cc.mult = neg_adj ? mult - diff : mult + diff;

spin_unlock_irqrestore(&sc->systim_lock, flags);

ath_warn(ath9k_hw_common(sc->sc_ah), "phc adjust adj=%llu freq=%u\n", adj, diff);

#endif

return 0;

struct ath_softc *sc = container_of(ptp, struct ath_softc, ptp_clock_info);

unsigned long flags;

spin_lock_irqsave(&sc->systim_lock, flags);

timecounter_read(&sc->tc);

sc->cc.mult = adjust_by_scaled_ppm(sc->cc_mult, scaled_ppm);

spin_unlock_irqrestore(&sc->systim_lock, flags);

ath_dbg(ath9k_hw_common(sc->sc_ah), ATH_DBG_CONFIG, "phc adjust adj=%llu freq=%u\n", adj, diff);

return 0;

The whitespace is probably not correct here for kernel style, but you should get the idea. You could also pull adjust_by_scaled_ppm to outside the lock, but I don't think its necessary, since its really just a few multiplications and division.

Whitespace and coding style are a bit of a mess generally with these changes, but that can be a task for others to fix up if they were ever to think of upstreaming them (I have no idea if it would even be considered upstream).
I did try a checkpatch --fix-inplace, but it only addressed a small fraction of the issues.

Applies and updates the patch from https://github.com/zlab-pub/wifi-ptp/blob/main/ath9k.diff

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

wirelessOJ · 2025-07-03T18:21:06Z

@jacob-keller @6by9 @CALMorACT When I ransudo./ptp4l -I wlan0 -p /dev/pptp0 -mthere was an error that suggested a driver issue. I wondered if this was due to how the ath9k.diff was forward ported. Looking at the logs using sudo dmesg | grep ath9k

[ 4.181657] ath9k 0000:01:00.0: enabling device (0000 -> 0002)
[ 4.360628] ath9k 0000:01:00.0: Failed to initialize device
[ 4.360662] ath9k 0000:01:00.0: probe with driver ath9k failed with error -12

It looks like the device (PCI 0000:01:00.0) tried to load with ath9k but failed.

I am wondering if I could have assistance troubleshooting this.

Thank you!

pelwell · 2025-07-03T21:26:07Z

Error 12 is ENOMEM, a pretty fundamental failure while probing. I don't believe it's actually run out of memory, but perhaps it's because of the PCIe space exposed by the card. What does lspci -v report?

jacob-keller · 2025-07-04T01:04:29Z

Ya. That looks like a pretty fundamental issue with loading the wireless driver.

wirelessOJ · 2025-07-04T16:45:18Z

lspci -v reports:

00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2711 PCIe Bridge (rev 20) (prog-if 00 [Normal decode])
      Device tree node: /sys/firmware/devicetree/base/scb/pcie@7d500000/pci@0,0
      Flags: bus master, fast devsel, latency 0, IRQ 27
      Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
      Memory behind bridge: 00000000-000fffff [size=1M] [32-bit]
      Prefetchable memory behind bridge: [disabled] [64-bit]
      Capabilities: <access denied>
      Kernel driver in use: pcieport

01:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01)
      Subsystem: Qualcomm Atheros AR93xx Wireless Network Adapter
      Flags: fast devsel, IRQ 27
      Memory at 600000000 (64-bit, non-prefetchable) [size=128K]
      Expansion ROM at 600020000 [virtual] [disabled] [size=64K]
      Capabilities: <access denied>
      Kernel modules: ath9k

wirelessOJ · 2025-07-07T18:09:50Z

so isn't this a problem with how the ath9k driver was forward ported?

wirelessOJ · 2025-07-11T20:42:40Z

@6by9 @pelwell @jacob-keller @CALMorACT If anyone has any advice, I believe something is wrong with the kernel and I am uncertain how to move forward

jacob-keller · 2025-07-11T21:07:17Z

Unfortunately I don't have much experience with wireless drivers :(

wirelessOJ · 2025-07-14T18:17:31Z

I ended up adding cma=256M and dtoverlay=pcie-32bit-dma to the config.txt file and that has resolved the ath9k initialization errors I was seeing. When I run lscpi -v I can now see too that the kernel driver ath9k is being used.

jacob-keller · 2025-07-14T23:22:31Z

Try increasing the tx_timestamp_timeout config value for ptp4l. The timestamps may not be returned within the default time, depending on driver/hardware implementation. If a value of 100 or 200 milliseconds still fails then it's likely a bug with the driver never reporting a timestamp for one of the packets.

wirelessOJ · 2025-07-15T12:36:34Z

100 and 200 result in the same error. I am wondering...

when I run ls /sys/class/ptp there is a ptp0 and when I then run readlink /sys/class/ptp/ptp0/device

it points to:

../../../unimac-mdio--19:00

but then when I run ls -l /sys/class/net/*/device

lrwxrwxrwx 1 root root 0 Jul 14 10:39 /sys/class/net/eth0/device -> ../../../fd580000.ethernet

lrwxrwxrwx 1 root root 0 Jul 14 10:39 /sys/class/net/wlan0/device -> ../../../0000:01:00.0

lrwxrwxrwx 1 root root 0 Jul 14 10:39 /sys/class/net/wlan1/device -> ../../../mmc1:0001:1

It shows that the ptp0 devices is the onboard ethernet MDIO interface.

IF the ath9k driver patch was applied correctly, shouldn't there be a wlan0 ptp0 device present? Likewise, I am wondering if the driver is imported correctly, if the error I first see after running./ptp4lthat says interface 'wlan0' does not support requested timestamping mode would still show up as an error no matter what?

I am looking at this issue: zlab-pub/wifi-ptp#8

"Please ensure the "ls /sys/class/net/${WLAN_DEV}/device/ptp" has the right output, it means there is a available PHC/PTP clock for you and the driver patch successfully. You can read the 'dmesg' output for more info if this step is error for you"

I currently do not have a device under wlan0 that is a ptp device. I am thinking that this might indicate a problem with the way the driver patch was applied to this kernel.

jacob-keller · 2025-07-15T18:59:23Z

Does your ptp4l command hardcode the ptp device? If so, you should stop doing that and rely on the ethtool -T autodetection. What does ethtool -T show for the wlan0 device?

jacob-keller · 2025-07-15T19:00:31Z

If you use the wrong ptp device for a given network interface things will not work. Maybe the ath9k driver didn't implement the get_ts_info appropriately?

wirelessOJ · 2025-07-16T18:07:29Z

Yes, I don't believe it is implementing as it should. There is no phc_device associated with wlan0.

This is what it shows for the wlan0 interface

ethtool -T wlan0
Time stamping parameters for wlan0:
Capabilities:
      software-receive
      software-system-clock
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes: none
Hardware Receive Filter Modes: none

jacob-keller · 2025-07-16T19:15:58Z

You need to make sure the .get_ts_info callback for ethtool is implemented and reports the clock number. When i am back at a real PC I will take a look and see if I can propose something

…

On Wed, Jul 16, 2025, 11:07 AM OJD ***@***.***> wrote: *wirelessOJ* left a comment (raspberrypi/linux#6882) <#6882 (comment)> This is what it shows for the wlan0 interface ethtool -T wlan0 Time stamping parameters for wlan0: Capabilities: software-receive software-system-clock PTP Hardware Clock: none Hardware Transmit Timestamp Modes: none Hardware Receive Filter Modes: none — Reply to this email directly, view it on GitHub <#6882 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGVRX5BO4NXNLJ2BHLOHOL3I2IHNAVCNFSM6AAAAAB6THDSISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZZG4YTONBWG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

wirelessOJ · 2025-07-17T14:06:42Z

@jacob-keller thank you! I am also just worried because I do not see the correct output for ls /sys/class/net/${WLAN_DEV}/device/ptp

when I run ethtool -T wlan0 the output is:

Time stamping parameters for wlan0:
Capabilities:
              software-receive
              software-system-clock
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes: none
Hardware Receive Filter Modes: none

I would think if the linuxptp patch was implemented correctly with the driver patch it should display PTP Hardware Clock option for the wlan0.

@CALMorACT would you have any advice on this?

jacob-keller · 2025-07-17T15:39:58Z

This has nothing to do with linuxptp project, it's the kernel driver which needs updating :)

wirelessOJ · 2025-07-17T16:04:23Z

the unfortunate truth

wirelessOJ · 2025-07-21T18:10:09Z

I now have the correct kernel patches compiled and applied, but when I run:

sudo ./ptp4l -i wlan1 -p /dev/ptp0 -m -H

the output stalls atassuming the grade master role

any thoughts?

jacob-keller · 2025-07-21T22:09:37Z

That typically means it's not seeing any other announce messages on the network

wirelessOJ · 2025-07-30T20:59:37Z

@6by9 @pelwell @jacob-keller @CALMorACT I now can correctly see a ptp device under wlan0. However, when I run ptp, software or hardware, it aborts after assuming grandmaster role.

This is part of the output from the verbose log:

ptp4l[85387.147]: port 1: received link status notification
ptp4l[85387.147]: interface index 3 is up
ptp4l[85393.320]: port 1: announce timeout
ptp4l[85393.320]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[85393.320]: selected local clock 000e8e.fffe.5a7295 as best master
ptp4l[85393.320]: assuming the grand master role
ptp4l[85393.321]: port 1: master tx announce timeout
ptp4l[85393.321]: port 1: setting asCapable
ptp4l[85394.320]: port 1: master sync timeout
ptp4l[85394.321]: port 1: tx sync is calling interpolate
Aborted

@CALMorACT do you have any advice for this?

jacob-keller · 2025-08-11T19:18:10Z

That's very weird...

wirelessOJ · 2025-08-11T20:09:32Z

Do you have any concept of where I can look at the patched kernel driver to resolve this?

6by9 mentioned this pull request Jun 4, 2025

Add CM4 supporting for kernel 4.19.y (back porting) #4358

Closed

6by9 force-pushed the rpi-6.12.y-ath9k-ptp branch from a81b104 to 021bac0 Compare June 4, 2025 17:52

This was referenced Jun 4, 2025

More detailed description on how to patch driver zlab-pub/wifi-ptp#7

Open

Forward port ath9k.diff patch to kernel 6.12 zlab-pub/wifi-ptp#10

Open

6by9 force-pushed the rpi-6.12.y-ath9k-ptp branch from 021bac0 to 3b8126e Compare June 4, 2025 20:56

jacob-keller reviewed Jun 12, 2025

View reviewed changes

6by9 added 2 commits June 12, 2025 17:19

wifi: ath9k: Add PTP patch from wifi-ptp project

e8ed8e2

Applies and updates the patch from https://github.com/zlab-pub/wifi-ptp/blob/main/ath9k.diff

wireless: ath9k: Fix up PTP patches based on updated understanding

8b8afcd

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

6by9 force-pushed the rpi-6.12.y-ath9k-ptp branch from 3b8126e to 8b8afcd Compare June 12, 2025 16:35

wireless: ath9k: Fix build warning

0320eb2

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>

wirelessOJ mentioned this pull request Jul 15, 2025

Some problems when setup zlab-pub/wifi-ptp#8

Open

Conversation

6by9 commented Jun 4, 2025

Uh oh!

6by9 commented Jun 4, 2025

Uh oh!

jacob-keller left a comment

Choose a reason for hiding this comment

Uh oh!

jacob-keller Jun 12, 2025

Choose a reason for hiding this comment

Uh oh!

wirelessOJ Jun 12, 2025

Choose a reason for hiding this comment

Uh oh!

jacob-keller Jun 12, 2025

Choose a reason for hiding this comment

Uh oh!

jacob-keller Jun 12, 2025

Choose a reason for hiding this comment

Uh oh!

6by9 Jun 12, 2025

Choose a reason for hiding this comment

Uh oh!

wirelessOJ commented Jul 3, 2025

Uh oh!

pelwell commented Jul 3, 2025

Uh oh!

jacob-keller commented Jul 4, 2025

Uh oh!

wirelessOJ commented Jul 4, 2025

Uh oh!

wirelessOJ commented Jul 7, 2025

Uh oh!

wirelessOJ commented Jul 11, 2025

Uh oh!

jacob-keller commented Jul 11, 2025

Uh oh!

wirelessOJ commented Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jacob-keller commented Jul 14, 2025

Uh oh!

wirelessOJ commented Jul 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jacob-keller commented Jul 15, 2025

Uh oh!

jacob-keller commented Jul 15, 2025

Uh oh!

wirelessOJ commented Jul 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jacob-keller commented Jul 16, 2025 via email

Uh oh!

wirelessOJ commented Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jacob-keller commented Jul 17, 2025

Uh oh!

wirelessOJ commented Jul 17, 2025

Uh oh!

wirelessOJ commented Jul 21, 2025

Uh oh!

jacob-keller commented Jul 21, 2025

Uh oh!

wirelessOJ commented Jul 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jacob-keller commented Aug 11, 2025

Uh oh!

wirelessOJ commented Aug 11, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

wirelessOJ commented Jul 14, 2025 •

edited

Loading

wirelessOJ commented Jul 15, 2025 •

edited

Loading

wirelessOJ commented Jul 16, 2025 •

edited

Loading

wirelessOJ commented Jul 17, 2025 •

edited

Loading

wirelessOJ commented Jul 30, 2025 •

edited

Loading