[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d46abe01-2f1d-42ec-ab93-a0be3d431c09@linux.dev>
Date: Wed, 22 Oct 2025 12:07:59 +0100
From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
To: Dong Yibo <dong100@...se.com>, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, horms@...nel.org, corbet@....net,
andrew+netdev@...n.ch, danishanwar@...com, geert+renesas@...der.be,
mpe@...erman.id.au, lorenzo@...nel.org, lukas.bulwahn@...hat.com
Cc: netdev@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v15 4/5] net: rnpgbe: Add basic mbx_fw support
On 22/10/2025 09:13, Dong Yibo wrote:
> Add fundamental firmware (FW) communication operations via PF-FW
> mailbox, including:
> - FW sync (via HW info query with retries)
> - HW reset (post FW command to reset hardware)
> - MAC address retrieval (request FW for port-specific MAC)
> - Power management (powerup/powerdown notification to FW)
>
> Signed-off-by: Dong Yibo <dong100@...se.com>
> ---
> drivers/net/ethernet/mucse/rnpgbe/Makefile | 3 +-
> drivers/net/ethernet/mucse/rnpgbe/rnpgbe.h | 4 +
> .../net/ethernet/mucse/rnpgbe/rnpgbe_mbx.c | 1 +
> .../net/ethernet/mucse/rnpgbe/rnpgbe_mbx_fw.c | 194 ++++++++++++++++++
> .../net/ethernet/mucse/rnpgbe/rnpgbe_mbx_fw.h | 88 ++++++++
> 5 files changed, 289 insertions(+), 1 deletion(-)
> create mode 100644 drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx_fw.c
> create mode 100644 drivers/net/ethernet/mucse/rnpgbe/rnpgbe_mbx_fw.h
[...]
> +static int mucse_mbx_get_info(struct mucse_hw *hw)
> +{
> + struct mbx_fw_cmd_req req = {
> + .datalen = cpu_to_le16(MUCSE_MBX_REQ_HDR_LEN),
> + .opcode = cpu_to_le16(GET_HW_INFO),
> + };
> + struct mbx_fw_cmd_reply reply = {};
> + struct mucse_hw_info info = {};
> + int err;
> +
> + err = mucse_fw_send_cmd_wait_resp(hw, &req, &reply);
> + if (!err) {
> + memcpy(&info, &reply.hw_info, sizeof(struct mucse_hw_info));
> + hw->pfvfnum = FIELD_GET(GENMASK_U16(7, 0),
> + le16_to_cpu(info.pfnum));
why do you need local struct mucse_hw_info info? The reply is stack
allocated, nothing else will use it afterwards. You clear out
info on allocation (40 bytes memset), then you copy whole structure from
reply to info (another round of 40 bytes reads/writes) and then use only
2 bytes out of it - it does look like an overkill, you can access
reply.hwinfo.pfnum directly.
Powered by blists - more mailing lists