[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190814134225.GB5265@lunn.ch>
Date: Wed, 14 Aug 2019 15:42:25 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Y.b. Lu" <yangbo.lu@....com>
Cc: "Allan W. Nielsen" <allan.nielsen@...rochip.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"David S . Miller" <davem@...emloft.net>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>
Subject: Re: [PATCH 3/3] ocelot_ace: fix action of trap
> [Y.b. Lu] PTP messages over Ethernet will use two multicast addresses.
> 01-80-C2-00-00-0E for peer delay messages.
> 01-1B-19-00-00-00 for other messages.
>
> But only 01-80-C2-00-00-0E could be handled by hardware filter for BPDU frames (01-80-C2-00-00-0x).
> For PTP messages handling, trapping them to CPU through VCAP IS2 is the suggested way by Ocelot/Felix.
>
> I have a question since you are experts.
There real expert is Richard Cochran <richardcochran@...il.com>. He
implemented PTP support for the mv88e6xxx devices, maintains to core
code, and the linuxptp daemon. Any ptp support your post will be
reviewed by him.
> For other switches, whether they are always trapping PTP messages to CPU?
For the mv88e6xxx family, there is a per port bit which enabled
PTP. When enabled, PTP frames are recognised by the hardware and
forwarded to the CPU.
> Is there any common method in linux to configure switch to select
> trapping or just forwarding PTP messages?
The best answer to that is to look at other switch driver which
implement ptp. The ptp core expects a ptp_clock_info structure, and
one of its members is 'enable'.
Andrew
Powered by blists - more mailing lists