PTP and Software Defined Pins (PPS I/O) regressions on Intel E610 (XT2 & XT4) between kernel in-tree driver and out-of-tree v6.4.4

# Context & Goal
We are upgrading our PTP synchronization infrastructure from **Intel I210 cards** (using the `igb` driver, which handles PTP and PPS hardware input/output perfectly via pins) to **Intel E610 (XT2 and XT4)** cards to benefit from higher clock frequencies and better sync performance.

However, we are encountering critical issues with the `ixgbe` driver regarding **PTP and Software Defined Pins (SDP) configuration**.

We tested two driver versions:
1. **The Ubuntu 26.04 in-tree driver (7.0.0-22-generic):** PTP works, but SDP/programmable pins are completely unavailable.
2. **The latest out-of-tree Intel driver (6.4.4):** SDP pins appear and PPS output commands succeed, but no physical signal is observed on the pins, and `ptp4l` completely fails to initialize due to HWTSTAMP ioctl rejections.

---

# Environment Information
* **OS:** Ubuntu 26.04 LTS (Resolute Raccoon) x86_64
* **Host:** HP Z4 G5 Workstation Desktop PC
* **Kernel:** Linux 7.0.0-22-generic
* **CPU:** Intel(R) Xeon(R) w3-2425 (6) @ 4.40 GHz
* **NIC:** Intel E610 (XT2 / XT4)
* **Firmware Version:** 1.50 0x8000efab 1.3955.0

---

# Behavior with Driver Version: 7.0.0-22-generic (In-tree)

## 1. Ethtool Information
```bash
master@master:~$ sudo ethtool -i eth1
driver: ixgbe
version: 7.0.0-22-generic
firmware-version: 1.50 0x8000efab 1.3955.0
bus-info: 0000:48:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
```
```bash
master@master:~$ sudo ethtool -T eth1
Time stamping parameters for eth1:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
Hardware timestamp provider index: 1
Hardware timestamp provider qualifier: Precise (IEEE 1588 quality)
Hardware timestamp source: MAC
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
all
```

## 2. PTP Status

PTP works perfectly both as Master and Slave with ptp4l.
```bash
master@master:~$ sudo ptp4l -i eth1 -m
ptp4l[9328.330]: selected /dev/ptp1 as PTP clock
ptp4l[9328.349]: port 1 (eth1): INITIALIZING to MASTER on INIT_COMPLETE
ptp4l[9328.349]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[9328.349]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
```

## 3. SDP / PPS Issue

When checking the hardware capabilities using testptp, 0 programmable pins are detected, preventing any use of SDPs, ts2phc, or physical scope verification:
```bash
master@master:~$ sudo testptp -d /dev/ptp1 -c
capabilities:
30000000 maximum frequency adjustment (ppb)
0 programmable alarms
0 external time stamp channels
0 programmable periodic signals
1 pulse per second
0 programmable pins
0 cross timestamping
0 adjust_phase
```
Problem: We cannot access any of the 4 Software Defined Pins (SDP) that each interface is supposed to have. Outputting PPS to an oscilloscope or timestamping incoming external pulses is impossible.

---

# Behavior with Driver Version: 6.4.4 (Latest Out-of-Tree)

In an attempt to fix the SDP limitation, we built and installed the latest ixgbe 6.4.4 driver. It successfully exposes SDP capabilities, but breaks ptp4l entirely and fails to output physical electrical signals.

## 1. Ethtool Information
```bash
master@master:~$ sudo ethtool -i eth1
driver: ixgbe
version: 6.4.4
firmware-version: 1.50 0x8000efab 1.3955.0
bus-info: 0000:48:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
```
```bash
master@master:~$ sudo ethtool -T eth1
Time stamping parameters for eth1:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
Hardware timestamp provider index: 1
Hardware timestamp provider qualifier: Precise (IEEE 1588 quality)
Hardware timestamp source: MAC
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
all
```

## 2. Critical Regression: ptp4l Fails Completely

Running ptp4l immediately fails because the driver rejects the hardware timestamping filter configuration:
```bash
master@master:~$ sudo ptp4l -i eth1 -m
ptp4l[3541.881]: selected /dev/ptp1 as PTP clock
ptp4l[3541.899]: driver rejected most general HWTSTAMP filter
ptp4l[3541.899]: ioctl SIOCSHWTSTAMP failed: Operation not supported
ptp4l[3541.916]: port 1 (eth1): INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[3541.916]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[3541.916]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
```
The execution locks up here, and PTP never initializes.

## 3. SDP / PPS Issue (Software configuration OK, No hardware output)

With 6.4.4, testptp now properly reports 1 programmable pin:
```bash
master@master:~$ sudo testptp -d /dev/ptp1 -c
capabilities:
500000000 maximum frequency adjustment (ppb)
0 programmable alarms
0 external time stamp channels
1 programmable periodic signals
0 pulse per second
1 programmable pins
0 cross timestamping
0 adjust_phase
```

We can probe, map, and request periodic output successfully on the software side:
```bash
master@master:~$ sudo testptp -d /dev/ptp1 -l
name SDP0 index 0 func 0 chan 0

master@master:~$ sudo testptp -d /dev/ptp1 -L 0,2
set pin function okay

master@master:~$ sudo testptp -d /dev/ptp1 -p 1000000000
periodic output request okay
```

Problem: Even though the commands report okay, no physical electrical signal (PPS) is outputted on any of the physical pins when measured with an oscilloscope.

This exact same procedure works flawlessly on our Intel I210 hardware.

# Expected Behavior

1. The driver should support hardware timestamping filters properly so ptp4l can initialize successfully (as it did in the 7.0.0-22-generic kernel in-tree driver).

2. The driver should properly expose the 4 Software Defined Pins (SDP) to testptp/ts2phc.

3. When configuring an SDP pin to output a periodic signal (PPS), the physical pin on the Intel E610 card should generate the corresponding electrical signal.

Reproduce the two configurations with ethtool, testptp, and ptp4l, then compare the ixgbe driver's PTP/HWTSTAMP and SDP behavior between the in-tree 7.0.0-22-generic driver and out-of-tree 6.4.4. Use the testptp pin and periodic-output commands and the ptp4l initialization failure as checkpoints. Done means ptp4l initializes, the expected SDP pins are exposed, and a configured PPS signal is measurable on the physical pin.

Written by the indexing model from the issue text.