All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Dong Yibo <dong100@mucse.com>,
	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
Cc: netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH net-next v7 4/5] net: rnpgbe: Add basic mbx_fw support
Date: Mon, 25 Aug 2025 17:37:27 +0100	[thread overview]
Message-ID: <316f57e3-5953-4db6-84aa-df9278461d30@linux.dev> (raw)
In-Reply-To: <20250822023453.1910972-5-dong100@mucse.com>

On 22/08/2025 03:34, Dong Yibo wrote:

[...]
> +/**
> + * mucse_mbx_fw_post_req - Posts a mbx req to firmware and wait reply
> + * @hw: pointer to the HW structure
> + * @req: pointer to the cmd req structure
> + * @cookie: pointer to the req cookie
> + *
> + * mucse_mbx_fw_post_req posts a mbx req to firmware and wait for the
> + * reply. cookie->wait will be set in irq handler.
> + *
> + * @return: 0 on success, negative on failure
> + **/
> +static int mucse_mbx_fw_post_req(struct mucse_hw *hw,
> +				 struct mbx_fw_cmd_req *req,
> +				 struct mbx_req_cookie *cookie)
> +{
> +	int len = le16_to_cpu(req->datalen);
> +	int err;
> +
> +	cookie->errcode = 0;
> +	cookie->done = 0;
> +	init_waitqueue_head(&cookie->wait);
> +	err = mutex_lock_interruptible(&hw->mbx.lock);
> +	if (err)
> +		return err;
> +	err = mucse_write_mbx_pf(hw, (u32 *)req, len);
> +	if (err)
> +		goto out;
> +	/* if write succeeds, we must wait for firmware response or
> +	 * timeout to avoid using the already freed cookie->wait
> +	 */
> +	err = wait_event_timeout(cookie->wait,
> +				 cookie->done == 1,
> +				 cookie->timeout_jiffies);

it's unclear to me, what part of the code is managing values of cookie
structure? I didn't get the reason why are you putting the address of
cookie structure into request which is then directly passed to the FW.
Is the FW supposed to change values in cookie?

> +
> +	if (!err)
> +		err = -ETIMEDOUT;
> +	else
> +		err = 0;
> +	if (!err && cookie->errcode)
> +		err = cookie->errcode;
> +out:
> +	mutex_unlock(&hw->mbx.lock);
> +	return err;
> +}

[...]

> +struct mbx_fw_cmd_req {
> +	__le16 flags;
> +	__le16 opcode;
> +	__le16 datalen;
> +	__le16 ret_value;
> +	union {
> +		struct {
> +			__le32 cookie_lo;
> +			__le32 cookie_hi;
> +		};
> +
> +		void *cookie;
> +	};
> +	__le32 reply_lo;
> +	__le32 reply_hi;

what do these 2 fields mean? are you going to provide reply's buffer
address directly to FW?

> +	union {
> +		u8 data[32];
> +		struct {
> +			__le32 version;
> +			__le32 status;
> +		} ifinsmod;
> +		struct {
> +			__le32 port_mask;
> +			__le32 pfvf_num;
> +		} get_mac_addr;
> +	};
> +} __packed;
> +
> +struct mbx_fw_cmd_reply {
> +	__le16 flags;
> +	__le16 opcode;
> +	__le16 error_code;
> +	__le16 datalen;
> +	union {
> +		struct {
> +			__le32 cookie_lo;
> +			__le32 cookie_hi;
> +		};
> +		void *cookie;
> +	};

This part looks like the request, apart from datalen and error_code are
swapped in the header. And it actually means that the FW will put back
the address of provided cookie into reply, right? If yes, then it
doesn't look correct at all...

> +	union {
> +		u8 data[40];
> +		struct mac_addr {
> +			__le32 ports;
> +			struct _addr {
> +				/* for macaddr:01:02:03:04:05:06
> +				 * mac-hi=0x01020304 mac-lo=0x05060000
> +				 */
> +				u8 mac[8];
> +			} addrs[4];
> +		} mac_addr;
> +		struct hw_abilities hw_abilities;
> +	};
> +} __packed;

  parent reply	other threads:[~2025-08-25 16:37 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-22  2:34 [PATCH net-next v7 0/5] Add driver for 1Gbe network chips from MUCSE Dong Yibo
2025-08-22  2:34 ` [PATCH net-next v7 1/5] net: rnpgbe: Add build support for rnpgbe Dong Yibo
2025-08-22  4:32   ` Parthiban.Veerasooran
2025-08-22  5:23     ` Yibo Dong
2025-08-22  2:34 ` [PATCH net-next v7 2/5] net: rnpgbe: Add n500/n210 chip support Dong Yibo
2025-08-22  2:34 ` [PATCH net-next v7 3/5] net: rnpgbe: Add basic mbx ops support Dong Yibo
2025-08-22  4:41   ` Parthiban.Veerasooran
2025-08-22  5:25     ` Yibo Dong
2025-08-22  2:34 ` [PATCH net-next v7 4/5] net: rnpgbe: Add basic mbx_fw support Dong Yibo
2025-08-22  4:49   ` Parthiban.Veerasooran
2025-08-22  5:37     ` Yibo Dong
2025-08-22  6:07       ` Parthiban.Veerasooran
2025-08-22  6:51         ` Yibo Dong
2025-08-22  8:05           ` Parthiban.Veerasooran
2025-08-22  9:04             ` Yibo Dong
2025-08-22 14:33           ` Andrew Lunn
2025-08-23  2:03             ` Yibo Dong
2025-08-22 14:43   ` Andrew Lunn
2025-08-23  1:58     ` Yibo Dong
2025-08-23 15:17       ` Andrew Lunn
2025-08-24  4:10         ` Yibo Dong
2025-08-24 15:15           ` Andrew Lunn
2025-08-25  1:30             ` Yibo Dong
2025-08-23 15:02   ` Vadim Fedorenko
2025-08-24  3:46     ` Yibo Dong
2025-08-25 16:37   ` Vadim Fedorenko [this message]
2025-08-26  1:31     ` Yibo Dong
2025-08-26 10:14       ` Vadim Fedorenko
2025-08-26 11:05         ` Yibo Dong
2025-08-26 12:39           ` Andrew Lunn
2025-08-27  1:42             ` Yibo Dong
2025-08-27 19:54               ` Andrew Lunn
2025-08-28  2:02                 ` Yibo Dong
2025-08-22  2:34 ` [PATCH net-next v7 5/5] net: rnpgbe: Add register_netdev Dong Yibo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=316f57e3-5953-4db6-84aa-df9278461d30@linux.dev \
    --to=vadim.fedorenko@linux.dev \
    --cc=Parthiban.Veerasooran@microchip.com \
    --cc=alexanderduyck@fb.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=corbet@lwn.net \
    --cc=danishanwar@ti.com \
    --cc=davem@davemloft.net \
    --cc=dong100@mucse.com \
    --cc=edumazet@google.com \
    --cc=geert+renesas@glider.be \
    --cc=gongfan1@huawei.com \
    --cc=gur.stavi@huawei.com \
    --cc=gustavoars@kernel.org \
    --cc=horms@kernel.org \
    --cc=kees@kernel.org \
    --cc=kuba@kernel.org \
    --cc=lee@trager.us \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=lukas.bulwahn@redhat.com \
    --cc=maddy@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=richardcochran@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.