From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-180.mta0.migadu.com (out-180.mta0.migadu.com [91.218.175.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 65907350820 for ; Tue, 9 Sep 2025 14:37:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757428658; cv=none; b=EEae7r/jsHTpEmEZhtcQzXHSRTh4kURYeQm/1MYLjH5hX+hoafc4Az0gQUniY8/YU0xmp8OkWkrdEV7qNt6kdUBjp70UIpN+sDNN55oZF/lgIyRfG7HdbcmVtcON91mP0arvKZ+HQ341UQ21MuDx3ycDokXBPWLRV3L7DjV+9bo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757428658; c=relaxed/simple; bh=hImgRP5PDSJ8tahE+RtUsG3WvwJy/+Y1BnkvJrIMRfM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NjZwTxomSIAEEnDxcNgUs3NfCQI9wSSDLRPNl1yR9fsONLkBspLqb3iDw17srtRkLqapV6LArt/B7QKDd1FsxTraA0Ab/c8zw9gtqFQmgplJLZ4Tl11DZSKKTjJvp6RdXkzUSvyCKUiD9Mq3RKytSMEcdV0B9Kue32oK1IdEPFY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=OBtCrRsb; arc=none smtp.client-ip=91.218.175.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="OBtCrRsb" Message-ID: <2ec8c7f8-cf79-4701-97dc-2d0a687f0f3b@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1757428643; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=joBHHo2vNOa9/tISXv4x8ETwG4JXU3LtDMt2JeCyLyM=; b=OBtCrRsbxfPzoj5D3rkn5kRq6++vRm4cPJxZet2JnWn0QfYPTL7nbnbOZWm5Tw3rBdC3uq IQJ0BUlyseKMXmdkTRZLSkawjmyuAbFXu0zZjb8Zo/VdP0anjTSxei8fqRFe84t6u9fRD4 WcPczDipxB6bdThSvMIuiY+tTZsSQ+Y= Date: Tue, 9 Sep 2025 15:37:19 +0100 Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH net-next v11 5/5] net: rnpgbe: Add register_netdev To: Dong Yibo , andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, corbet@lwn.net, gur.stavi@huawei.com, maddy@linux.ibm.com, mpe@ellerman.id.au, danishanwar@ti.com, lee@trager.us, gongfan1@huawei.com, lorenzo@kernel.org, geert+renesas@glider.be, Parthiban.Veerasooran@microchip.com, lukas.bulwahn@redhat.com, alexanderduyck@fb.com, richardcochran@gmail.com, kees@kernel.org, gustavoars@kernel.org, rdunlap@infradead.org Cc: netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org References: <20250909120906.1781444-1-dong100@mucse.com> <20250909120906.1781444-6-dong100@mucse.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Vadim Fedorenko In-Reply-To: <20250909120906.1781444-6-dong100@mucse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 09/09/2025 13:09, Dong Yibo wrote: > Complete the network device (netdev) registration flow for Mucse Gbe > Ethernet chips, including: > 1. Hardware state initialization: > - Send powerup notification to firmware (via echo_fw_status) > - Sync with firmware > - Reset hardware > 2. MAC address handling: > - Retrieve permanent MAC from firmware (via mucse_mbx_get_macaddr) > - Fallback to random valid MAC (eth_random_addr) if not valid mac > from Fw > > Signed-off-by: Dong Yibo [...] > +struct mucse_hw; why do you need this forward declaration ...> + > +struct mucse_hw_operations { > + int (*reset_hw)(struct mucse_hw *hw); > + int (*get_perm_mac)(struct mucse_hw *hw); > + int (*mbx_send_notify)(struct mucse_hw *hw, bool enable, int mode); > +}; > + > +enum { > + mucse_fw_powerup, > +}; > + > struct mucse_hw { > void __iomem *hw_addr; > + struct pci_dev *pdev; > + const struct mucse_hw_operations *ops; > + struct mucse_dma_info dma; > struct mucse_mbx_info mbx; > + int port; > + u8 perm_addr[ETH_ALEN]; > u8 pfvfnum; > }; ... if you can simply move mucse_hw_operations down here? > > @@ -54,4 +76,7 @@ int rnpgbe_init_hw(struct mucse_hw *hw, int board_type); > #define PCI_DEVICE_ID_N500_DUAL_PORT 0x8318 > #define PCI_DEVICE_ID_N210 0x8208 > #define PCI_DEVICE_ID_N210L 0x820a > + > +#define rnpgbe_dma_wr32(dma, reg, val) \ > + writel((val), (dma)->dma_base_addr + (reg)) [...] > @@ -48,8 +127,14 @@ static void rnpgbe_init_n210(struct mucse_hw *hw) > **/ > int rnpgbe_init_hw(struct mucse_hw *hw, int board_type) > { > + struct mucse_dma_info *dma = &hw->dma; > struct mucse_mbx_info *mbx = &hw->mbx; > > + hw->ops = &rnpgbe_hw_ops; > + hw->port = 0; > + > + dma->dma_base_addr = hw->hw_addr; not quite sure why do you need additional structure just to store the value that already exists in mucse_hw? > + > mbx->pf2fw_mbx_ctrl = MUCSE_GBE_PFFW_MBX_CTRL_OFFSET; > mbx->fwpf_mbx_mask = MUCSE_GBE_FWPF_MBX_MASK_OFFSET; >