raspberrypi
wifi: ath9k: Add PTP patch from wifi-ptp project
Applies and updates the patch from https://github.com/zlab-pub/wifi-ptp/blob/main/ath9k.diff
@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!
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?
Ya. That looks like a pretty fundamental issue with loading the wireless driver.
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
@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
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.
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.
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: https://github.com/zlab-pub/wifi-ptp/issues/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.
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?
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?
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
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) https://github.com/raspberrypi/linux/pull/6882#issuecomment-3079717467
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 https://github.com/raspberrypi/linux/pull/6882#issuecomment-3079717467, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGVRX5BO4NXNLJ2BHLOHOL3I2IHNAVCNFSM6AAAAAB6THDSISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZZG4YTONBWG4 . You are receiving this because you were mentioned.Message ID: @.***>
@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?
This has nothing to do with linuxptp project, it's the kernel driver which needs updating :)
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?
That typically means it's not seeing any other announce messages on the network
@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?
Do you have any concept of where I can look at the patched kernel driver to resolve this?