netdev - Re: [PATCH net-next v15 4/5] net: rnpgbe: Add basic mbx

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3CA6D21491D51426+20251022112100.GA61682@nic-Precision-5820-Tower>
Date: Wed, 22 Oct 2025 19:21:00 +0800
From: Yibo Dong <dong100@...se.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Cc: 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,
	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 Wed, Oct 22, 2025 at 12:07:59PM +0100, Vadim Fedorenko wrote:
> 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.
> 

mm, you are right, I should access it directly. Thanks. 

> 
>