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.