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>

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

When the servo is tracking, it oscillates between two states:
track_phase and wait_sync_idle.  Users should better not see
the "wait_sync_idle", becuase it look problematic but it is not
(earlier, the state was entered in the same way but not shown).

We are going to change the thing, and speed-up the servo as a side
effect, but meanwhile we'd better do this so ppsi's master can be
picked as the wrpc-sw submodule

Please note that state reported as number and string via SNMP may be
inconsistent.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

master port on GM should copy DefaultDS.clockQuality (e.g. clockClass)
to ParentDS.grandmaster.clockQuality so that it is send out in Announce
messages. BC should not do that, as it copies clockQuality received
on the slave port into the ParentDS.grandmaster.ClockQuality and sends
out on its master ports this info.

m1() was used always when entering MASTER on Announce timeout - this
caused "going up" port (which usually enters MASTER) to use m1()
to overwrite the parentDS->grandmasterClockClass with its local
ClockClass. This should not happen on BC which is already synchronized.

instead of GM clockQuality info, the information from Default DS
was sent in announce. Corrected according to Table 25, p129 of PTP

the bmc data copying functions (e.g. m1(), s1()) should be called
only as a result of BMCA. This is rather irrelevant for WR, but
important for PTP networks.

Remove ptpdexp_sync_state_t cur_servo_state from servo. All status info is now passed via ppsi's shmem.
Remove definition of ptpdexp_sync_state_t.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

This pointer is needed for wr_servo_reset function, since this function is
called without ppi context for wrpc-sw.

It is required since wr_servo_reset has to mark instance as invalid.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

This call is not needed since all status info is exported via shmem.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Reads of servo_state_name from shmem were inconsistent with reads of servo "state".
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

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

There is a need to update sfp_lib.h since new field vendor_name in
structure shw_sfp_caldata was added. That changes position of other fields in
shmem.
hal_shmem.h was updated because HAL's shmem version was changes.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

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

needed to implement shmem locking for ppsi
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>

file arch-wrs/include/ppsi-wrs.h is local to ppsi and including from wrs
causes conflicts.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Add unique fields for servo to wr_servo_state_t which is placed in shmem.
structure cur_servo_state to be removed soon.
Increment ppsi shmem version.
Part of a process to move wrs-servo internal data into shmem.

remove unused fields from wr_servo_state_t:
-TimeInternal prev_t4;
-TimeInternal nsec_offset;
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Part of a process to move wrs-servo internal data into shmem
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

also typedefs
hexp_port_state_t
hexp_port_list_t

Above are not used anymore due to move of port status read from minirpc to hal.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

get_port_state minipc call is not used anymore. All status requests were moved
to SHM. Remove also not used halexp_get_port_state and
hal_port_get_exported_state
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

make wrpc to use the same structures as HAL even though wrpc doesn't use real
HAL. The idea is it remove hexp_port_state completely.

Additionally indentation was fixed.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Function hal_port_get_exported_state, fills structure hal_port_state with data
that are not available in SHM. It just assigns defines.
These defines are private to HAL, and assignment should be done in HAL.

Similar problem is for wrpc. There is a wrapper function that pretends to be
HAL. All HAL info should be filled in that function.

Added:
--uint32_t clock_period;
--uint32_t t2_phase_transition;
--uint32_t t4_phase_transition;
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

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

delta_tx and delta_rx in the SFP information are differences from
the values in the "calibration" SFP model. Thus they are signed
not uint32_t.  Fortunately nobody used negative values so far.

I also renamed the fields, to ensure the compiler would find all uses.

(there are other irrelevant changes in upstream headers; this commits
puts them in sync again).
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

System time is used for log messages and nothing critical, so we'd
better have it different from WR time, when WR time is clearly wrong.
This commit avoids setting Unix time from WR time when WR time is
clearly wrong (i.e. earlier than today).

This, among other things, fixes a "fatal error" startup failure when
two free-running WRS devices are turned one at the same time
(noted by Adam Wujek).

This is because the master was counting from zero and the slave,
was setting system time accordingly; but the slave's boot procedure
already used wr_date to set the utc/tai offset, and system time
as a result  was being set to a negative value -- tai's being small,
"tai - 35" was negative.
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>