On Tue, Mar 02, 2021 at 11:54:31AM +0100, luigi.mantell...@gmail.com wrote:
> This patch borns from my requirements and it permits to have a
> configurable portNumber.
Why is this useful?
Please explain the requirements and state the use case.
> @@ -826,12 +826,22 @@ static int clock_add_port(struct clock *c, const
> char *phc_device,
> struct interface *iface)
> {
> struct port *p, *piter, *lastp = NULL;
> + int port_number = config_get_int(c->config,
> interface_name(iface), "portNumber");
Your mailer is mangling the patch.
>
> if (clock_resize_pollfd(c, c->nports + 2)) {
> return -1;
> }
> +
> + if (port_number) {
> + c->last_port_number = (c->last_port_number >
> port_number ?
> + c->last_port_number :
> port_number) + 1;
> + } else {
> + port_number = ++c->last_port_number;
> + }
> +
This logic won't work correctly. The standard is quite explicit WRT
port numbering:
The value of the portNumber for a port on a PTP node supporting a
single PTP port shall be 1. The values of the port numbers for the
N ports on a PTP node supporting N PTP ports shall be 1, 2, ...N,
respectively.
Thus if you want configurable port numbers, then you need to ensure
that the configured numbering adheres to the scheme 1, 2, ... N.
> @@ -291,6 +291,7 @@ struct config_item config_tab[] = {
> GLOB_ITEM_DBL("pi_proportional_exponent", -0.3, -DBL_MAX,
> DBL_MAX),
> GLOB_ITEM_DBL("pi_proportional_norm_max", 0.7, DBL_MIN, 1.0),
> GLOB_ITEM_DBL("pi_proportional_scale", 0.0, 0.0, DBL_MAX),
> + GLOB_ITEM_INT("portNumber", 0, 0, UINT16_MAX),
Zero and 0xffff are not valid port numbers.
Thanks,
Richard
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
