netdev - Re: [PATCH RFC net-next v1 0/9] ptp: dynamic pin control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 12 Mar 2014 09:21:00 +0100
From:	Christian Riesch <christian.riesch@...cron.at>
To:	Richard Cochran <richardcochran@...il.com>, netdev@...r.kernel.org
cc:	linux-kernel@...r.kernel.org,
	Ben Hutchings <bhutchings@...arflare.com>,
	David Miller <davem@...emloft.net>,
	Stefan Sørensen <stefan.sorensen@...ctralink.com>
Subject: Re: [PATCH RFC net-next v1 0/9] ptp: dynamic pin control

Hi Richard,

--On March 08, 2014 20:42 +0100 Richard Cochran <richardcochran@...il.com> 
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.

I did a few tests on one of my boards, everything works so far! Thanks for 
the patchset, I like it!

> The first patch adds the new ioctls. The PHC subsystem does most of
> the work of maintaining the function-to-pin mapping. Drivers will only
> need to allocate and initialize a pin configuration table and also
> provide a new method that validates a particular assignment.
>
> Patches 5 and 6 just clean up a couple of issues in the phyter driver,
> and the remaining patches actually hook the phyter's pins into the new
> system.
>
> Comments and questions are most welcome.

Do you think it is possible to extend this in the future, e.g. for 
selecting the polarity of periodic output signals or for time stamping of 
external signals (rising edge/falling edge), or duty cycles of the periodic 
signal other than 50%? How could this be done? Using the reserved fields in 
struct ptp_pin_desc?

Do you think the concept allows an extension for single pulse output, e.g. 
programming a pin to output a single pulse at a given time, as supported by 
the DP83640?

If several DP83640 are connected together with the calibration function, 
only the GPIOs of the master device can be used, right? I guess this could 
also be extended in the future to use the GPIOs of all DP83640, right? Or 
do you see a problem with your concept here?

Best regards,
Christian

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html