Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]

Hi Oleksij,

> On Tue, Jun 17, 2025 at 10:07:32PM -0700, Richard Cochran wrote:
> > On Tue, Jun 17, 2025 at 05:10:11PM +0100, Vadim Fedorenko wrote:  
> > > On 17/06/2025 06:25, Oleksij Rempel wrote:  
> > > > No, this will not work correctly. Both sides must use the same
> > > > timestamping mode: either both "one step" or both "two step".  
> > > 
> > > I'm not quite sure this statement is fully correct. I don't have a
> > > hardware on hands to make this setup, but reading through the
> > > code in linuxptp - the two-step fsm kicks off based on the
> > > message type bit. In case when linuxptp receives 1-step sync, it
> > > does all the calculations.  
> > 
> > Correct.
> >   
> > > For delay response packets on GM side it doesn't matter as GM
> > > doesn't do any calculations. I don't see any requirements here
> > > from the perspective of protocol itself.  
> > 
> > Running on a PTP client, ptp4l will happily use either one or two
> > step Sync messages from the server.  
> 
> Thank you for clarification! In this case, something else was wrong,
> and I made a wrong assumption. I had a non-working configuration, so
> I made the assumption without verifying the code.
> 

Ok, I do have one issue to fix - the BBB with "two step" timestamping
mode (with recent ptp4l) shall communicate with the KSZ9477 based PTP
setup, which uses the "one step" timestamping.

The second problem which I've found after some debugging:
- One device is selected as grandmaster clock. Another one tries to
  synchronize (for the simpler setup I've used two the same boards with
  identical kernel and KSZ9477 setup).

- tshark from host on which we do have grandmaster running:
  IEEEI&MS_00:00:00 PTPv2 58 Sync Message
  LLDP_Multicast PTPv2 68 Peer_Delay_Req Message
  IEEEI&MS_00:00:00 PTPv2 58 Sync Message
  LLDP_Multicast PTPv2 68 Peer_Delay_Req Message

So the SYNC is send, then the "slave" responds correctly with
Peer_Delay_Req_Message.

But then the "grandmaster" is NOT replying with PER_DELAY_RESPONSE.

After some digging into the code it turned out that
dsa_skb_defer_rx_timestamp() (from net/dsa/tag.c) calls
ptp_classify_raw(skb), which is a bpf program.

Instead of returning 0x42 I do receive "PTP_CLASS_NONE" and the frame is
dropped.

That is why grandmaster cannot send reply and finish the PTP clock
adjustment process.

The CONFIG_NET_PTP_CLASSIFY=y.

Any hints on how to proceed? If this would help - I'm using linux
kernel with PREEMPT_RT applied to it.

> Best Regards,
> Oleksij


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@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]