AQC113: Why does HW PTP timestamping not show up with upstream Linux driver?

[peci1]

With kernel 6.1 and its atlantic driver, AQC113 does not seem to support PTP. And it does not have the aq_enable_ptp module parameter. I checked the upstream code and PTP is force-enabled instead of reading this parameter. So everything should be set up for PTP, yet it is not there.

When I build 2.5.5 version from here, after a few fixes for the other bugs, I could normally load the driver with aq_enable_ptp and ethtool -T was satisfied and showed up the HW timestamping features. What should I do to get the same from the upstream kernel driver?

[Ezzat1198]

Hello, I have the same issue, have you found any solution for it?

[peci1]

No.

[eric957]

Same here as well with a dual AQC-113C board from QNAP.
Driver 2.5.6.
Kernel is 5.18.0-0.deb11.3-rt-amd64.
/sys/class/net/enp14s0/device/driver/module/parameters/aq_enable_ptp is 'Y'.

ethtool -T shows the hardware clock of the aqc113c. I also have an I225 which works, the only difference I see in the ethtool output is in the receive filters. For aqc113c I have:
Hardware Receive Filter Modes:
none
ptpv2-l4-event
ptpv2-l2-event
ptpv2-event
For I225 I have:
Hardware Receive Filter Modes:
none
all

Then ptp4l shows:
ptp4l[191720.023]: driver rejected most general HWTSTAMP filter
ptp4l[191720.023]: ioctl SIOCSHWTSTAMP failed: Operation not supported
ptp4l[191720.091]: port 1: INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)

[Matheus-Garbelini]

@peci1 @Ezzat1198 @eric957

I think I got it. It seems the capabilties reported by the firmware might not be accurate.
There is a line that checks if the hardware supports ptp and fails ptp initialization in this line: https://github.com/Aquantia/AQtion/blob/master/aq_ptp.c#L2072C33-L2072C51

After I added some prints to check the status and comment the error return, I was able to skip that check (!(mbox.info.caps_ex & BIT(CAPS_EX_PHY_PTP_EN))).

Now ethertool to correctly report PTP support:

In summary, it seems that the checks for capabilities does not work well with all firmwares or AQtion hardwares even if PTP support is allowed by the hardware.

[peci1]

And does the PTP actually work? (i.e. do you see timestamps added to the packets)?

[eric957]

And does the PTP actually work? (i.e. do you see timestamps added to the packets)?

Nope, for me it is still the same. I still have the ioctl SIOCSHWTSTAMP error above.
In fact the driver does not enter the "if (a1_ptp)" branch of code; instead it goes into the "if (a2_ptp)" branch below.

[peci1]

Did you update linuxptp from current master branch? There was a bug recently that resulted in this error on some NICs...

[eric957]

Did you update linuxptp from current master branch? There was a bug recently that resulted in this error on some NICs...

It is the same either with release 3.1.1 or the current master branch.
BTW I also had a float divide crash (in ptp4l-git) when the cable was disconnected.

[peci1]

The ptp4l fails on this function:

AQtion/aq_main.c

Line 324 in 340d608

static int aq_ndev_hwtstamp_set(struct aq_nic_s *aq_nic, struct ifreq *ifr)

. Try to put a few debug prints here and there to find out what exactly doesn't work.

[gadgils]

@peci1 were you able to get this resolved? I'm running into the same issue.

[peci1]

No.

[gadgils]

In case anyone runs through this issue again, clean build via make (README.txt Install 1) fixes this issue. DKMS and RPM do not install PTP drivers properly for whatever reason. Tested on both x86-64 and ARM Linux running Linux 22.04.

[peci1]

But this issue is about getting PTP support in upstream kernel driver, not in this one.

[niilona]

Please, check the firmware version driver is using for as thre were older firmwares not supporting PTP. Am not aware if AQC113, but that was the reason with AQC107.

[peci1]

Hmm, is there a list of the FWs? Or how do I know I'm using the latest? Or does the card download firmware via the linux-firmware package?

[niilona]

Shouldnt you look from cmdline : ethtool -i interface-name

[peci1]

ethtool or modinfo can tell me the version of the FW. But how do I know it is the latest one for the given chipset?

[niilona]

At least those I found :
https://www.station-drivers.com/index.php/en-us/component/remository/Drivers/Marvell/LAN/AQC-107-108-100-113--and--AQN-107-108-100/Firmwares/lang,en-us/

[peci1]

You're right, it is probably the firmware.

I took a QNAP QXG-10G2T with two AQC107 with firmwares 3.0.33, which did not report HW timestamping capabilities even with this driver. Then I tried flashing 3.1.109 and later also 3.1.121 and both these enabled HW timestamping. However, both of these firmwares also broke SW timestamping (it is reported, but works wrong with linuxptp). I'll try to figure out why and send a PR.

[niilona]

the may be question, that only Marvel can info you.

[peci1]

So, I got SW timestamping working: see #55 .

Therefore, on firmware 3.1.121, both HW and SW timestamping can work well.

For reference on how to update the firmware on Linux: Download the [https://pmeerw.net/blog/images/atlflashupdate-1.8.0_AQC107-FW-3.1.109.tgz](Linux flash tool) and copy the executable to the [https://www.marvell.com/content/dam/marvell/en/drivers/MarvellFlashUpdate_1.80.3_3.1.121a.zip](newest firmware package). Then run sudo atlflashupdate.

The tool is only for x86_64, but it runs well on arm64 using qemu_user-static and a few libraries copied from a random x86_64 host with similar OS version.

---

You can also find mentions about FW 4.x, but a comment in Linux kernel reveals that it is not generally usable for most AQC cards. FW 3.x is the suggested one.

[peci1]

There were multiple issues with this repo (see PRs #55, #56, #57, #58, #63) plus build issues on newer kernels (#41, #51). For convenience, I've created a branch which contains all of these fixes: https://github.com/ctu-vras/AQtion (devel branch). Feel free to use it until Marvell finds the guts to start fixing their drivers :)