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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ