netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 
> 

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).