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

[Oleksij Rempel <o.rempel@pengutronix.de>]

On Sun, Jun 29, 2025 at 11:28:30AM +0200, Lukasz Majewski wrote:
> Hi Vladimir,
> 
> > On Thu, Jun 26, 2025 at 11:33:25PM +0200, Lukasz Majewski wrote:
> > > 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.  
> > 
> > Peer delay measurement is an independent process, not a response to
> > Sync messages.
> > 
> > > 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.  
> > 
> > Which frame is classified as PTP_CLASS_NONE? The peer delay request?
> > That doesn't sound convincing, can you place a call to skb_dump() and
> > show the contents of the PTP packets that don't pass this BPF filter?
> > Notably, the filter matches for event messages and doesn't match for
> > general messages, maybe that confused your debugging process in some
> > way.
> 
> It looks like PER_DELAY_REQ goes from one KSZ9477 device (with DA:
> 01:80:C2:00:00:0E) and then it is not visible (i.e. is dropped) in the
> tshark output on the other KSZ9477 device.
> 
> From what I've read on the Internet - those multicast frames are
> dropped by default by switches, but I'm using KSZ9477 ports in
> stand alone mode - i.e. bridge is not created).
> 
> On the other hand - the frames with DA: 01:16:19:00:00:00 (other
> multicast "set" of address) are delivered correctly (so the grandmaster
> clock is elected).
> 
> This is under further investigation.
> (setting KSZ9477 lan3s as promisc doesn't help).

Hm, if I remember it correctly, there was some HW filters:
https://patchwork.ozlabs.org/project/devicetree-bindings/cover/20201118203013.5077-1-ceggers@arri.de/#2589089
"
When master mode is on Delay_Resp will not be forwarded to the host
port.
When master mode is off Delay_Req will not be forwarded to the host
port.
"

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |