The patches from the audit chapter 2.4.1 were ported, some of the
changes were not ported due to previous changes or different
foreign master handling, eg.g announce unpacking is still done since
this seems more streamline with other message handling and is actually
still used for field extraction for the foreign master data set

For the announce receipt timeout the datasets shall be updated depending on the other ports states, only if no other in slave update parent dataset.
when a link was connected it runs through initializing which was wrongly updating the parent dataset which caused a short masterchange condition an resyncing.

changed peer delay handling so p2p messages are only answered when in this mode
added p2p messages to some states where it was missing

Message handling for the case of received back frames changed and timeouts for announces reset according to standard

The calibration handshake is now started on the slave state base
Announce messages from the same device are handled differnetly for a BC

A hook was added that handles the wr states, so that they don't get overwritten by bmc decisions.
The extension stays in the white rabbit states until a calibration is done.

The FSM order was changed in order to leave the fsm on a state change and re-enter the fsm directly afterward,
this makes sure no state decision is overwritten by the state handling and each state dicision is handled at least once,
There seems to be an issue with htons on unaligned addresses, which is the case for stepsRemoved in an announce,
a workaround of a manual 16bit conversion was added.

Merged uncalibrated and slave state, added event handling to the individual states,
changed in all states the frame handling to table driven handling,
moved common handling from common to slave since it is actually not common,
fixed state passive to be according to standard,
added uncalibrated handling,
fixed listening and master frame handling,

BMC fixed to be called periodically and data sets comparisments fixed
also changed the foreign master table adding and agging and some
minor adpatations in state pre-master

This reverts commit a72f6bdc.

Remove warning that HAS_ABSCAL is redefined
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

This is a port of previous work by Peter Jansweijer from nikhef.

To perform absolute calibration, we need a grand-master look-alike
mode that sends sync once a second (and hopefully slightly after the
pps signal).

Using a special gateware that sends a pulse whenever a frame is
transmitted and received, users can correlate collected timestamps
(T1 and T4), this special pulse and the pps pulse of the node.

The procedure for absolute calibration is described in

http://www.ohwr.org/attachments/4542/WhiteRabbitAbsoluteCalibrationProcedure.pdf

Another commit, in wrpc-sw, adds "mode abscal" for this feature to be used.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This is used by absolute calibration, where we send sync and no f-up.
We may implement two-step flag, actually, but this is an easier choice.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

format is "%9d.%09d.%03d". This is not properly a flating point number, but
counting 9 digits is already heavy, I'd better not have a 12-digit field
(which, btw, will be wrongly converted by 32-bit parsers).

This comes from a similar change by Peter Jansweijer from nikhef,
for absolute-calibration work.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

The previous commit is not enough as a fix.  This may happen:

    - we invalidate stamps after processing them
    - we send request
    - get reply, loose reply-fup
    - send request
    - loose reply, get f-up

So we now invalidate when sending the request. And invalidate t4 alone
as the beautifulness and symmetry of the previous commit is lost
anyways.

Note: there no need to invalidate stamps in e2e mode, because checking
the sequence number to validate RX frames is enough.  But here all
replies match the sequence number, so the problem is not caught and
stamps from different tuples are mixed.

Example beofre this commit, with trimmed stamps (was 1497283863):

   diag-frames-1-wr1: SENT 54 bytes at 863.333173928 (pdelay_req)
   diag-frames-1-wr1: RECV 54 bytes at 863.334158796 (type 3, pdelay_resp)
   diag-frames-1-wr1: Drop received frame
   diag-frames-1-wr1: SENT 54 bytes at 864.479336104 (pdelay_req)
   diag-frames-1-wr1: Drop received frame
   diag-frames-1-wr1: RECV 54 bytes at 864.481095164 (type a, presp_follow_up)

   diag-servo-2-wr1: servo:t3 = 864:479336104:0
   diag-servo-2-wr1: servo:t4 = 863:333174267:586
   diag-servo-2-wr1: servo:t5 = 864:480295312:0
   diag-servo-2-wr1: servo:t6 = 863:334158796:773
   diag-servo-2-wr1: ->mdelay = -2:-292298352:359
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

The code is checking the sequence number of pdelay-rep and
pdelay-rep-fup, but we may miss the reply and get the f-up.

The result was something like this (first tuple is ok, next is wrong):

   diag-servo-2-wr1: servo:t3 = 1497279009:22584224:0
   diag-servo-2-wr1: servo:t4 = 1497279009:22584574:759
   diag-servo-2-wr1: servo:t5 = 1497279009:23564032:0
   diag-servo-2-wr1: servo:t6 = 1497279009:23564365:547
   diag-servo-2-wr1: ->mdelay = 0:684:306

   diag-servo-2-wr1: servo:t3 = 1497279009:663586672:0
   diag-servo-2-wr1: servo:t4 = 1497279009:22584574:759
   diag-servo-2-wr1: servo:t5 = 1497279009:683142000:0
   diag-servo-2-wr1: servo:t6 = 1497279009:23564365:547
   diag-servo-2-wr1: ->mdelay = -1:-300579732:306

Here, t4 and t6 are old. The former is the receipt of the request,
send back to the "slave" in the pdelay-reply payload; the latter is
the receive time of such frame.

We now invalidate t4 and t5 when using the tuple. They are the two
"remote" times, one sent back in the response and the other sent back
in the response-fup.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Dropping on tx is normal behaviour under test. state-listening is
still entering faulty (thus waiting 4 seconds before restarting) if tx
fails.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

It was a hack of mine, I'd better call it by name. We must spit
no errors when injecting faults.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

If we stopped sending to the master or the peer (for traffic or
whatever; in my case with "fault drop"), we wouldn't notice the
problem.

This looks like SYNCHRONIZATION_FAULT (9.2.6.12), so this reuses the
almost-unused TO_FAULTY, renaming it to a more generic TO_FAULT.

9.2.6.12 says we should reach uncalibrated, but since uncalibrated doesn't
exits (it is never entered, it's dead and untested code at this point),
I handle the problem just like the timeout receiving announce messages.

For wr, I reset the servo, so the problem can be seen.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

There is no need to go to 0 phase at servo init. It is already 0
at the beginning of the world, but on re-track it can be the same
as it was.

With this change, if we loose track due to packet loss and timeout
(thanks to a few commits ago), we recover in 1..4 seconds as opposed
to 5..9 without this commit.

Tested with "fault drop 0 1000" and later "fault drop 0 0", and
a syslog server:

   Jan  1 00:00:10 192.168.16.229 (22:33:44:55:66:77) Node up since 10 seconds
   Mar 14 15:48:55 192.168.16.229 Tracking after 7.178 s
   Mar 14 15:49:07 192.168.16.229 Lost track
   Mar 14 15:49:11 192.168.16.229 2-th re-rtrack after 4.171 s
   Mar 14 15:49:30 192.168.16.229 Lost track
   Mar 14 15:49:32 192.168.16.229 3-th re-rtrack after 2.485 s
   Mar 14 15:49:49 192.168.16.229 Lost track
   Mar 14 15:49:51 192.168.16.229 4-th re-rtrack after 2.559 s
   Mar 14 15:50:13 192.168.16.229 Lost track
   Mar 14 15:50:16 192.168.16.229 5-th re-rtrack after 3.171 s
   Mar 14 15:50:31 192.168.16.229 Lost track
   Mar 14 15:50:32 192.168.16.229 6-th re-rtrack after 1.589 s

With the original commit for this, Adam found that by unplugging
and re-plugging the fiber our setpoint is always increasing, up to big
values. I checked, and the softpll is always using the module. I brought
the phase value up to hundreds of nanos both positive and negative, without
any issues.  So this version of the commit makes a modulus of the set
point, to avoid it getting too big and scare a user watching the logs.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This branch is a singe commit which is used in wr-switch-sw, where
ppsi is a submodule.

Let's merge it here to avoid loosing the hash.

When two masters are connected to the same link one of them tries to enter
a state pre-master. However, this state is not compiled in the ppsi, so one
node stuck there forever. It is necessary to restart a node or re-establish
a link.

BUG introduced by a PPSI's commit:
2996dd7b compliance, 9.2.6.10: properly switch to MASTER or PRE_MASTER
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

It was by me fore me, and I'm not using it. Simplify.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

When two masters are connected to the same link one of them tries to enter
a state pre-master. However, this state is not compiled in the ppsi, so one
node stuck there forever. It is necessary to restart a node or re-establish
a link.

BUG introduced by a PPSI's commit:
2996dd7b compliance, 9.2.6.10: properly switch to MASTER or PRE_MASTER
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Add casting for delay_ms_fix calculations, otherwise
((s->picos_mu - big_delta_fix) * s->fiber_fix_alpha)
is shifted as unsigned.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

If meanPathDelay is calculated negative at the first iteration, we
must zero it immediately, or this will loop forever:

	while (mpd_fltr->y >> (63 - s))
		--s;

The bug only appears with e2e mechanism, where t3 happens long after
t2, if the slave clock when ppsi starts is running much slower than
the master.

Before changing data structures we used abs() in that loop (which was
suboptimal), and I made a mistake in converting it in a check before
the loop itlsef.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Increment due to cField changes
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

There is still some factorization to make, and other irrelevant
size-related things, but I'd better wait a little and get confident
this stuff is solid.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>