From: Simon Horman <horms@kernel.org>
To: Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, kuba@kernel.org, pabeni@redhat.com,
davem@davemloft.net, edumazet@google.com,
vadim.fedorenko@linux.dev, arkadiusz.kubalewski@intel.com,
saeedm@nvidia.com, leon@kernel.org, jesse.brandeburg@intel.com,
anthony.l.nguyen@intel.com, rrameshbabu@nvidia.com
Subject: Re: [patch net-next v2 1/3] dpll: extend uapi by lock status error attribute
Date: Thu, 1 Feb 2024 14:53:11 +0100 [thread overview]
Message-ID: <20240201135311.GE530335@kernel.org> (raw)
In-Reply-To: <20240130120831.261085-2-jiri@resnulli.us>
On Tue, Jan 30, 2024 at 01:08:29PM +0100, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@nvidia.com>
>
> If the dpll devices goes to state "unlocked" or "holdover", it may be
> caused by an error. In that case, allow user to see what the error was.
> Introduce a new attribute and values it can carry.
>
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> Acked-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
The nit below notwithstanding, this looks good to me.
Reviewed-by: Simon Horman <horms@kernel.org>
...
> diff --git a/include/uapi/linux/dpll.h b/include/uapi/linux/dpll.h
> index b4e947f9bfbc..0c13d7f1a1bc 100644
> --- a/include/uapi/linux/dpll.h
> +++ b/include/uapi/linux/dpll.h
> @@ -50,6 +50,35 @@ enum dpll_lock_status {
> DPLL_LOCK_STATUS_MAX = (__DPLL_LOCK_STATUS_MAX - 1)
> };
>
> +/**
> + * enum dpll_lock_status_error - if previous status change was done due to a
> + * failure, this provides information of dpll device lock status error. Valid
> + * values for DPLL_A_LOCK_STATUS_ERROR attribute
> + * @DPLL_LOCK_STATUS_ERROR_NONE: dpll device lock status was changed without
> + * any error
> + * @DPLL_LOCK_STATUS_ERROR_UNDEFINED: dpll device lock status was changed due
> + * to undefined error. Driver fills this value up in case it is not able to
> + * obtain suitable exact error type.
> + * @DPLL_LOCK_STATUS_ERROR_MEDIA_DOWN: dpll device lock status was changed
> + * because of associated media got down. This may happen for example if dpll
> + * device was previously locked on an input pin of type
> + * PIN_TYPE_SYNCE_ETH_PORT.
> + * @DPLL_LOCK_STATUS_ERROR_FRACTIONAL_FREQUENCY_OFFSET_TOO_HIGH: the FFO
> + * (Fractional Frequency Offset) between the RX and TX symbol rate on the
> + * media got too high. This may happen for example if dpll device was
> + * previously locked on an input pin of type PIN_TYPE_SYNCE_ETH_PORT.
> + */
> +enum dpll_lock_status_error {
> + DPLL_LOCK_STATUS_ERROR_NONE = 1,
> + DPLL_LOCK_STATUS_ERROR_UNDEFINED,
> + DPLL_LOCK_STATUS_ERROR_MEDIA_DOWN,
> + DPLL_LOCK_STATUS_ERROR_FRACTIONAL_FREQUENCY_OFFSET_TOO_HIGH,
nit: I'm all for descriptive names,
but this one is rather long to say the least.
> +
> + /* private: */
> + __DPLL_LOCK_STATUS_ERROR_MAX,
> + DPLL_LOCK_STATUS_ERROR_MAX = (__DPLL_LOCK_STATUS_ERROR_MAX - 1)
> +};
> +
> #define DPLL_TEMP_DIVIDER 1000
>
> /**
> @@ -150,6 +179,7 @@ enum dpll_a {
> DPLL_A_LOCK_STATUS,
> DPLL_A_TEMP,
> DPLL_A_TYPE,
> + DPLL_A_LOCK_STATUS_ERROR,
>
> __DPLL_A_MAX,
> DPLL_A_MAX = (__DPLL_A_MAX - 1)
> --
> 2.43.0
>
>
next prev parent reply other threads:[~2024-02-01 13:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 12:08 [patch net-next v2 0/3] dpll: expose lock status error value to user Jiri Pirko
2024-01-30 12:08 ` [patch net-next v2 1/3] dpll: extend uapi by lock status error attribute Jiri Pirko
2024-02-01 13:53 ` Simon Horman [this message]
2024-02-01 15:02 ` Jakub Kicinski
2024-01-30 12:08 ` [patch net-next v2 2/3] dpll: extend lock_status_get() op by status error and expose to user Jiri Pirko
2024-02-01 13:53 ` Simon Horman
2024-01-30 12:08 ` [patch net-next v2 3/3] net/mlx5: DPLL, Implement lock status error value Jiri Pirko
2024-02-01 13:53 ` Simon Horman
2024-02-01 14:50 ` [patch net-next v2 0/3] dpll: expose lock status error value to user patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240201135311.GE530335@kernel.org \
--to=horms@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=arkadiusz.kubalewski@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jesse.brandeburg@intel.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rrameshbabu@nvidia.com \
--cc=saeedm@nvidia.com \
--cc=vadim.fedorenko@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.