This requires some change to the include files, to be able to
build for all architectures.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

The vlanhdr is not something I can find in standard include files,
so here is a custom definition, called pp_vlanhdr.

Adding peer_vid is needed so a master can reply to its own slave,
while listening to several vlans.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This step is in preparation for vlan support, where the tx and rx
headers have a different length.

This commit doesn't build for arch-wrpc, fixed in the next commit
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 "netpath" is a pain, completely needless. The NP(ppi)
is overhead in the code and must be removed. It is now turned to
an identity function, so external patches won't conflict.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This is partly undoing the previous commit, but there is really
no common code between udp and raw in the init path.

Besides, initializing for vlan means creating a raw socket, and
we'd break the whole "switch" idea.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

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

We can't have VLAN support with UDP, since this VLAN is a hack (needed
for GSI operational setup).

The error check about udp+vlan is only in time-unix, because arch-wrs
uses unix socket initialization, and other architectures can't run UDP.
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 was a trial of mine, but it really has never been working (at least
on wrs -- I think nobody ever tried a non-wr code base on wrpc).

Too much of the timetamping, servo, pll, is dependent on WR being
available, this academic idea doesn't make much sense, so let's remove
a number of conditionals (and associated potential bugs).
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

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

--update hal_shmem to version 7
--add tx and rx packet counters
--add error counters for SNMP
--increase ppsi shmem version to 6
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Add counters used by SNMP:
--n_err_state (state different than WR_TRACK_PHASE)
--n_err_offset (offset exceeded SNMP_MAX_OFFSET)
--n_err_delta_rtt (delta rtt exceeded SNMP_MAX_DELTA_RTT)
--n_err_rxtx_deltas (any delta_*x_* bigger than SNMP_MAX_RXTX_DELTAS)
All these counters are increased on servo update if error condition is met

Due to above, increase WRS_PPSI_SHMEM_VERSION to 6
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Add counting of tx and rx PTP packets.
__recv_and_count and __send_and_log are arch independent functions.
Increase WRS_PPSI_SHMEM_VERSION due to add of tx_count and tx_count firlds in
pp_instance.
Update WRS_PPSI_SHMEM_VERSION to 5
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Remove fields used to keep thresholds of temperature sensors (not used by ppsi)
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

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

This temporary wr-servo state, with the hack of next_state is not
really clean. I took a while to understand it, and this tries to make
it clearer for my fellow developer.

When we change state by commanding hardware, we must wait for hw to be
done with the change, and this is better a flag than another state.

While making this clean, the commit stresses the fact that we loose
one wr-servo iteration every two of them.  Unfortunately, the trivial
fix I tried some time ago doesn't actually work (the slave won't
sync), so the behaviour remains unchanged by this commit, but the
problem is not clearly visible in code and comments, so we may fix it
"the real way" later on.
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>

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

We were already following big jump, in theory, but we were missing a break
statement.  Now tracking jumps in the master is working.

The commit also fixes another details, zeroing an error counter when
restarting sync because of that very error counter.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

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

After changing the nsec counter, the next state should be SYNC_PHASE,
not SYNC_NSEC.  This was a mistake when making order in the wr-servo
file, initially, but has no effect as we move to a later step anyways
if offset_hw.nanoseconds is already 0.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

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

Add information to section "Diagnostic Macros" that diagnostics can be enabled
by specifying proper string after -d switch in command line or by "diagnostics"
option in configuration file.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Port configured to PPSI_ROLE_MASTER must do m1() update of data set
only if it is a port of a GM. We need the dataSet comparision to
know this (thus we calculate the compres value) even on the ports
forced to be masters by default

This is the result of an audit of all send functions. Most are not
affected, because they send on the "general" channel. But when event
messages are sent, an error of SEND_NO_STAMP must not be fatal.
In WR, for example, after a sync the stamping engine reports invalid
stamps for a second.

I chose not to change the return type of the sending function and have
the compiler help me, because my mates are working on peer-delay and I'd
better not make the merge more difficult for us.

Unfortunately, my wrs is still not syncing with this patch, as it remains
stuck in SYNC_NSEC (in the state machine within the WR servo). See
next commit....
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This is the first step to fix a problem introduced by commit 79ffd673
(a fix to release 4.1.2 forward ported to master).

When we get a bad timestamp in sending sync, we should not return "error"
but a special value for "no timestamp". Otherwise the caller goes to
"faulty" state and can't sync any more (this situation loops over).

Also, check for timestamp errors only for event message, or we break
out of the messaging loop during wr synchronization (when we get bad
timestamps for frames whose timestamp we don't care about).
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

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

anyways, we can't send delay_req just after receiving f-up.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

When the wrs has high data traffic, the tx stamp can be delayed more than
the time it takes for software to poll for it.

What happened is that we got back -EAGAIN, but when collecting the
next stamp we got the previous one, and sync goes nuts ever after.

This uses poll() to wait a little for the timestamp.

Moreover, we check the frame we get back, so we can discard it in case
some unsync between tx frames and timestamps happen -- checking frame
contents is the suggested policy anyways, but I've been lazy in this,
when I drafted this wrs support.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This is bsased on Greg's original commit, which is in wrs-4.1.2-fixes,
that we developed and released in the wr-switch-sw maintainance for the
4.1 series.

What we do here is return error for sending if the timestamp is not
correctly retrieved; the error is already handled in the sync+f.up
pair, so this is enough for f.up to not be sent.

The commit also changes state-master, in that we need to restart the
timeout for sync (and annunce) even if one even of sync (announce,
resp) fails.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>