netdev - Re: [PATCH net-next 1/3] ptp: add ability to configure duty cycle for periodic output

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]

Message-ID: <20200716220923.k6vwsjdk2os4rlrp@skbuf>
Date:   Fri, 17 Jul 2020 01:09:23 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     kuba@...nel.org, davem@...emloft.net, netdev@...r.kernel.org,
        richardcochran@...il.com, yangbo.lu@....com,
        xiaoliang.yang_1@....com, po.liu@....com,
        UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH net-next 1/3] ptp: add ability to configure duty cycle
 for periodic output

On Fri, Jul 17, 2020 at 12:49:27AM +0300, Vladimir Oltean wrote:
> On Thu, Jul 16, 2020 at 02:36:45PM -0700, Jacob Keller wrote:
> > 
> > 
> > On 7/16/2020 2:20 PM, Vladimir Oltean wrote:
> > > There are external event timestampers (PHCs with support for
> > > PTP_EXTTS_REQUEST) that timestamp both event edges.
> > > 
> > > When those edges are very close (such as in the case of a short pulse),
> > > there is a chance that the collected timestamp might be of the rising,
> > > or of the falling edge, we never know.
> > > 
> > > There are also PHCs capable of generating periodic output with a
> > > configurable duty cycle. This is good news, because we can space the
> > > rising and falling edge out enough in time, that the risks to overrun
> > > the 1-entry timestamp FIFO of the extts PHC are lower (example: the
> > > perout PHC can be configured for a period of 1 second, and an "on" time
> > > of 0.5 seconds, resulting in a duty cycle of 50%).
> > > 
> > > A flag is introduced for signaling that an on time is present in the
> > > perout request structure, for preserving compatibility. Logically
> > > speaking, the duty cycle cannot exceed 100% and the PTP core checks for
> > > this.
> > 
> > I was thinking whether it made sense to support over 50% since in theory
> > you could change start time and the duty cycle to specify the shifted
> > wave over? but I guess it doesn't really make much of a difference to
> > support all the way up to 100%.
> > 
> 
> Only if you also support polarity, and we don't support polarity. It's
> always high first, then low.
> 

Sorry for the imprecise statement.
If you look at things from the perspective of the signal itself, the
statement is correct.
If you look at them from the perspective of the imaginary grid drawn by
the integer multiples of the period, in the PHC's time (a digital
counter), the correct statement would be that "it's always rising edge
first, then falling edge".  And then the phase is just the delta between
these 2 points of reference.

Let me annotate this:

     t_on
     <------>
     t_period
     <--------->
phase
   <->
>    +------+  +------+  +------+  +------+  +------+  +------+  +------+
>    |      |  |      |  |      |  |      |  |      |  |      |  |      |
>  --+      +--+      +--+      +--+      +--+      +--+      +--+      +
> 
>  +---------+---------+---------+---------+---------+---------+--------->
   t=1000    t=1010    t=1020    t=1030    t=1040    t=1050    t=1060
>  period=10                                                          time
>  phase=2
>  on = 7
> 
> There's no other way to obtain this signal which has a duty cycle > 50%
> by specifying a duty cycle < 50%.
> 

Thanks,
-Vladimir