linuxptp-users — Open discussion on using the linuxptp software.

Re: [Linuxptp-users] Intel i210 PTP HW timestamping not supported

[Richard C. <ric...@gm...>]

On Tue, Apr 11, 2023 at 05:03:31AM +1000, Aris Theocharides via Linuxptp-users wrote:
> 
> The card in question is a 4-port i210 PCIe - https://www.lr-link.com/products/LRES3004PT.html

That is a very strange looking card.  I guess it has 4 i210 ASICs?

What is under the giant heat sink?

Thanks,
Richard

Re: [Linuxptp-users] Intel i210 PTP HW timestamping not supported

[Richard C. <ric...@gm...>]

On Tue, Apr 11, 2023 at 05:03:31AM +1000, Aris Theocharides via Linuxptp-users wrote:
> 
> The card in question is a 4-port i210 PCIe - https://www.lr-link.com/products/LRES3004PT.html
> 
> It seems to behave for general use, but I can’t use it without PTP working. 
> 
> A single-port PCIe i210 behaves perfectly on the same mainboard, so I assume that something interesting is happening in the i210 driver for this card.
> 
> For interest, I have 2 of these cards, and both exhibit the same behaviour (so, unlikely to be a failure of a specific card). A single-port i210 card work perfectly.  
> 
> Not sure where from here. Maybe a full debug trace?

Probably the generic work (see igb_ptp_tx_work()) is being delayed too
much on your RT kernels.

Try increasing tx_timestamp_timeout to a really large value, like 1000.

Also try a non RT kernel.

Proper fix is to let driver use ptp_aux_kworker/do_aux_work and set
kernel thread to SCHED_FIFO at high priority.

FWIW I have a box with three 1-port i210 PCIe cards that runs fine on
vanilla kernel.

HTH,
Richard

Re: [Linuxptp-users] Layer 2 ptp on Nvidia Orin

[Richard C. <ric...@gm...>]

On Mon, Apr 10, 2023 at 07:09:23PM +0000, Greiner, Andreas wrote:
> We are using these versions:
> 
> ptp4l: 3.1-00224-gd4adf87
> kernel: 5.10.104-tegra
> 
> Are there any mistakes on our side? What else can we try?

This is likely a bug in the vendor kernel.  You should ask them to fix
it for you.

Thanks,
Richard

[Linuxptp-users] Layer 2 ptp on Nvidia Orin

[Greiner, A. <and...@iv...>]

Hello,

we are currently trying to use ptp4l on a NVIDIA Orin to sync with a couple of sensors using layer 2 ptp.
However, we get an error when starting the master instance on the Orin.

               uam@hubble:~$ sudo ptp4l -i eth0 -m -2 -l 7
               ptp4l[922.980]: selected /dev/ptp0 as PTP clock
               ptp4l[923.053]: driver rejected most general HWTSTAMP filter
               ptp4l[923.059]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range
               ptp4l[923.120]: port 1 (eth0): INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
               ptp4l[923.121]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
               ptp4l[923.121]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE

As far as I can tell it should be supported by the hardware though, as this output of ethtool suggests:

               uam@hubble:~$ ethtool -T eth0
               Time stamping parameters for eth0:
               Capabilities:
                              hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
                              software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
                              hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
                              software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
                              software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
                              hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
               PTP Hardware Clock: 0
               Hardware Transmit Timestamp Modes:
                              off                   (HWTSTAMP_TX_OFF)
                              on                    (HWTSTAMP_TX_ON)
                              one-step-sync         (HWTSTAMP_TX_ONESTEP_SYNC)
               Hardware Receive Filter Modes:
                              none                  (HWTSTAMP_FILTER_NONE)
                              ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
                              ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
                              ptpv2-l4-sync         (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
                              ptpv2-l4-delay-req    (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
                              ptpv2-l2-sync         (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
                              ptpv2-l2-delay-req    (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
                              ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)

We are using these versions:

ptp4l: 3.1-00224-gd4adf87
kernel: 5.10.104-tegra

Are there any mistakes on our side? What else can we try?

Kind regards,
Andreas

Re: [Linuxptp-users] Intel i210 PTP HW timestamping not supported

[Aris T. <ar...@ma...>]

The card in question is a 4-port i210 PCIe - https://www.lr-link.com/products/LRES3004PT.html

It seems to behave for general use, but I can’t use it without PTP working. 

A single-port PCIe i210 behaves perfectly on the same mainboard, so I assume that something interesting is happening in the i210 driver for this card.

For interest, I have 2 of these cards, and both exhibit the same behaviour (so, unlikely to be a failure of a specific card). A single-port i210 card work perfectly.  

Not sure where from here. Maybe a full debug trace?

Aris



> On 10 Apr 2023, at 11:09 pm, Richard Cochran <ric...@gm...> wrote:
> 
> On Mon, Apr 10, 2023 at 10:31:05PM +1000, Aris Theocharides via Linuxptp-users wrote:

> [snip]

>> Debian 12 Kernel Module (based on Linux 6.1.20 kernel, modified by Debian):
>> 
>>> filename:       /lib/modules/6.1.20-rt8/kernel/drivers/net/ethernet/intel/igb/igb.ko
> 
> Hm, Debian is shipping a PREEMPT_RT kernel?  That is news to me.


Yes, albeit not the default, a (signed) RT variant is available from the official repos.


>> root@controller:~/proj/igb-5.13.16/src# ptp4l -i enp3s0 -m -2 -H
>> ptp4l[11754.773]: selected /dev/ptp0 as PTP clock
>> ptp4l[11754.818]: port 1 (enp3s0): INITIALIZING to LISTENING on INIT_COMPLETE
>> ptp4l[11754.818]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
>> ptp4l[11754.819]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
>> ptp4l[11760.857]: port 1 (enp3s0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
>> ptp4l[11760.857]: selected local clock 6cb311.fffe.663910 as best master
>> ptp4l[11760.857]: port 1 (enp3s0): assuming the grand master role
>> ptp4l[11761.868]: timed out while polling for tx timestamp
>> ptp4l[11761.868]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
> 
> Did you try this?   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


Yes, I tried increasing tx_timestamp_timeout - the reported issue persists.


> [snip]

[Linuxptp-users] ptp4l passive phc synchronization with active phc in linux bonding

[shashank v. <sha...@gm...>]

Hello experts,
I need to configure PTP with linux bonding.

I can see it is supported in active-passive configuration.

I have following queries related to functioning of PTP with active-passive
bonding:

   - Will passive/standby slave PHC synchronize itself with active slave
   PHC when active-passive NIC ports are on different PHCs?
   - Does the passive NIC port's PHC is ready to take-over when the current
   active slave NIC goes down or does this require the passive NIC's PHC to
   synchronize first?


Thanks and regards
Shashank Varshney

Re: [Linuxptp-users] Intel i210 PTP HW timestamping not supported

[Richard C. <ric...@gm...>]

On Mon, Apr 10, 2023 at 10:31:05PM +1000, Aris Theocharides via Linuxptp-users wrote:

> Intel Module (from SF, v 5.13.16):

Can't comment on that, since not mainline linux.

> Debian 12 Kernel Module (based on Linux 6.1.20 kernel, modified by Debian):
> 
> > filename:       /lib/modules/6.1.20-rt8/kernel/drivers/net/ethernet/intel/igb/igb.ko

Hm, Debian is shipping a PREEMPT_RT kernel?  That is news to me.

> root@controller:~/proj/igb-5.13.16/src# ptp4l -i enp3s0 -m -2 -H
> ptp4l[11754.773]: selected /dev/ptp0 as PTP clock
> ptp4l[11754.818]: port 1 (enp3s0): INITIALIZING to LISTENING on INIT_COMPLETE
> ptp4l[11754.818]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
> ptp4l[11754.819]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
> ptp4l[11760.857]: port 1 (enp3s0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> ptp4l[11760.857]: selected local clock 6cb311.fffe.663910 as best master
> ptp4l[11760.857]: port 1 (enp3s0): assuming the grand master role
> ptp4l[11761.868]: timed out while polling for tx timestamp
> ptp4l[11761.868]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug

Did you try this?   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> AVNU Module (from AVNU):
> 
> > filename:       /lib/modules/6.1.20-rt8/kernel/drivers/net/igb_avb/igb_avb.ko
> > version:        5.3.2_AVB

Can't comment on that, since not mainline linux.  IMHO avnu driver
stuff is of dubious quality.

Thanks,
Richard

[Linuxptp-users] Intel i210 PTP HW timestamping not supported

[Aris T. <ar...@ma...>]

I’m trying to get an I210 card working with LinuxPTP. The command I use works fine on another interface:

Debian 12 Kernel Module (I225 interface, eno2):

> ^Croot@controller:~/proj/igb_avb/kmod# ptp4l -i eno2 -m -2 -H
> ptp4l[12580.495]: selected /dev/ptp4 as PTP clock
> ptp4l[12580.570]: port 1 (eno2): INITIALIZING to LISTENING on INIT_COMPLETE
> ptp4l[12580.570]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
> ptp4l[12580.570]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
> ptp4l[12588.253]: port 1 (eno2): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> ptp4l[12588.253]: selected local clock 3cecef.fffe.7b900b as best master
> ptp4l[12588.253]: port 1 (eno2): assuming the grand master role



But for any of the range of I210 driver’s I’ve tried, I can’t get it to work.


Intel Module (from SF, v 5.13.16):

> filename:       /lib/modules/6.1.20-rt8/updates/drivers/net/ethernet/intel/igb/igb.ko
> version:        5.13.16


^Croot@controller:~/proj/igb-5.13.16/src# ptp4l -i enp3s0 -m -2 -H
ptp4l[8769.060]: selected /dev/ptp0 as PTP clock
ptp4l[8769.110]: driver rejected most general HWTSTAMP filter
ptp4l[8769.110]: ioctl SIOCSHWTSTAMP failed: Operation not supported
ptp4l[8769.158]: port 1 (enp3s0): INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[8769.158]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[8769.158]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE


Debian 12 Kernel Module (based on Linux 6.1.20 kernel, modified by Debian):

> filename:       /lib/modules/6.1.20-rt8/kernel/drivers/net/ethernet/intel/igb/igb.ko

root@controller:~/proj/igb-5.13.16/src# ptp4l -i enp3s0 -m -2 -H
ptp4l[11754.773]: selected /dev/ptp0 as PTP clock
ptp4l[11754.818]: port 1 (enp3s0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[11754.818]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[11754.819]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[11760.857]: port 1 (enp3s0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[11760.857]: selected local clock 6cb311.fffe.663910 as best master
ptp4l[11760.857]: port 1 (enp3s0): assuming the grand master role
ptp4l[11761.868]: timed out while polling for tx timestamp
ptp4l[11761.868]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[11761.868]: port 1 (enp3s0): send sync failed
ptp4l[11761.868]: port 1 (enp3s0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)


Linux 6.1 Kernel Module (string from 6.1 Linux Kernel tag):

> filename:       /lib/modules/6.1.20-rt8/updates/igb.ko

root@controller:~/proj/linux-6.1/drivers/net/ethernet/intel/igb# ptp4l -i enp3s0 -m -2 -H
ptp4l[12277.722]: selected /dev/ptp0 as PTP clock
ptp4l[12277.794]: port 1 (enp3s0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[12277.794]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[12277.795]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[12284.253]: port 1 (enp3s0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[12284.253]: selected local clock 6cb311.fffe.663910 as best master
ptp4l[12284.253]: port 1 (enp3s0): assuming the grand master role
ptp4l[12285.264]: timed out while polling for tx timestamp
ptp4l[12285.264]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[12285.264]: port 1 (enp3s0): send sync failed
ptp4l[12285.264]: port 1 (enp3s0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)


AVNU Module (from AVNU):

> filename:       /lib/modules/6.1.20-rt8/kernel/drivers/net/igb_avb/igb_avb.ko
> version:        5.3.2_AVB

> root@controller:~/proj/igb_avb/kmod# ptp4l -i enp3s0 -m -2 -H
> ptp4l[12490.551]: selected /dev/ptp0 as PTP clock
> ptp4l[12490.614]: port 1 (enp3s0): INITIALIZING to LISTENING on INIT_COMPLETE
> ptp4l[12490.614]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
> ptp4l[12490.614]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
> ptp4l[12497.419]: port 1 (enp3s0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
> ptp4l[12497.419]: selected local clock 6cb311.fffe.663910 as best master
> ptp4l[12497.419]: port 1 (enp3s0): assuming the grand master role
> ptp4l[12498.429]: timed out while polling for tx timestamp
> ptp4l[12498.430]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
> ptp4l[12498.430]: port 1 (enp3s0): send sync failed
> ptp4l[12498.430]: port 1 (enp3s0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)



There are also a number of other issues with the Intel i210 card. "Detected Tx Unit Hang", "exceed max 2 second” for example.

I’m a bit stuck - any hints from anyone who has it working?

Aris

Re: [Linuxptp-users] ptp4l support for multiple time domains

[Miroslav L. <mli...@re...>]

On Wed, Apr 05, 2023 at 07:04:12PM +0000, Nemo Crypto wrote:
> Hi All,
> 
> I have a use case where my SoC needs to be configured as two Time Follower or Slave to 2 different PTP Domains (Domain 0 & Domain 1) through a single interface.
> 
> SoC supports HW timestamping on this interface.
> 
> How to configure the ptp4l to achieve this? Is this supported by linuxptp?

It's supported in the latest development code. It's using virtual
clocks provided by the kernel, each having its own ptp4l instance. You
can create the vclocks and start ptp4l+phc2sys instances manually or
let timemaster handle it. See the man page.

-- 
Miroslav Lichvar

[Linuxptp-users] ptp4l support for multiple time domains

[Nemo C. <nem...@gm...>]

Hi All,

I have a use case where my SoC needs to be configured as two Time Follower or Slave to 2 different PTP Domains (Domain 0 & Domain 1) through a single interface.

SoC supports HW timestamping on this interface.

How to configure the ptp4l to achieve this? Is this supported by linuxptp?

Thanks,
Nemo

Re: [Linuxptp-users] negative delay issue

[Merlin He <mer...@gm...>]

ok, i'm going to submit a patch for this issue

Miroslav Lichvar <mli...@re...> 于2023年3月29日周三 17:09写道：

> On Tue, Mar 28, 2023 at 10:24:47PM +0800, Merlin He wrote:
> > hello team,
> >
> > I found that port_nrate_calculate() save the first ingress1 before slave
> > clock jumping, if the offset of master and slave is too large, this may
> > results in an extremly small nrate_ratio value, and cause the nagative
> > delay issue.
> > so, is this a problem please?
>
> There might be an assumption that the clock if running free. I'm not
> very familiar with this feature.
>
> > what about port_nrate_calculate() sampling the first ingress1 until servo
> > entering lock state?
> > like this:
> > 1028   if (tmv_is_zero(n->ingress1) && *clock_servo_state(p->clock) ==
> > SERVO_LOCKED*) {
> > 1029     n->ingress1 = ingress;
> > 1030     n->origin1 = origin;
> > 1031     return;
> > 1032   }
>
> Another option might be calling port_nrate_initialize() on clock jump.
>
> --
> Miroslav Lichvar
>
>

Re: [Linuxptp-users] DSA bridge PTP issues

[Vladimir O. <ol...@gm...>]

On Wed, Mar 29, 2023 at 02:35:56PM +0200, Riccardo Laiolo wrote:
> Those kernel options were unselected. I've recompiled the kernel. Still not working.
> 
> On A I'm running ptp4l on IPv4 transport and highest priority (so, always grand master).
> 
> On B, ptp4l with standard priority don't see any master on the network and promotes itself as gm.
> On A I see there is a new master, but A remains gm due to higher priority.
> 
> A log:
> 	root@imx8mp-var-dart:~# ptp4l -i eth0 --tx_timestamp_timeout=40 -m -4 --priority1=0 -P
> 
> B log: (here you see i passed two lan ports to force boundary clock mode, don't know if this is relevant. Anyway, there was ptp traffic on lan2 only)
> 
> It looks like outgoing ptp packets get routed fine while incoming ones get ignored/filtered/sucked-into-void

Start simple first. Remove the bridge. Use a single interface. Make sure
you have an IP address on that interface. Then add things one by one.

> Is there any downsides using -2 instead the default IPv4 transport?

Define "downsides"?

> 
> By the way sometimes I had some "port [n]: received SYNC without timestamp" messages when using -2 that went away
> when I added the broute on EtherType 0x88F7.

I'm not sure that's related, but okay...

> > Here, there may simply be too much MDIO traffic, and 40 ms is not enough
> > to collect timestamps. Can you try increasing it more (100 ms)?
> > 
> > What MDIO controller is this? The one from the FEC? If so, does your
> > kernel have this patch (and related)?
> > [...]
> 
> On mdio bus the only devices are the controller and the Marvell switch.
> Even increasing timeout to stupid values (>1000) I still get tx timestamp timeout sometimes...
> Simultaneously I get a "tx timestamp overrun" message from Marvell driver module, maybe I can try to track that message
> in driver code trying to figure out what's going on.
> 
> We are not using FEC as eth controller, we are using eqos (dw-mac/stmmac ip) instead. Do you know if there
> are some bugs or patches related to ptp applications with this controller too?

The stmmac driver is in a pretty sorry state, and things won't probably
work well until inspected with a fine comb, and then an eye kept on it.
I don't have any magic tricks for it. Maybe check the value of the "clk_csr"
device tree property, which controls the MDIO frequency (MAC_MDIO_Address
register, field CR - CSR Clock Range). There are some more interesting
bits that this device has in its MAC_MDIO_Address register, like PSE
(Preamble Suppression Enable), BTB (Back to Back transactions), NTC
(Number of Trailing Clocks) which could potentially improve the MDIO
throughput considerably.

I'm talking about this sort of optimizations that are being applied to
other MDIO controller drivers for transactions to take place quicker:
https://patchwork.kernel.org/project/netdevbpf/cover/202...@wa.../

But, as they say, some elbow grease will be required.

Re: [Linuxptp-users] DSA bridge PTP issues

[Riccardo L. <la...@le...>]

Il 28/03/23 17:50, Vladimir Oltean ha scritto:
> ah, ok, I didn't notice it :)
>
> so with PTP over IP, you'll also need these kernel config options and
> commands for the software bridge to leave PTP traffic on the bridge
> ports (so ptp4l can process it), and not "steal" it.
>
> CONFIG_BRIDGE_NF_EBTABLES=y
> CONFIG_BRIDGE_EBT_BROUTE=y
> CONFIG_BRIDGE_EBT_T_FILTER=y
> CONFIG_BRIDGE_EBT_IP=y
> CONFIG_BRIDGE_EBT_IP6=y
>
> /sbin/ebtables --table broute --append BROUTING --protocol 0x88F7 --jump DROP
>
> /sbin/ebtables --table broute --append BROUTING --protocol 0x0800 --ip-protocol udp --ip-destination-port 320 --jump DROP
> /sbin/ebtables --table broute --append BROUTING --protocol 0x0800 --ip-protocol udp --ip-destination-port 319 --jump DROP
>
> /sbin/ebtables --table broute --append BROUTING --protocol 0x86DD --ip6-protocol udp --ip6-destination-port 320 --jump DROP
> /sbin/ebtables --table broute --append BROUTING --protocol 0x86DD --ip6-protocol udp --ip6-destination-port 319 --jump DROP

Those kernel options were unselected. I've recompiled the kernel. Still not working.

ebtables dump:
	root@imx8mp-leaff-evk:~# ebtables --table broute --list
	Bridge table: broute
	
	Bridge chain: BROUTING, entries: 5, policy: ACCEPT
	-p PTP -j DROP
	-p IPv4 --ip-proto udp --ip-dport 320 -j DROP
	-p IPv4 --ip-proto udp --ip-dport 319 -j DROP
	-p IPv6 --ip6-proto udp --ip6-dport 320 -j DROP
	-p IPv6 --ip6-proto udp --ip6-dport 319 -j DROP

Now my ptp network is made up of two nodes:
A = reference board (standard lan hardware configuration, no dsa)
B = our development board (Marvell DSA)

On A I'm running ptp4l on IPv4 transport and highest priority (so, always grand master).

On B, ptp4l with standard priority don't see any master on the network and promotes itself as gm.
On A I see there is a new master, but A remains gm due to higher priority.

A log:
	root@imx8mp-var-dart:~# ptp4l -i eth0 --tx_timestamp_timeout=40 -m -4 --priority1=0 -P
	ptp4l[4320.662]: selected /dev/ptp1 as PTP clock
	ptp4l[4320.664]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
	ptp4l[4320.664]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
	ptp4l[4327.580]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
	ptp4l[4327.580]: selected local clock f8dc7a.fffe.739f22 as best master
	ptp4l[4327.581]: port 1: assuming the grand master role
	ptp4l[4365.680]: port 1: new foreign master de5c00.fffe.941eb2-1
	ptp4l[4369.682]: selected best master clock de5c00.fffe.941eb2
	ptp4l[4369.682]: port 1: assuming the grand master role

B log: (here you see i passed two lan ports to force boundary clock mode, don't know if this is relevant. Anyway, there was ptp traffic on lan2 only)
	root@imx8mp-leaff-evk:~# ptp4l -H -mq --tx_timestamp_timeout=40 -i lan2 -i lan3 -4 -P
	ptp4l[245.645]: selected /dev/ptp0 as PTP clock
	ptp4l[245.648]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
	ptp4l[245.650]: port 2: INITIALIZING to LISTENING on INIT_COMPLETE
	ptp4l[245.650]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
	ptp4l[252.318]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
	ptp4l[252.318]: selected local clock de5c00.fffe.941eb2 as best master
	ptp4l[252.318]: port 1: assuming the grand master role
	ptp4l[252.954]: port 2: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
	ptp4l[252.954]: selected local clock de5c00.fffe.941eb2 as best master
	ptp4l[252.954]: port 1: assuming the grand master role
	ptp4l[252.954]: port 2: assuming the grand master role

It looks like outgoing ptp packets get routed fine while incoming ones get ignored/filtered/sucked-into-void
Is there any downsides using -2 instead the default IPv4 transport?

By the way sometimes I had some "port [n]: received SYNC without timestamp" messages when using -2 that went away
when I added the broute on EtherType 0x88F7.

> | ptp4l[2095.455]: master offset      17973 s2 freq +1000000 path delay       369
>
> This "freq +1000000" is odd. Who plays the role of the PTP master?
> Its clock is running way too fast, the switch can't keep up with it.
> If it's linuxptp-based, you can reset its frequency with
> "phc_ctl /dev/ptp0 freq 0" and that should get things back to normal
> (unless the PHC of the master is under the control of another process
> which is persistently causing this).

Master was the reference board that was a slave in previous experiments.
A power cycle fixed the issue, probably was the clock speed, as you said.

> | ptp4l[1857.988]: timed out while polling for tx timestamp
> | ptp4l[1857.988]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
>
> Here, there may simply be too much MDIO traffic, and 40 ms is not enough
> to collect timestamps. Can you try increasing it more (100 ms)?
>
> What MDIO controller is this? The one from the FEC? If so, does your
> kernel have this patch (and related)?
> [...]

On mdio bus the only devices are the controller and the Marvell switch.
Even increasing timeout to stupid values (>1000) I still get tx timestamp timeout sometimes...
Simultaneously I get a "tx timestamp overrun" message from Marvell driver module, maybe I can try to track that message
in driver code trying to figure out what's going on.

We are not using FEC as eth controller, we are using eqos (dw-mac/stmmac ip) instead. Do you know if there
are some bugs or patches related to ptp applications with this controller too?

Thanks for your support,
RL

-- 
Riccardo Laiolo
Leaff Engineering - Digital Solutions & Algorithms

Re: [Linuxptp-users] negative delay issue

[Miroslav L. <mli...@re...>]

On Tue, Mar 28, 2023 at 10:24:47PM +0800, Merlin He wrote:
> hello team,
> 
> I found that port_nrate_calculate() save the first ingress1 before slave
> clock jumping, if the offset of master and slave is too large, this may
> results in an extremly small nrate_ratio value, and cause the nagative
> delay issue.
> so, is this a problem please?

There might be an assumption that the clock if running free. I'm not
very familiar with this feature.

> what about port_nrate_calculate() sampling the first ingress1 until servo
> entering lock state?
> like this:
> 1028   if (tmv_is_zero(n->ingress1) && *clock_servo_state(p->clock) ==
> SERVO_LOCKED*) {
> 1029     n->ingress1 = ingress;
> 1030     n->origin1 = origin;
> 1031     return;
> 1032   }

Another option might be calling port_nrate_initialize() on clock jump.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] DSA bridge PTP issues

[Vladimir O. <ol...@gm...>]

On Tue, Mar 28, 2023 at 03:54:50PM +0200, Riccardo Laiolo wrote:
> Thanks for your reply,
> why are you saying there's no IP support? I thought ethtool was saying
> there is both L2 and L4 filtering capabilities.
> > Hardware Receive Filter Modes:
> > 	none
> > 	ptpv2-l4-event
> > 	ptpv2-l4-sync
> > 	ptpv2-l4-delay-req
> > 	ptpv2-l2-event
> > 	ptpv2-l2-sync
> > 	ptpv2-l2-delay-req
> > 	ptpv2-event
> > 	ptpv2-sync
> > 	ptpv2-delay-req

ah, ok, I didn't notice it :)

so with PTP over IP, you'll also need these kernel config options and
commands for the software bridge to leave PTP traffic on the bridge
ports (so ptp4l can process it), and not "steal" it.

CONFIG_BRIDGE_NF_EBTABLES=y
CONFIG_BRIDGE_EBT_BROUTE=y
CONFIG_BRIDGE_EBT_T_FILTER=y
CONFIG_BRIDGE_EBT_IP=y
CONFIG_BRIDGE_EBT_IP6=y

/sbin/ebtables --table broute --append BROUTING --protocol 0x88F7 --jump DROP

/sbin/ebtables --table broute --append BROUTING --protocol 0x0800 --ip-protocol udp --ip-destination-port 320 --jump DROP
/sbin/ebtables --table broute --append BROUTING --protocol 0x0800 --ip-protocol udp --ip-destination-port 319 --jump DROP

/sbin/ebtables --table broute --append BROUTING --protocol 0x86DD --ip6-protocol udp --ip6-destination-port 320 --jump DROP
/sbin/ebtables --table broute --append BROUTING --protocol 0x86DD --ip6-protocol udp --ip6-destination-port 319 --jump DROP

> > PTP hardware timestamping does not work on a bridge interface, for the
> > same basic reason that a bridge forwards packets to potentially multiple
> > ports, and it is not immediately clear, when an application sees a
> > timestamp coming from a bridge interface, which bridge port took that
> > timestamp (they may have different PHCs).
> > 
> > This only leaves you a single option:
> > 
> > ptp4l -i lan1 -i lan2 -i lan3 [ ... ] -2 -P -m --tx_timestamp_timeout 40
> 
> Finally, I tried to launch ptp4l on my board as master (on all of the front-facing port)
> with -2 and it's working as expected, since all the (slave-only) devices are synchronising to it.
> 
> On the other hand if I configure my board as a slave-only device (-s flag) it's not working.
> I've attached two logs, in the first one i launched ptp4l with -i on all ports,
> but it's noisy and unreadable!
> Anyway, the master was on port3 and on port5 was a second slave.
> In the second one i passed -i lan3 (the port connected directly to the ptp master device)

| ptp4l[2095.455]: master offset      17973 s2 freq +1000000 path delay       369

This "freq +1000000" is odd. Who plays the role of the PTP master?
Its clock is running way too fast, the switch can't keep up with it.
If it's linuxptp-based, you can reset its frequency with
"phc_ctl /dev/ptp0 freq 0" and that should get things back to normal
(unless the PHC of the master is under the control of another process
which is persistently causing this).

| ptp4l[1857.988]: timed out while polling for tx timestamp
| ptp4l[1857.988]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug

Here, there may simply be too much MDIO traffic, and 40 ms is not enough
to collect timestamps. Can you try increasing it more (100 ms)?

What MDIO controller is this? The one from the FEC? If so, does your
kernel have this patch (and related)?

commit f166f890c8f026a931e1bb80f51561a1d2f41b27
Author: Andrew Lunn <an...@lu...>
Date:   Sat May 2 17:25:04 2020 +0200

    net: ethernet: fec: Replace interrupt driven MDIO with polled IO

    Measurements of the MDIO bus have shown that driving the MDIO bus
    using interrupts is slow. Back to back MDIO transactions take about
    90us, with 25us spent performing the transaction, and the remainder of
    the time the bus is idle.

    Replacing the completion interrupt with polled IO results in back to
    back transactions of 40us. The polling loop waiting for the hardware
    to complete the transaction takes around 28us. Which suggests
    interrupt handling has an overhead of 50us, and polled IO nearly
    halves this overhead, and doubles the MDIO performance.

    Care has to be taken when setting the MII_SPEED register, or it can
    trigger an MII event> That then upsets the polling, due to an
    unexpected pending event.

    Suggested-by: Chris Heally <cp...@gm...>
    Signed-off-by: Andrew Lunn <an...@lu...>
    Signed-off-by: David S. Miller <da...@da...>

[Linuxptp-users] negative delay issue

[Merlin He <mer...@gm...>]

hello team,

I found that port_nrate_calculate() save the first ingress1 before slave
clock jumping, if the offset of master and slave is too large, this may
results in an extremly small nrate_ratio value, and cause the nagative
delay issue.
so, is this a problem please?
what about port_nrate_calculate() sampling the first ingress1 until servo
entering lock state?
like this:
1028   if (tmv_is_zero(n->ingress1) && *clock_servo_state(p->clock) ==
SERVO_LOCKED*) {
1029     n->ingress1 = ingress;
1030     n->origin1 = origin;
1031     return;
1032   }

 734 ptp4l[61.809]: negative delay   -2267723
 735 ptp4l[61.809]: delay = (t2 - t3) * rr + (t4 - t1)
 736 ptp4l[61.809]: t2 - t3 =         +0
 737 ptp4l[61.809]: t4 - t1 =   -4535446
* 738 ptp4l[61.809]: rr = 0.000000003*

*Thanks*
*Merlin*

Re: [Linuxptp-users] DSA bridge PTP issues

[Riccardo L. <la...@le...>]

Il 28/03/23 12:14, Vladimir Oltean ha scritto:
> On Tue, Mar 28, 2023 at 11:29:02AM +0200, Riccardo Laiolo wrote:
>> Hi there,
>> I'm working on a custom NXP iMX8 SoM connected to a Marvell MV88E6390 switch on port0 (eth0 as management port).
>> Five switch ports are exposed to the outside and bridged together in a dsa device (br0 soft bridge).
>> I'm running iMX linux-5.15.71 from NXP downstream repository.
>>
>> I need my device to be a ptp device (master or slave depending on the specific application).
>>
>> Since I can ping other PCs on the network I think Marvell DSA drivers are working, but ptp is not working.
>>
>> I found and backported this patch (https://github.com/torvalds/linux/commit/9627c981ac82209c66c1b6c0e15c6cceb8656f01)
>> into my codebase, but when I launch ptp4l it's not working properly. Launching ptp4l on eth0 it says eth0 is
>> rejecting HWTSTAMP filtering configuration. Launching ptp4l on an outside facing port (lan1:5), instead, using IPv4
>> or IPv6 transport, it's like my SoM can't talk to other ptp devices: if my SoM is a ptp master i see announce, sync,
>> and follow-up messages get sent, and I see dly_req from other slaves coming back, but there are no dly_resp at all.
>> When my som is slave there are no packets from it. It's like all ptp related packets get ignored.
>>
>> Is it possible to run ptp on eth0 (or on br0)? I want to syncronize devices on all the front facing ports.
>>
>> I've attached `ip a` output, `ethtool -T eth0` output, and `ethtool -T lan1` output.
> "ethtool -T lan1" reports that the switch ports only support L2 PTP, so
> no IPv4 and no IPv6.

Thanks for your reply,
why are you saying there's no IP support? I thought ethtool was saying there is both L2 and L4 filtering capabilities.
>Hardware Receive Filter Modes:
>	none
>	ptpv2-l4-event
>	ptpv2-l4-sync
>	ptpv2-l4-delay-req
>	ptpv2-l2-event
>	ptpv2-l2-sync
>	ptpv2-l2-delay-req
>	ptpv2-event
>	ptpv2-sync
>	ptpv2-delay-req

>
> PTP hardware timestamping on eth0 (the DSA master) is rejected if the
> switch supports hardware timestamping too, because the kernel does not
> support reporting more than 1 TX timestamp per packet (or rather, it
> does report multiple timestamps, but it doesn't tell user space where
> they came from). Since a choice needs to be made even with the
> limitations in place, that current choice is to only allow PTP hardware
> timestamping on the DSA switch ports, if those support this operation,
> or on the DSA master if the switch doesn't support hardware timestamping.

Ok, that seems reasonable. Thanks for the insight.

> PTP hardware timestamping does not work on a bridge interface, for the
> same basic reason that a bridge forwards packets to potentially multiple
> ports, and it is not immediately clear, when an application sees a
> timestamp coming from a bridge interface, which bridge port took that
> timestamp (they may have different PHCs).
>
> This only leaves you a single option:
>
> ptp4l -i lan1 -i lan2 -i lan3 [ ... ] -2 -P -m --tx_timestamp_timeout 40

Finally, I tried to launch ptp4l on my board as master (on all of the front-facing port)
with -2 and it's working as expected, since all the (slave-only) devices are synchronising to it.

On the other hand if I configure my board as a slave-only device (-s flag) it's not working.
I've attached two logs, in the first one i launched ptp4l with -i on all ports,
but it's noisy and unreadable!
Anyway, the master was on port3 and on port5 was a second slave.
In the second one i passed -i lan3 (the port connected directly to the ptp master device)

Thanks for the help,
RL

-- 
Riccardo Laiolo
Leaff Engineering - Digital Solutions & Algorithms

Re: [Linuxptp-users] DSA bridge PTP issues

[Vladimir O. <ol...@gm...>]

On Tue, Mar 28, 2023 at 11:29:02AM +0200, Riccardo Laiolo wrote:
> Hi there,
> I'm working on a custom NXP iMX8 SoM connected to a Marvell MV88E6390 switch on port0 (eth0 as management port).
> Five switch ports are exposed to the outside and bridged together in a dsa device (br0 soft bridge).
> I'm running iMX linux-5.15.71 from NXP downstream repository.
> 
> I need my device to be a ptp device (master or slave depending on the specific application).
> 
> Since I can ping other PCs on the network I think Marvell DSA drivers are working, but ptp is not working.
> 
> I found and backported this patch (https://github.com/torvalds/linux/commit/9627c981ac82209c66c1b6c0e15c6cceb8656f01)
> into my codebase, but when I launch ptp4l it's not working properly. Launching ptp4l on eth0 it says eth0 is
> rejecting HWTSTAMP filtering configuration. Launching ptp4l on an outside facing port (lan1:5), instead, using IPv4
> or IPv6 transport, it's like my SoM can't talk to other ptp devices: if my SoM is a ptp master i see announce, sync,
> and follow-up messages get sent, and I see dly_req from other slaves coming back, but there are no dly_resp at all.
> When my som is slave there are no packets from it. It's like all ptp related packets get ignored.
> 
> Is it possible to run ptp on eth0 (or on br0)? I want to syncronize devices on all the front facing ports.
> 
> I've attached `ip a` output, `ethtool -T eth0` output, and `ethtool -T lan1` output.

"ethtool -T lan1" reports that the switch ports only support L2 PTP, so
no IPv4 and no IPv6.

PTP hardware timestamping on eth0 (the DSA master) is rejected if the
switch supports hardware timestamping too, because the kernel does not
support reporting more than 1 TX timestamp per packet (or rather, it
does report multiple timestamps, but it doesn't tell user space where
they came from). Since a choice needs to be made even with the
limitations in place, that current choice is to only allow PTP hardware
timestamping on the DSA switch ports, if those support this operation,
or on the DSA master if the switch doesn't support hardware timestamping.

PTP hardware timestamping does not work on a bridge interface, for the
same basic reason that a bridge forwards packets to potentially multiple
ports, and it is not immediately clear, when an application sees a
timestamp coming from a bridge interface, which bridge port took that
timestamp (they may have different PHCs).

This only leaves you a single option:

ptp4l -i lan1 -i lan2 -i lan3 [ ... ] -2 -P -m --tx_timestamp_timeout 40

[Linuxptp-users] DSA bridge PTP issues

[Riccardo L. <la...@le...>]

Hi there,
I'm working on a custom NXP iMX8 SoM connected to a Marvell MV88E6390 switch on port0 (eth0 as management port).
Five switch ports are exposed to the outside and bridged together in a dsa device (br0 soft bridge).
I'm running iMX linux-5.15.71 from NXP downstream repository.

I need my device to be a ptp device (master or slave depending on the specific application).

Since I can ping other PCs on the network I think Marvell DSA drivers are working, but ptp is not working.

I found and backported this patch (https://github.com/torvalds/linux/commit/9627c981ac82209c66c1b6c0e15c6cceb8656f01)
into my codebase, but when I launch ptp4l it's not working properly. Launching ptp4l on eth0 it says eth0 is
rejecting HWTSTAMP filtering configuration. Launching ptp4l on an outside facing port (lan1:5), instead, using IPv4
or IPv6 transport, it's like my SoM can't talk to other ptp devices: if my SoM is a ptp master i see announce, sync,
and follow-up messages get sent, and I see dly_req from other slaves coming back, but there are no dly_resp at all.
When my som is slave there are no packets from it. It's like all ptp related packets get ignored.

Is it possible to run ptp on eth0 (or on br0)? I want to syncronize devices on all the front facing ports.

I've attached `ip a` output, `ethtool -T eth0` output, and `ethtool -T lan1` output.

Best Regards,
_RL_

-- 
Riccardo Laiolo
Leaff Engineering - Digital Solutions & Algorithms

Re: [Linuxptp-users] Offset details

[Merlin He <mer...@gm...>]

hi ravi,
I think there is no such api, you can only get ptp status through
management messages

ravi dandamudi <rkd...@gm...> 于2023年3月28日周二 15:34写道：

> Hi All,
>
> Just wanted to know, Is there any other way to get offset value without
> using PMC command.
>
> Any APIs are available?
>
> Thanks
> Ravi
>
> On Tue, 28 Mar, 2023, 12:38 pm Vladimir Oltean, <ol...@gm...> wrote:
>
>> On Tue, Mar 28, 2023 at 01:42:05PM +0800, Merlin He wrote:
>> > Richard Cochran <ric...@gm...> 于2023年3月28日周二 11:27写道：
>> > > On Tue, Mar 28, 2023 at 10:57:43AM +0800, merlinhe wrote:
>> > > > Hi Miroslav,
>> > > >
>> > > > We use Synopsys's IP, the driver is the same as stmmac
>> > >
>> > > Yeah, the stmmac driver is crazy bad.
>> > >
>> > > It is not clear to me whether setting the time when enabling time
>> > > stamping is actually required by the IP core or not.
>> > >
>> > > But even if it were required, still the driver should attempt to keep
>> > > the MAC unaltered by reprogramming the current MAC time.
>> > >
>> >
>> > Hi Richard,
>> > Thank you, We are going to report this issue to Synopsys
>>
>> Problem already solved, please use a kernel which tracks linux-stable.
>>
>> https://github.com/torvalds/linux/commit/a6da2bbb0005e6b4909472962c9d0af29e75dd06
>>
>>
>> _______________________________________________
>> Linuxptp-users mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>>
>

Re: [Linuxptp-users] rogue peer delay response caused by port_synchronize()

[Merlin He <mer...@gm...>]

Hi Vladimir,
Great help, thank you very much,
We will consider upgrading the kernel.


Vladimir Oltean <ol...@gm...> 于2023年3月28日周二 15:04写道：

> On Tue, Mar 28, 2023 at 01:42:05PM +0800, Merlin He wrote:
> > Richard Cochran <ric...@gm...> 于2023年3月28日周二 11:27写道：
> > > On Tue, Mar 28, 2023 at 10:57:43AM +0800, merlinhe wrote:
> > > > Hi Miroslav,
> > > >
> > > > We use Synopsys's IP, the driver is the same as stmmac
> > >
> > > Yeah, the stmmac driver is crazy bad.
> > >
> > > It is not clear to me whether setting the time when enabling time
> > > stamping is actually required by the IP core or not.
> > >
> > > But even if it were required, still the driver should attempt to keep
> > > the MAC unaltered by reprogramming the current MAC time.
> > >
> >
> > Hi Richard,
> > Thank you, We are going to report this issue to Synopsys
>
> Problem already solved, please use a kernel which tracks linux-stable.
>
> https://github.com/torvalds/linux/commit/a6da2bbb0005e6b4909472962c9d0af29e75dd06
>

[Linuxptp-users] Offset details

[ravi d. <rkd...@gm...>]

Hi All,

Just wanted to know, Is there any other way to get offset value without
using PMC command.

Any APIs are available?

Thanks
Ravi

On Tue, 28 Mar, 2023, 12:38 pm Vladimir Oltean, <ol...@gm...> wrote:

> On Tue, Mar 28, 2023 at 01:42:05PM +0800, Merlin He wrote:
> > Richard Cochran <ric...@gm...> 于2023年3月28日周二 11:27写道：
> > > On Tue, Mar 28, 2023 at 10:57:43AM +0800, merlinhe wrote:
> > > > Hi Miroslav,
> > > >
> > > > We use Synopsys's IP, the driver is the same as stmmac
> > >
> > > Yeah, the stmmac driver is crazy bad.
> > >
> > > It is not clear to me whether setting the time when enabling time
> > > stamping is actually required by the IP core or not.
> > >
> > > But even if it were required, still the driver should attempt to keep
> > > the MAC unaltered by reprogramming the current MAC time.
> > >
> >
> > Hi Richard,
> > Thank you, We are going to report this issue to Synopsys
>
> Problem already solved, please use a kernel which tracks linux-stable.
>
> https://github.com/torvalds/linux/commit/a6da2bbb0005e6b4909472962c9d0af29e75dd06
>
>
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>

Re: [Linuxptp-users] rogue peer delay response caused by port_synchronize()

[Vladimir O. <ol...@gm...>]

On Tue, Mar 28, 2023 at 01:42:05PM +0800, Merlin He wrote:
> Richard Cochran <ric...@gm...> 于2023年3月28日周二 11:27写道：
> > On Tue, Mar 28, 2023 at 10:57:43AM +0800, merlinhe wrote:
> > > Hi Miroslav,
> > >
> > > We use Synopsys's IP, the driver is the same as stmmac
> >
> > Yeah, the stmmac driver is crazy bad.
> >
> > It is not clear to me whether setting the time when enabling time
> > stamping is actually required by the IP core or not.
> >
> > But even if it were required, still the driver should attempt to keep
> > the MAC unaltered by reprogramming the current MAC time.
> >
> 
> Hi Richard,
> Thank you, We are going to report this issue to Synopsys

Problem already solved, please use a kernel which tracks linux-stable.
https://github.com/torvalds/linux/commit/a6da2bbb0005e6b4909472962c9d0af29e75dd06

Re: [Linuxptp-users] rogue peer delay response caused by port_synchronize()

[Merlin He <mer...@gm...>]

Hi Richard,
Thank you, We are going to report this issue to Synopsys

Richard Cochran <ric...@gm...> 于2023年3月28日周二 11:27写道：

> On Tue, Mar 28, 2023 at 10:57:43AM +0800, merlinhe wrote:
> > Hi Miroslav,
> >
> > We use Synopsys's IP, the driver is the same as stmmac
>
> Yeah, the stmmac driver is crazy bad.
>
> It is not clear to me whether setting the time when enabling time
> stamping is actually required by the IP core or not.
>
> But even if it were required, still the driver should attempt to keep
> the MAC unaltered by reprogramming the current MAC time.
>
> Thanks,
> Richard
>

Re: [Linuxptp-users] rogue peer delay response caused by port_synchronize()

[Richard C. <ric...@gm...>]

On Tue, Mar 28, 2023 at 10:57:43AM +0800, merlinhe wrote:
> Hi Miroslav,
> 
> We use Synopsys's IP, the driver is the same as stmmac

Yeah, the stmmac driver is crazy bad.

It is not clear to me whether setting the time when enabling time
stamping is actually required by the IP core or not.

But even if it were required, still the driver should attempt to keep
the MAC unaltered by reprogramming the current MAC time.

Thanks,
Richard