On Mon, 2018-10-01 at 10:59 -0700, Richard Cochran wrote:
> On Mon, Oct 01, 2018 at 05:24:48PM +0000, Patel, Vedang wrote:
> >
> > I will add the comment for clearing the SYNC_RX_TIMER. It is
> > basically
> > to clear out the event returned by poll().
> But why? Does the original code have a bug? Please explain.
>
In the original code, whenever we receive a FD_SYNC_RX_TIMER timeout,
it is usually accompanied by a state transition. So,
port_*_transition() will take care of clearing the event for us (by
calling port_clr_tmo() at the beginning). But, when BMCA == 'noop',
there is nothing to do, so we are not clearing out the event and poll()
will report the event in every loop. I am just taking care of clearing
this event here.
> >
> > But, I don't understand how moving the inhibit_announce before this
> > will help.
> You avoid changing the behavior of the non-noop-BCMA code.
>
> >
> > I am not removing the hunk anywhere.
> You are right. I misread the next patch.
>
> BUT you avoid changing the original behavior by doing this:
>
> if (p->inhibit_announce) {
> port_clr_tmo(p->fda.fd[FD_ANNOUNCE_TIMER]);
> port_clr_tmo(p->fda.fd[FD_SYNC_RX_TIMER]);
> } else {
> port_set_announce_tmo(p);
> }
>
The SYNC_RX_TIMER needs to be cleared out whenever BMCA == 'noop' (or
any other future state machine which does not do any state transition
in this case). I will add the condition to clear out the timer only
when BMCA == 'noop'.
Thanks,
Vedang
> See?
>
> Thanks,
> Richard
_______________________________________________
Linuxptp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
