lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250616172501.00ea80c4@wsk>
Date: Mon, 16 Jun 2025 17:25:01 +0200
From: Lukasz Majewski <lukma@...x.de>
To: netdev@...r.kernel.org
Cc: Arun Ramadoss <arun.ramadoss@...rochip.com>, Vladimir Oltean
 <olteanv@...il.com>, Oleksij Rempel  <o.rempel@...gutronix.de>,
 Tristram.Ha@...rochip.com, Richard Cochran <richardcochran@...il.com>,
 Christian Eggers <ceggers@...i.de>
Subject: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477
 device

Dear Community,

As of [1] KSZ drivers support HW timestamping HWTSTAMP_TX_ONESTEP_P2P.
When used with ptp4l (config [2]) I'm able to see that two boards with
KSZ9477 can communicate and one of them is a grandmaster device.

This is OK (/dev/ptp0 is created and works properly).

From what I have understood - the device which supports p2p1step also
supports "older" approaches, so communication with other HW shall be
possible.

Hence the questions:

1. Would it be possible to communicate with beaglebone black (BBB)
connected to the same network?

root@...gleBone:~# ethtool -T eth0
Hardware Transmit Timestamp Modes:
        off
        on
Hardware Receive Filter Modes:
        none
        ptpv2-event

My board:
# ethtool -T lan3
Hardware Transmit Timestamp Modes:
        off
        onestep-p2p
Hardware Receive Filter Modes:
        none
        ptpv2-l4-event
        ptpv2-l2-event
        ptpv2-event

(other fields are the same)

As I've stated above - onestep-p2p shall also support the "on" mode
from BBB.

The documentation of KSZ9477 states that:
- IEEE 1588v2 PTP and Clock Synchronization
- Transparent Clock (TC) with auto correction update
- Master and slave Ordinary Clock (OC) support
- End-to-end (E2E) or peer-to-peer (P2P)
- PTP multicast and unicast message support
- PTP message transport over IPv4/v6 and IEEE 802.3
- IEEE 1588v2 PTP packet filtering
- Synchronous Ethernet support via recovered clock

which looks like all PTP use cases (and other boards) for HW shall be
supported.

Is this a matter of not (yet) available in-driver support or do I need
to configure linuxptp in different way to have such support?



2. The master clock synchronization and calibration

On one board (grandmaster) (connected to lan3):
[1943.558]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
[1951.091]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
[1951.091]: selected local clock 824f12.fffe.110022 as best master
[1951.091]: port 1: assuming the grand master role

The other board:
[890.003]: port 1 (lan3): new foreign master 824f12.fffe.110022-1
[894.003]: selected best master clock 824f12.fffe.110022
[894.005]: port 1 (lan3): LISTENING to UNCALIBRATED on RS_SLAVE

The phc2sys -m -s lan3 shows some calibration...

CLOCK_REALTIME phc offset        65 s2 freq  -45509 delay 351557
CLOCK_REALTIME phc offset       591 s2 freq  -44964 delay 350475
CLOCK_REALTIME phc offset      -892 s2 freq  -46270 delay 350516
CLOCK_REALTIME phc offset    137456 s2 freq  +91811 delay 733784
CLOCK_REALTIME phc offset   -136987 s2 freq -141395 delay 350676
CLOCK_REALTIME phc offset    -41327 s2 freq  -86831 delay 350216
CLOCK_REALTIME phc offset        66 s2 freq  -57837 delay 350489
CLOCK_REALTIME phc offset     12037 s2 freq  -45846 delay 351854
CLOCK_REALTIME phc offset     12213 s2 freq  -42059 delay 350474
CLOCK_REALTIME phc offset      8984 s2 freq  -41624 delay 349682


but the "fluctuation" is too large to regard it as a "stable" and
precise source.

And probably hence it is "UNCALIBRATED" master clock.

Even more strange - the tshark -i lan3 -Y "ptp" -V

.... 1011 = messageId: Announce Message (0xb)
correction: 0.000000 nanoseconds                     
    correction: Ns: 0 nanoseconds                   
    correctionSubNs: 0 nanoseconds             

.... 0010 = messageId: Peer_Delay_Req Message (0x2)
    correction: 0.000000 nanoseconds
    correction: Ns: 0 nanoseconds
    correctionSubNs: 0 nanoseconds

shows always the correction value of 0 ns.
I do guess that it shall have some (different) values.

Any hints on fixing this problem?


3. Just to mention - I've found rather old conversation regarding PTP
support [3] on KSZ devices (but for KSZ9563)

And it looks like it has already been adopted to minline Linux. 
Am I correct? Or is anything still missing (and hence I do see the two
described above issues)?

Thanks in advance for your help :-)

Links:

[1] -
https://elixir.bootlin.com/linux/v6.16-rc1/source/drivers/net/dsa/microchip/ksz_ptp.c#L293

[2] - config for PTP (/etc/ptp4l.conf):

cat /etc/ptp4l.conf     
[global]

#twoStepFlag 0   ->  set automatically in ptp4l
time_stamping p2p1step
slaveOnly 0/1
delay_mechanism P2P
delay_filter_length 100
tx_timestamp_timeout 100
network_transport L2

[3] -
https://patchwork.ozlabs.org/project/netdev/patch/20201019172435.4416-8-ceggers@arri.de/#2570624

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...x.de

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ