linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Fan Gong <gongfan1@huawei.com>
Cc: Zhu Yikai <zhuyikai1@h-partners.com>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	Andrew Lunn <andrew+netdev@lunn.ch>, <linux-doc@vger.kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Bjorn Helgaas <helgaas@kernel.org>, luosifu <luosifu@huawei.com>,
	Xin Guo <guoxin09@huawei.com>,
	Shen Chenyang <shenchenyang1@hisilicon.com>,
	Zhou Shuai <zhoushuai28@huawei.com>, Wu Like <wulike1@huawei.com>,
	Shi Jing <shijing34@huawei.com>,
	Fu Guiming <fuguiming@h-partners.com>,
	Meny Yossefi <meny.yossefi@huawei.com>,
	Gur Stavi <gur.stavi@huawei.com>, Lee Trager <lee@trager.us>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	Suman Ghosh <sumang@marvell.com>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	Joe Damato <jdamato@fastly.com>,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Subject: Re: [PATCH net-next v09 1/8] hinic3: Async Event Queue interfaces
Date: Wed, 16 Jul 2025 18:32:08 -0700	[thread overview]
Message-ID: <20250716183208.26b87aa8@kernel.org> (raw)
In-Reply-To: <7666dc6771ef43bf97f1cfabfb50c97ccea31d9d.1752489734.git.zhuyikai1@h-partners.com>

On Tue, 15 Jul 2025 08:28:36 +0800 Fan Gong wrote:
> +/* Data provided to/by cmdq is arranged in structs with little endian fields but
> + * every dword (32bits) should be swapped since HW swaps it again when it
> + * copies it from/to host memory. This is a mandatory swap regardless of the
> + * CPU endianness.

This comment makes no sense, FWIW. The device writes a byte steam 
to host memory. For what you're saying to make sense the device would
have to intentionally switch the endian based on the host CPU.
And if it could do that why wouldn't it do it in the opposite
direction, avoiding the swap ? :/

I suppose the device is always writing in be32 words, and you should 
be converting from be32.

> +	/* Ensure handler can observe our intent to unregister. */
> +	mb();

What is "our intent"? I suppose you mean the change to the cb_state
bitfield? Please document the barriers explaining what two (or more)
memory accesses are separated. Not what they are achieving at the high
level.

> +	clear_bit(HINIC3_AEQ_CB_REG, cb_state);
> +	/* Ensure handler can observe our intent to unregister. */
> +	mb();
> +	while (test_bit(HINIC3_AEQ_CB_RUNNING, cb_state))
> +		usleep_range(HINIC3_EQ_USLEEP_LOW_BOUND,
> +			     HINIC3_EQ_USLEEP_HIGH_BOUND);

Please do not try to implement locks manually using bits ops.
Use standard synchronization primitives like wait queues or normal
locks, so that lockdep can help you validate your code is correct.

> +	val = EQ_CI_SIMPLE_INDIR_SET(arm_state, ARMED);
> +	val = val |
> +		EQ_CI_SIMPLE_INDIR_SET(eq_wrap_ci, CI) |
> +		EQ_CI_SIMPLE_INDIR_SET(eq->q_id, AEQ_IDX);

Why not:

	val = EQ_CI_SIMPLE_INDIR_SET(arm_state, ARMED) |
		EQ_CI_SIMPLE_INDIR_SET(eq_wrap_ci, CI) |
		EQ_CI_SIMPLE_INDIR_SET(eq->q_id, AEQ_IDX);
-- 
pw-bot: cr

  reply	other threads:[~2025-07-17  1:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-15  0:28 [PATCH net-next v09 0/8] net: hinic3: Add a driver for Huawei 3rd gen NIC - management interfaces Fan Gong
2025-07-15  0:28 ` [PATCH net-next v09 1/8] hinic3: Async Event Queue interfaces Fan Gong
2025-07-17  1:32   ` Jakub Kicinski [this message]
2025-07-17  8:02     ` Gur Stavi
2025-07-17 23:40       ` Jakub Kicinski
2025-07-15  0:28 ` [PATCH net-next v09 2/8] hinic3: Complete " Fan Gong
2025-07-15  0:28 ` [PATCH net-next v09 3/8] hinic3: Command Queue framework Fan Gong
2025-07-15  0:28 ` [PATCH net-next v09 4/8] hinic3: Command Queue interfaces Fan Gong
2025-07-15  0:28 ` [PATCH net-next v09 5/8] hinic3: TX & RX Queue coalesce interfaces Fan Gong
2025-07-15  0:28 ` [PATCH net-next v09 6/8] hinic3: Mailbox framework Fan Gong
2025-07-15  0:28 ` [PATCH net-next v09 7/8] hinic3: Mailbox management interfaces Fan Gong
2025-07-15  0:28 ` [PATCH net-next v09 8/8] hinic3: Interrupt request configuration Fan Gong

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=20250716183208.26b87aa8@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fuguiming@h-partners.com \
    --cc=gongfan1@huawei.com \
    --cc=guoxin09@huawei.com \
    --cc=gur.stavi@huawei.com \
    --cc=helgaas@kernel.org \
    --cc=horms@kernel.org \
    --cc=jdamato@fastly.com \
    --cc=lee@trager.us \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luosifu@huawei.com \
    --cc=meny.yossefi@huawei.com \
    --cc=mpe@ellerman.id.au \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=shenchenyang1@hisilicon.com \
    --cc=shijing34@huawei.com \
    --cc=sumang@marvell.com \
    --cc=vadim.fedorenko@linux.dev \
    --cc=wulike1@huawei.com \
    --cc=zhoushuai28@huawei.com \
    --cc=zhuyikai1@h-partners.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).