lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <81aa3232-b706-4931-87a2-13dfed82e9c7@kernel.org>
Date: Mon, 22 Jan 2024 15:42:53 +0200
From: Roger Quadros <rogerq@...nel.org>
To: Diogo Ivo <diogo.ivo@...mens.com>, danishanwar@...com,
 davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
 pabeni@...hat.com, grygorii.strashko@...com, andrew@...n.ch,
 linux-arm-kernel@...ts.infradead.org, netdev@...r.kernel.org
Cc: Jan Kiszka <jan.kiszka@...mens.com>
Subject: Re: [PATCH v2 6/8] net: ti: icssg-ethtool: Adjust channel count for
 SR1.0



On 17/01/2024 18:15, Diogo Ivo wrote:
> SR1.0 uses the highest priority channel to transmit control
> messages to the firmware. Take this into account when computing
> channels.
> 
> Based on the work of Roger Quadros in TI's 5.10 SDK [1].
> 
> [1]: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/?h=ti-linux-5.10.y
> 
> Co-developed-by: Jan Kiszka <jan.kiszka@...mens.com>
> Signed-off-by: Jan Kiszka <jan.kiszka@...mens.com>
> Signed-off-by: Diogo Ivo <diogo.ivo@...mens.com>
> ---
>  drivers/net/ethernet/ti/icssg/icssg_ethtool.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/ti/icssg/icssg_ethtool.c b/drivers/net/ethernet/ti/icssg/icssg_ethtool.c
> index a27ec1dcc8d5..29e67526fa22 100644
> --- a/drivers/net/ethernet/ti/icssg/icssg_ethtool.c
> +++ b/drivers/net/ethernet/ti/icssg/icssg_ethtool.c
> @@ -141,6 +141,9 @@ static int emac_set_channels(struct net_device *ndev,
>  		return -EBUSY;
>  
>  	emac->tx_ch_num = ch->tx_count;
> +	/* highest channel number for management messaging on SR1 */
> +	if (emac->is_sr1)
> +		emac->tx_ch_num++;

I don't recollect now but is management channel always pinned to the highest priority
channel?

Wouldn't it be better if we don't mix up management channel details here
in emac_get/set_channels(). So this patch is not required and we only need
to set ch->max_tx to PRUETH_MAX_TX_QUEUES-1 for sr1?

>  
>  	return 0;
>  }
> @@ -151,9 +154,12 @@ static void emac_get_channels(struct net_device *ndev,
>  	struct prueth_emac *emac = netdev_priv(ndev);
>  
>  	ch->max_rx = 1;
> -	ch->max_tx = PRUETH_MAX_TX_QUEUES;

Leave the above intact and add
	if (emac->is_sr1)
		ch->max_tx--;

> +	/* SR1 use high priority channel for management messages */
> +	ch->max_tx = emac->is_sr1 ? PRUETH_MAX_TX_QUEUES - 1 :
> +				    PRUETH_MAX_TX_QUEUES;
>  	ch->rx_count = 1;
> -	ch->tx_count = emac->tx_ch_num;
> +	ch->tx_count = emac->is_sr1 ? emac->tx_ch_num - 1 :
> +				      emac->tx_ch_num;
>  }
>  
>  static const struct ethtool_rmon_hist_range emac_rmon_ranges[] = {

-- 
cheers,
-roger

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ