[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250629112830.79975f4a@wsk>
Date: Sun, 29 Jun 2025 11:28:30 +0200
From: Lukasz Majewski <lukma@...x.de>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>, Richard Cochran
<richardcochran@...il.com>, Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
netdev@...r.kernel.org, Arun Ramadoss <arun.ramadoss@...rochip.com>,
Tristram.Ha@...rochip.com, Christian Eggers <ceggers@...i.de>
Subject: Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477
device
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).
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