From: Frank Li <Frank.li@oss.nxp.com>
To: Koichiro Den <den@valinux.co.jp>
Cc: "Manivannan Sadhasivam" <mani@kernel.org>,
"Frank Li" <Frank.Li@kernel.org>, "Jon Mason" <jdmason@kudzu.us>,
"Dave Jiang" <dave.jiang@intel.com>,
"Allen Hubbe" <allenbh@gmail.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
ntb@lists.linux.dev, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] PCI: endpoint: pci-epf-vntb: Track link state from both sides
Date: Tue, 13 Oct 2026 11:56:01 -0500 [thread overview]
Message-ID: <as5ioWuOWCqu7Us0@SMW015318> (raw)
In-Reply-To: <20260904162049.3432464-1-den@valinux.co.jp>
On Sat, Sep 05, 2026 at 01:20:49AM +0900, Koichiro Den wrote:
> The control-region link status is currently updated only by
> COMMAND_LINK_UP and COMMAND_LINK_DOWN from the HOST. The virtual
> NTB link callbacks are empty. Consequently, the HOST can see the link as
> up before the VHOST has enabled it, and ntb_link_disable() on the VHOST
> leaves LINK_STATUS_UP set without notifying either NTB client.
>
> ntb_netdev can hide this device-level state bug because ntb_transport uses
> a separate per-QP LINK_DOWN_FLAG message. Use ntb_tool to observe the
> device link state directly:
>
> After bringing both sides up, start one waiter on each side:
>
> HOST# echo N > /sys/kernel/debug/ntb_tool/<H-device>/peer0/link_event
> VHOST# echo N > /sys/kernel/debug/ntb_tool/<V-device>/peer0/link_event
>
> While both waiters are blocked, disable the link on the VHOST:
>
> VHOST# echo N > /sys/kernel/debug/ntb_tool/<V-device>/link
>
> Without this patch, the link-disable command succeeds, but peer0/link
> remains Y on both sides and neither waiter returns.
>
> Track HOST and VHOST enablement separately and report the effective link
> as up only when both sides have enabled it, as pci-epf-ntb does for its
> two physical hosts. Both NTB clients observe this effective state, so
> notify both sides only when it changes, including the side whose request
> completes the transition. Serialize the two paths because HOST commands
> run from delayed work while the VHOST callbacks may run concurrently.
>
> Order a link-status change caused by a HOST command before publishing
> command completion.
>
> With this patch, peer0/link changes to N on both sides and both waiters
> return.
>
> Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP")
> Signed-off-by: Koichiro Den <den@valinux.co.jp>
> ---
> Changes in v2:
> - Notify both NTB clients when the effective link state changes. (Sashiko)
> - Use devm_mutex_init(). (Frank)
> - Update the commit message + reproducer accordingly.
>
...
> /**
> - * epf_ntb_link_up() - Raise link_up interrupt to Virtual Host (VHOST)
> + * epf_ntb_link_up() - Update the HOST link state
> * @ntb: NTB device that facilitates communication between HOST and VHOST
> - * @link_up: true or false indicating Link is UP or Down
> - *
> - * Once NTB function in HOST invoke ntb_link_enable(),
> - * this NTB function driver will trigger a link event to VHOST.
> + * @link_up: true when the HOST has enabled the link
> *
> * Returns: Zero for success, or an error code in case of failure
> */
> static int epf_ntb_link_up(struct epf_ntb *ntb, bool link_up)
> {
> - if (link_up)
> - ntb->reg->link_status |= LINK_STATUS_UP;
> - else
> - ntb->reg->link_status &= ~LINK_STATUS_UP;
> + bool notify;
> +
> + scoped_guard(mutex, &ntb->link_lock) {
> + notify = ntb->host_linkup != link_up && ntb->vhost_linkup;
> + ntb->host_linkup = link_up;
> + epf_ntb_update_link(ntb);
> + }
> +
> + if (notify) {
> + /* Publish link status before completing the HOST command. */
> + dma_wmb();
why need dma_wmb() here? suppose there are writel() at
pci_epc_raise_irq(), or barrier should be inside pci_epc_raise_irq().
Frank
prev parent reply other threads:[~2026-10-13 16:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 16:20 [PATCH v2] PCI: endpoint: pci-epf-vntb: Track link state from both sides Koichiro Den
2026-09-04 16:33 ` sashiko-bot
2026-09-04 18:18 ` Koichiro Den
2026-10-13 14:26 ` Manivannan Sadhasivam
2026-10-13 14:30 ` Manivannan Sadhasivam
2026-10-13 16:56 ` Frank Li [this message]
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=as5ioWuOWCqu7Us0@SMW015318 \
--to=frank.li@oss.nxp.com \
--cc=Frank.Li@kernel.org \
--cc=allenbh@gmail.com \
--cc=bhelgaas@google.com \
--cc=dave.jiang@intel.com \
--cc=den@valinux.co.jp \
--cc=jdmason@kudzu.us \
--cc=kishon@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mani@kernel.org \
--cc=ntb@lists.linux.dev \
/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.