Re: [Linuxptp-devel] [RFC 1/1] Add avnu_ap to enable AVnu Automotive Profile

[Patel, V. <ved...@in...>]

Thanks Richard for the inputs.

On Tue, 2018-07-24 at 19:55 -0700, Richard Cochran wrote:
> On Tue, Jul 24, 2018 at 05:38:32PM +0000, Patel, Vedang wrote:
> > 
> > So, following is what we think will do the job:
> > - Add inhibit_announce option to stop announce messages as well as
> > timeouts. (default: 0 - disabled)
> Sounds okay.
> 
> > 
> > - Add source_port_identity_check option to disable checking for
> > source
> > port identities in sync and follow-up messages (default: 1 -
> > enabled)
> Or keeping with the negative tone, "ignore_source_id".  (Ignore and
> inhibit sound good together.)
> 
yeah ignore_source_id seems better. will use that.
> > 
> > - Add static_roles config which is a tristate - master, slave and
> > disabled. When master or slave roles are selected, the FSM will
> > directly assign those roles. (default: 'disabled')
> We already have slaveOnly and masterOnly.  All you need is a new
> option for your different BCMA, say "BCMA = noop".
> 
> Then provide two functions for p->state_machine, something like the
> following pseudo code.
> 
> enum port_state designated_master_fsm() {
> 	return PS_GRAND_MASTER;
> }
> enum port_state designated_slave_fsm() {
> 	return PS_SLAVE;
> }
> 
> port_open() {
> 	...
> 	if (BMCA == noop) {
> 		p->state_machine = clock_slave_only(clock) ?
> 			designated_slave_fsm : designated_master_fsm;
> 	}
> }
>  
In the description above, you mentioned that we should use masterOnly
and slaveOnly. But, from the pseudo code, it seems like you just want
to make decision based only on slaveOnly option. Which one do you
prefer?

In my opinion, we should use both the options to remove any ambiguity.
This would mean, if we decide to support brides (in the future), we
will have to change slaveOnly from global to per-port config option.

If we are just using a single option, I would prefer masterOnly since
it is a per-port variable and extending support to bridges will be
easy.
> > 
> > We also looked into the slaveOnly FSM for slave. But, we cannot use
> > that because it still expects the announce message from the master
> > before transitioning to UNCALIBRATED state.
> You can surely use the slaveOnly option, but of course you wouldn't
> use the ptp_slave_fsm function itself.
> 
> Thanks,
> Richard