netdev - Re: [PATCH v2 1/2] dp83640: Support a configurable number of periodic outputs

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: <1392301311.2585.9.camel@e37108.spectralink.com>
Date:	Thu, 13 Feb 2014 15:21:51 +0100
From:	Stefan Sørensen 
	<stefan.sorensen@...ctralink.com>
To:	Richard Cochran <richardcochran@...il.com>
CC:	<grant.likely@...aro.org>, <robh+dt@...nel.org>,
	<mark.rutland@....com>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] dp83640: Support a configurable number of
 periodic outputs

On Tue, 2014-02-11 at 21:09 +0100, Richard Cochran wrote:

> > -#define EXT_EVENT	1
> 
> Regarding this EXT_EVENT thing ...
> 
> > @@ -430,12 +419,12 @@ static int ptp_dp83640_enable(struct ptp_clock_info *ptp,
> >  	switch (rq->type) {
> >  	case PTP_CLK_REQ_EXTTS:
> >  		index = rq->extts.index;
> > -		if (index < 0 || index >= N_EXT_TS)
> > +		if (index < 0 || index >= n_ext_ts)
> >  			return -EINVAL;
> > -		event_num = EXT_EVENT + index;
> > +		event_num = index;
> 
> there was a mapping between the "event numbers" and the external time
> stamp channels. I don't remember off the top of my head why this these
> two differ by one, but there was a good reason.

I haven't seen anything in the documentation regarding this, output
triggers 0 and 1 are special, but the events should all behave the same.
Could be be a mixup between events and pins? Pin0 means disable the
event.

> Are you sure this is still working with this change?

It has been running with event 0 in one of our products for at least the
last 3 months....

> I am especially wondering about the event decoding here:
> 
> > @@ -642,7 +631,7 @@ static void recalibrate(struct dp83640_clock *clock)
> >  
> >  static inline u16 exts_chan_to_edata(int ch)
> >  {
> > -	return 1 << ((ch + EXT_EVENT) * 2);
> > +	return 1 << ((ch) * 2);
> >  }
> 
> Maybe I am just paranoid, but can you remind me how these event
> numbers are supposed to work, before and after the change?

The mapping was hardcoded to map events 0-5 to event channels 1-6, the
periodic output trigger at channel 6 and the calibration event+trigger
both at channel 7.

The patch will (at least in v3 that I will post shortly) change both the
event and trigger mapping to a direct mapping and keep the calibration
at channel 7.

Stefan


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