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] [day] [month] [year] [list]

Date:	Wed, 12 Mar 2014 15:46:02 +0100
From:	Richard Cochran <richardcochran@...il.com>
To:	Christian Riesch <christian.riesch@...cron.at>
Cc:	netdev@...r.kernel.org, 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

On Wed, Mar 12, 2014 at 09:21:00AM +0100, Christian Riesch wrote:
> 
> 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?

Yes, this can be done, but this relates to the ptp_xyz_request ioctls
and not to the ptp_pin_desc. You asked for three things. Here is how
one might implement them.

1. selecting the polarity of periodic output signals

   ptp_perout_request.flags (new flag)

2. time stamping of external signals (rising edge/falling edge)

   This is already supported in the ptp_extts_request.flags field.
   The drivers just need to implement it.

3. duty cycles of the periodic signal other than 50%?

   Maybe using one of the ptp_perout_request.rsv fields.

> 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?

Yes, either a new ioctl or maybe ptp_perout_request.flags with a
ONE-SHOT flag.

> 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?

If the driver would combine all of the pins and functions over all the
devices, that would be best. I think it would be tricky to implement,
since the driver probe() function doesn't know how many more phyters
to expect.

Thanks,
Richard
--
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