netdev - Re: [PATCH net-next v9 02/13] net:ethernet:realtek:rtase: Implement the .ndo

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]

Date: Thu, 28 Sep 2023 14:57:13 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Justin Lai <justinlai0215@...ltek.com>
Cc: kuba@...nel.org, davem@...emloft.net, edumazet@...gle.com,
	pabeni@...hat.com, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, pkshih@...ltek.com, larry.chiu@...ltek.com
Subject: Re: [PATCH net-next v9 02/13] net:ethernet:realtek:rtase: Implement
 the .ndo_open function

> diff --git a/drivers/net/ethernet/realtek/rtase/rtase.h b/drivers/net/ethernet/realtek/rtase/rtase.h
> index bae04cfea060..5314fceb72a2 100644
> --- a/drivers/net/ethernet/realtek/rtase/rtase.h
> +++ b/drivers/net/ethernet/realtek/rtase/rtase.h
> @@ -51,8 +51,6 @@
>  
>  #define RX_BUF_SIZE (1522 + 1)
>  
> -#define IVEC_NAME_SIZE IFNAMSIZ + 10
> -
>  /*****************************************************************************/
>  enum rtase_registers {
>  	RTASE_MAC0   = 0x0000,
> @@ -261,6 +259,8 @@ union rx_desc {
>  #define RTASE_IDLESLOPE_INT_SHIFT 25
>  #define RTASE_IDLESLOPE_INT_MASK  GENMASK(31, 25)
>  
> +#define IVEC_NAME_SIZE IFNAMSIZ + 10
> +

Please try to avoid moving things around which you just added in the
previous patch.

> +static int rtase_open(struct net_device *dev)
> +{
> +	struct rtase_private *tp = netdev_priv(dev);
> +	struct rtase_int_vector *ivec = &tp->int_vector[0];
> +	const struct pci_dev *pdev = tp->pdev;
> +	int ret;
> +	u16 i;
> +

> +	netif_carrier_on(dev);
> +	netif_wake_queue(dev);
> +	netdev_info(dev, "link up\n");

No need to spam the log with this. Given the hardware architecture,
the link is always going to be up.

    Andrew