[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1391550719.3003.33.camel@deadeye.wl.decadent.org.uk>
Date: Tue, 04 Feb 2014 21:51:59 +0000
From: Ben Hutchings <ben@...adent.org.uk>
To: Sørensen, Stefan
<Stefan.Sorensen@...ctralink.com>
Cc: "davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"mugunthanvnm@...com" <mugunthanvnm@...com>
Subject: Re: [PATCH] net:cpsw: Pass unhandled ioctl's on to generic phy ioctl
On Tue, 2014-02-04 at 15:08 +0000, Sørensen, Stefan wrote:
> On Tue, 2014-02-04 at 10:50 +0000, Ben Hutchings wrote:
> > > This patch allows the use of a generic timestamping phy connected
> > > to the cpsw if CPTS support is not enabled.
> >
> > What if CPTS support is enabled in the driver, but this particular
> > machine doesn't have it and uses a timestamping PHY instead?
>
> That would not work, the CPTS will grab the SIOC{G,S}HWTSTAMP. I'm not
> sure how that could be configured at runtime, other than a private
> ethtool flag.
Do all versions of CPSW include hardware timestamping? Because the
condition at the top of cpsw_htstamp_ioctl() suggested to me that there
are some that don't.
> Also it seem as the situation with a timestamping MAC and a timestamping
> PHY could deliver bogus ethtool timestamping info, as it will come from
> the PHY if available, but the timestamping will be handled by the MAC.
[...]
Right. If all versions of CPSW include hardware timestamping then
bother with PHY timestamping at all? And why make CONFIG_TI_CPTS
configurable?
Ben.
--
Ben Hutchings
One of the nice things about standards is that there are so many of them.
Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)
Powered by blists - more mailing lists