If no follow-up is to be received, we trigger pp_servo_got_presp()
on reception of peer delay response.

In this case we also possibly have switch to port state to PASSIVE.

A function should only do what it promises, so msg_unpack_header should
just unpack. This move also gets also us ready for fixing compliance
to 9.5.2.3.

This gets us ready for leaving a state as a consequence of filtered out
messages (9.5.2.3: discard announce AND switch state to PASSIVE).

    See Table 13.
    Note that we keep currentUtcOffset as it is and reset currentUtcOffsetValid,
    because  we presently don't know about leap seconds.
    leap59 and leap61 are forced to zero.

See Table 13.

See Table 20.

We don't support alternate masters at present.

We're not a transparent clock, so this should be ok.

We also avoid setting the same flag while handling a Pdelay_Resp_Followup.

remove duplication, remove code size

11.3 d says:

Upon receipt of the Delay_Resp message by the slave:

1) If the received Sync message indicated that a Follow_Up message will not
   be received, the <meanPathDelay> shall be computed as:
   <meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message -
   originTimestamp of Sync message) -
   correctionField of Sync message -
   correctionField of Delay_Resp message]/2.
2) If the received Sync message indicated that a Follow_Up message will be
   received, the <meanPathDelay> shall be computed as:
   <meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message -
   preciseOriginTimestamp of Follow_Up message) -
   correctionField of Sync message -
   correctionField of Follow_Up message -
   correctionField of Delay_Resp message]/2.

We assume that:

t1 = originTimestamp of Sync message (one step) or
t1 = preciseOriginTimestamp of Follow_Up message (two steps)

      and

t4 = receiveTimestamp of Delay_Resp message

wich is true for masters not supporting sub-nanosecond
timestamps (we don't support sub-ns precision via standard protocol, so the
assumption should be true for us).

As sync (or followup) arrives, we calculate m_to_s_dly, which is:

t2 - t1 - cf_sync - cf_followup

When delay_resp arrives, we calculate s_to_m_dly, which is:

t4 - t3 - cf_delay_resp

So [(m_to_s_dly + s_to_m_dly) / 2] should be equal to:

(t2 - t3 + t4 - t1 - cf_sync - cf_followup - cf_delay_resp) / 2

which looks like the 11.3 d expression for mean path delay
(note that cf_followup is zero for a one-step master).

To get this result, we just save the delay_resp cf to ppi->cField.

11.2 c says:

If the twoStepFlag bit of the flagField of the of the Sync message is TRUE,
indicating that a Follow_Up message will be received, then

        <offsetFromMaster> = <syncEventIngressTimestamp> -
       <preciseOriginTimestamp> - <meanPathDelay> -
       correctionField of Sync message -
       correctionField of Follow_Up message.

Before this patch, only the correctionField of the Sync message was
subtracted. We fix things by adding the Follow_Up correctionField to the
Sync correctionField.

Now m_to_s_dly as calculated in pp_servo_got_sync is:

t2 - t1 - sync_cf - follow_up_cf

Before this commit, ANNOUNCE messages were sent with grandmaster-related
fields equal to 0. Values for such fields were taken from the parentDS data
set, which did not look properly initialized.

Paragraphs 8.2.3.2 to 8.2.3.9 of the ieee1588 standard specify
initialization values for the parentDS data set.
Many such values come from the defaultDS, so care must be taken to
initialize the parent data set __after__ the default data set.
We do this in pp-initializing().
Signed-off-by: Davide Ciminaghi <ciminaghi@gnudd.com>

Please note that timeout_init is not resetting timeouts, it's just
saving the values for later settings.
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>

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

The bmc may turn a port to passive state, so we need the
state in our state table.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

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

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

remove rules like:
--allmodconfig
--kvmconfig
--xenconfig
--tinyconfig

change directory with configs
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Now it is also possible to use for dot-config configuration:
make nconfig
make xconfig
make gconfig
make menuconfig

kconfig is taken from the linux kernel repo commit v4.8-rc1-19-g81abf25:
e50bd235 Merge tag 'lkdtm-v4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linuxSigned-off-by: Adam Wujek <adam.wujek@cern.ch>

Fix command make config. The error was probably introduced by commit:
b88106b3 trivial: Makefile: fix for make v4
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Uplift shmem from wr-switch-sw repo.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>