[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1416769497.7215.56.camel@decadent.org.uk>
Date: Sun, 23 Nov 2014 19:04:57 +0000
From: Ben Hutchings <ben@...adent.org.uk>
To: David Miller <davem@...emloft.net>
Cc: richardcochran@...il.com, netdev@...r.kernel.org,
stefan.sorensen@...ctralink.com
Subject: Re: [PATCH net-next] vlan: Pass ethtool get_ts_info queries to real
device.
On Sun, 2014-11-23 at 13:48 -0500, David Miller wrote:
> From: Richard Cochran <richardcochran@...il.com>
> Date: Sun, 23 Nov 2014 17:05:35 +0100
>
> > On Sun, Nov 23, 2014 at 03:15:12AM +0000, Ben Hutchings wrote:
> >> This assumes that the same PTP capabilities apply to VLAN-tagged frames.
> >> I don't think it's at all safe to assume that RX filter modes other than
> >> HWTSTAMP_FILTER_ALL will include VLAN-tagged frames. I think it is
> >> necessary to define additional modes that explicitly include VLAN-tagged
> >> frames.
> >
> > Unsafe? How?
> >
> > Do you mean that some HW cannot identify and time stamp PTP frames
> > when VLAN tagged? That is surely disappointing for people who shell
> > out money for such cards, but it is hardly unsafe.
>
> Ben, you will have to provide a concrete example of a chip that will
> do the wrong thing with Richard's change.
>
> Hypotheticals won't cut it.
The two datasheets I've looked at so far (EG20T for pch_gbe driver,
BF518 for bfin_mac driver) mention support for 802.1q but not 802.1ad.
I already mentioned ptp_classify.c doesn't support 802.1ad, and I can't
see how it would ever make sense to run PTP directly over 802.1ad
anyway.
I'll read some more datasheets to see whether 802.1q is generally
supported, but for 802.1ad VLAN devices I think we should pass-through
only the NONE and ALL filter capabilities.
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)
Powered by blists - more mailing lists