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
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Reply via email to