[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1394455974.2296.22.camel@e37108.spectralink.com>
Date: Mon, 10 Mar 2014 12:52:57 +0000
From: Sørensen, Stefan
<Stefan.Sorensen@...ctralink.com>
To: "richardcochran@...il.com" <richardcochran@...il.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"bhutchings@...arflare.com" <bhutchings@...arflare.com>,
"christian.riesch@...cron.at" <christian.riesch@...cron.at>,
"davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH RFC net-next v1 0/9] ptp: dynamic pin control
On Sat, 2014-03-08 at 20:42 +0100, Richard Cochran wrote:
> This patch series introduces a way of changing the auxiliary PTP
> Hardware Clock functions (periodic output signals and time stamping
> external signals) at run time. In the past on the netdev list, we have
> discussed other ways to handle this, such as module parameters and
> ethtool. This series implements a new PHC ioctl because that is the
> most natural way. Users already activate the auxiliary functions via
> the ioctls. The sysfs interface has also been expanded so that the pin
> configuration can be programmed using shell scripts.
A few general questions / thoughts:
What are the n_ext_ts and n_per_out supposed to be set to now? The
number of pins configured for the relevant function or the number of
channels that are available for the function?
The implementation is limited to a single function for each pin - the
dp83640 supports an ext_ts and several periodic outputs on the same pin,
but I do not see that many real-world uses.
I have done a few short run-time tests, and so far everything is working
as expected.
Stefan
Powered by blists - more mailing lists