netdev - Re: [PATCH net-next v18 1/6] eea: introduce PCI framework

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: <20260107195227.GE345651@kernel.org>
Date: Wed, 7 Jan 2026 19:52:27 +0000
From: Simon Horman <horms@...nel.org>
To: Xuan Zhuo <xuanzhuo@...ux.alibaba.com>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Wen Gu <guwen@...ux.alibaba.com>,
	Philo Lu <lulie@...ux.alibaba.com>,
	Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
	Lorenzo Bianconi <lorenzo@...nel.org>,
	Lukas Bulwahn <lukas.bulwahn@...hat.com>,
	Dong Yibo <dong100@...se.com>,
	Vivian Wang <wangruikang@...as.ac.cn>,
	MD Danish Anwar <danishanwar@...com>,
	Dust Li <dust.li@...ux.alibaba.com>
Subject: Re: [PATCH net-next v18 1/6] eea: introduce PCI framework

On Mon, Jan 05, 2026 at 07:07:07PM +0800, Xuan Zhuo wrote:
> Add basic driver framework for the Alibaba Elastic Ethernet Adapter(EEA).
> 
> This commit implements the EEA PCI probe functionality.
> 
> Reviewed-by: Dust Li <dust.li@...ux.alibaba.com>
> Reviewed-by: Philo Lu <lulie@...ux.alibaba.com>
> Signed-off-by: Wen Gu <guwen@...ux.alibaba.com>
> Signed-off-by: Xuan Zhuo <xuanzhuo@...ux.alibaba.com>

...

> diff --git a/drivers/net/ethernet/alibaba/eea/eea_pci.c b/drivers/net/ethernet/alibaba/eea/eea_pci.c

...

> +static int eea_pci_setup(struct pci_dev *pci_dev, struct eea_pci_device *ep_dev)
> +{
> +	int err, n, ret;
> +
> +	ep_dev->pci_dev = pci_dev;
> +
> +	err = pci_enable_device(pci_dev);
> +	if (err)
> +		return err;
> +
> +	err = pci_request_regions(pci_dev, "EEA");
> +	if (err)
> +		goto err_disable_dev;
> +
> +	pci_set_master(pci_dev);
> +
> +	err = dma_set_mask_and_coherent(&pci_dev->dev, DMA_BIT_MASK(64));
> +	if (err) {
> +		dev_warn(&pci_dev->dev, "Failed to enable 64-bit DMA.\n");
> +		goto err_release_regions;
> +	}
> +
> +	ep_dev->reg = pci_iomap(pci_dev, 0, 0);
> +	if (!ep_dev->reg) {
> +		dev_err(&pci_dev->dev, "Failed to map pci bar!\n");
> +		err = -ENOMEM;
> +		goto err_release_regions;
> +	}
> +
> +	ep_dev->edev.rx_num = cfg_read32(ep_dev->reg, rx_num_max);
> +	ep_dev->edev.tx_num = cfg_read32(ep_dev->reg, tx_num_max);
> +
> +	/* 2: adminq, error handle*/
> +	n = ep_dev->edev.rx_num + ep_dev->edev.tx_num + 2;
> +	ret = pci_alloc_irq_vectors(ep_dev->pci_dev, n, n, PCI_IRQ_MSIX);
> +	if (ret != n)
> +		goto err_unmap_reg;

Hi,

As n is passed as both the min_vecs and max_vecs argument of
pci_alloc_irq_vectors() I believe that ret will either be n, on success,
or an negative error value error.

And on error I think it would be appropriate for this function
to return that error value, rather than 0 s is currently the case.

Something like this (completely untested!):

	err = pci_alloc_irq_vectors(ep_dev->pci_dev, n, n, PCI_IRQ_MSIX);
	if (err < 0)
		goto err_unmap_reg;

Function return value portion of the above flagged by Smatch.

> +
> +	ep_dev->msix_vec_n = ret;
> +
> +	ep_dev->db_base = ep_dev->reg + EEA_PCI_DB_OFFSET;
> +	ep_dev->edev.db_blk_size = cfg_read32(ep_dev->reg, db_blk_size);
> +
> +	return 0;
> +
> +err_unmap_reg:
> +	pci_iounmap(pci_dev, ep_dev->reg);
> +	ep_dev->reg = NULL;
> +
> +err_release_regions:
> +	pci_release_regions(pci_dev);
> +
> +err_disable_dev:
> +	pci_disable_device(pci_dev);
> +
> +	return err;
> +}

...

-- 
pw-bot: cr