lkml.org 
[lkml]   [2020]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
SubjectRe: [RFC PATCH net-next 7/9] net: dsa: microchip: ksz9477: add hardware time stamping support
Date
On Sunday, 1 November 2020, 12:10:08 CET, Vladimir Oltean wrote:
> On Sun, Nov 01, 2020 at 10:35:01AM +0100, Christian Eggers wrote:
> > Hi Vladimir,
> >
> > On Friday, 30 October 2020, 19:24:47 CET, Vladimir Oltean wrote:
> > > On Thu, Oct 22, 2020 at 12:17:48PM +0200, Christian Eggers wrote:
> > > > I tried to study the effect of setting the ocmode bit on the KSZ
> > > > either to
> > > > master or to slave. The main visible change is, that some PTP message
> > > > types
> > > > are be filtered out on RX:
> > > > - in "master" mode, "Sync" messages from other nodes will not be
> > > > received
> > > > (but everything else like "Announce" seem to work)
> > > > - in "slave" mode, "Delay_Req" messages from other nodes will not be
> > > > received
> > >
> > > Could you dump the contents of your REG_PTP_MSG_CONF2 register?
> >
> > runtime register value is 0x1004 (matches default value from the data
> > sheet). The Linux driver doesn't touch this register. Below is a dump of
> > all PTP related (global) registers.
>
> So the bit 5 ("Enable Dropping of Sync/Follow_Up and Delay_Req PTP
> Messages") is not set. When the PTP messages are dropped, do you know
> which error counter in ethtool -S is increasing?
I am not sure whether I understand the question. My assumption is that the
KSZ9563 simply doesn't forward specific PTP packages from the slave ports to
the CPU port. In my imagination this happens in hardware and is not visible in
software.

I have run "ethtool -S" two times on the PTP master clock (E2E mode):
- When "ocmode" is set to master (DelayReq messages can be received)
- When "ocmode" is set to slave (DelayReq messages cannot be received)

Here is the diff output:
--- /home/root/ethtool1
+++ /home/root/ethtool2
@@ -1,8 +1,8 @@
NIC statistics:
- tx_packets: 1421
- tx_bytes: 133641
- rx_packets: 488
- rx_bytes: 35904
+ tx_packets: 1455
+ tx_bytes: 136783
+ rx_packets: 496
+ rx_bytes: 36459
rx_hi: 0
rx_undersize: 0
rx_fragments: 0
@@ -14,10 +14,10 @@
rx_mac_ctrl: 0
rx_pause: 0
rx_bcast: 4
- rx_mcast: 667
+ rx_mcast: 683
rx_ucast: 0
rx_64_or_less: 0
- rx_65_127: 659
+ rx_65_127: 675
rx_128_255: 11
rx_256_511: 1
rx_512_1023: 0
@@ -27,15 +27,15 @@
tx_hi: 0
tx_late_col: 0
tx_pause: 0
- tx_bcast: 713
- tx_mcast: 1852
- tx_ucast: 324
+ tx_bcast: 733
+ tx_mcast: 1897
+ tx_ucast: 333
tx_deferred: 0
tx_total_col: 0
tx_exc_col: 0
tx_single_col: 0
tx_mult_col: 0
- rx_total: 61158
- tx_total: 307225
+ rx_total: 62577
+ tx_total: 313773
rx_discards: 20
tx_discards: 0
regards
Christian



\
 
 \ /
  Last update: 2020-11-01 23:16    [W:0.229 / U:1.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site