linux-kernel - Re: [Intel PMC TGPIO Driver 0/5] Add support for Intel PMC Time GPIO Driver with PHC interface changes to support additional H/W Features

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200226024707.GA10271@localhost>
Date:   Tue, 25 Feb 2020 18:47:07 -0800
From:   Richard Cochran <richardcochran@...il.com>
To:     "Christopher S. Hall" <christopher.s.hall@...el.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        tglx@...utronix.de, hpa@...or.com, mingo@...hat.com,
        x86@...nel.org, jacob.e.keller@...el.com, davem@...emloft.net,
        sean.v.kelley@...el.com
Subject: Re: [Intel PMC TGPIO Driver 0/5] Add support for Intel PMC Time GPIO
 Driver with PHC interface changes to support additional H/W Features

On Tue, Feb 25, 2020 at 03:37:07PM -0800, Christopher S. Hall wrote:
> On Sun, Feb 02, 2020 at 08:08:38PM -0800, Richard Cochran wrote:
> > The TGPIO input clock, the ART, is a free running counter, but you
> > want to support frequency adjustments.  Use a timecounter cyclecounter
> > pair.
> 
> I'm concerned about the complexity that the timecounter adds to
> the driver. Specifically, the complexity of dealing with any rate mismatches
> between the timecounter and the periodic output signal. The phase
> error between the output and timecounter needs to be zero.

If I understood correctly, the device's outputs are generated from a
non-adjustable counter.  So, no matter what, you will have the problem
of changing the pulse period in concert with the user changing the
desired frequency.

> My counter-proposal would be to use the real-time clock as the basis of the
> device clock. This is fairly simple because the relation between ART and the
> realtime clock is known. When output is enabled any phase error between
> the realtime clock and the periodic output signal is accumulated in the
> SYS_OFFSET result.

I don't understand how you intend to do this...
 
> This leaves the PHC API behavior as it is currently and uses the frequency
> adjust API to adjust the output rate.
> 
> > Let the user dial a periodic output signal in the normal way.
> > 
> > Let the user change the frequency in the normal way, and during this
> > call, adjust the counter values accordingly.
> 
> Yes to both of the above.

So, why then do you need this?

+#define PTP_EVENT_COUNT_TSTAMP2 \
+       _IOWR(PTP_CLK_MAGIC, 19, struct ptp_event_count_tstamp)

If you can make the device work with the existing user space API,

	ioctl(fd, PTP_PEROUT_REQUEST2, ...);
	while (1) {
		clock_adjtimex(FD_TO_CLOCKID(fd), ...);
	}

that would be ideal.  But I will push back on anything like the
following.

	ioctl(fd, PTP_PEROUT_REQUEST2, ...);
	while (1) {
		clock_adjtimex(FD_TO_CLOCKID(fd), ...);
		ioctl(fd, PTP_EVENT_COUNT_TSTAMP, ...);
	}

But maybe I misunderstood?

Thanks,
Richard