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.

[sushant-gadgil-ai]

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

[peci1]

No.

[sushant-gadgil-ai]

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?