From: Jakub Kicinski <kuba@kernel.org>
To: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, longli@microsoft.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
kotaranov@microsoft.com, horms@kernel.org,
shradhagupta@linux.microsoft.com, shirazsaleem@microsoft.com,
dipayanroy@linux.microsoft.com, yury.norov@gmail.com,
kees@kernel.org, ssengar@linux.microsoft.com,
gargaditya@linux.microsoft.com, linux-hyperv@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rdma@vger.kernel.org
Subject: Re: [PATCH net-next v4] net: mana: Expose hardware diagnostic info via debugfs
Date: Mon, 23 Mar 2026 17:44:44 -0700 [thread overview]
Message-ID: <20260323174444.2717da3d@kernel.org> (raw)
In-Reply-To: <20260319070926.1459515-1-ernis@linux.microsoft.com>
On Thu, 19 Mar 2026 00:09:13 -0700 Erni Sri Satya Vennela wrote:
> Add debugfs entries to expose hardware configuration and diagnostic
> information that aids in debugging driver initialization and runtime
> operations without adding noise to dmesg.
>
> The debugfs directory creation and removal for each PCI device is
> integrated into mana_gd_setup() and mana_gd_cleanup_device()
> respectively, so that all callers (probe, remove, suspend, resume,
> shutdown) share a single code path.
>
> Device-level entries (under /sys/kernel/debug/mana/<slot>/):
> - num_msix_usable, max_num_queues: Max resources from hardware
> - gdma_protocol_ver, pf_cap_flags1: VF version negotiation results
> - num_vports, bm_hostmode: Device configuration
>
> Per-vPort entries (under /sys/kernel/debug/mana/<slot>/vportN/):
> - port_handle: Hardware vPort handle
> - max_sq, max_rq: Max queues from vPort config
> - indir_table_sz: Indirection table size
> - steer_rx, steer_rss, steer_update_tab, steer_cqe_coalescing:
> Last applied steering configuration parameters
AI says:
> @@ -1918,15 +1930,23 @@ static int mana_gd_setup(struct pci_dev *pdev)
> struct gdma_context *gc = pci_get_drvdata(pdev);
> int err;
>
> + if (gc->is_pf)
> + gc->mana_pci_debugfs = debugfs_create_dir("0", mana_debugfs_root);
> + else
> + gc->mana_pci_debugfs = debugfs_create_dir(pci_slot_name(pdev->slot),
> + mana_debugfs_root);
If pdev->slot is NULL (which can happen for VFs in environments like generic
VFIO passthrough or nested KVM), will pci_slot_name(pdev->slot) cause a
NULL pointer dereference?
Also, could this naming scheme cause name collisions? If multiple PFs are
present, they would all try to use "0". Similarly, VFs across different
PCI domains or buses might share the same physical slot identifier, leading
to -EEXIST errors. Would it be safer to use the unique PCI BDF via
pci_name(pdev) instead?
> @@ -3141,6 +3149,24 @@ static int mana_init_port(struct net_device *ndev)
> eth_hw_addr_set(ndev, apc->mac_addr);
> sprintf(vport, "vport%d", port_idx);
> apc->mana_port_debugfs = debugfs_create_dir(vport, gc->mana_pci_debugfs);
> +
> + debugfs_create_u64("port_handle", 0400, apc->mana_port_debugfs,
> + &apc->port_handle);
When operations like changing the MTU or setting an XDP program trigger a
detach/attach cycle, mana_detach() invokes mana_cleanup_port_context(),
which recursively removes the apc->mana_port_debugfs directory.
During re-attachment, mana_attach() calls mana_init_port(), which
recreates the directory and the new files added in this patch. However, the
pre-existing current_speed file (created in mana_probe_port()) is not
recreated here.
Does this cause the current_speed file to be permanently lost after a
detach/attach cycle? Should the creation of current_speed be moved to
mana_init_port() so it survives the cycle?
--
pw-bot: cr
next prev parent reply other threads:[~2026-03-24 0:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 7:09 [PATCH net-next v4] net: mana: Expose hardware diagnostic info via debugfs Erni Sri Satya Vennela
2026-03-20 9:55 ` Simon Horman
2026-03-24 0:44 ` Jakub Kicinski [this message]
2026-03-24 16:20 ` Erni Sri Satya Vennela
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=20260323174444.2717da3d@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=dipayanroy@linux.microsoft.com \
--cc=edumazet@google.com \
--cc=ernis@linux.microsoft.com \
--cc=gargaditya@linux.microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=horms@kernel.org \
--cc=kees@kernel.org \
--cc=kotaranov@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shirazsaleem@microsoft.com \
--cc=shradhagupta@linux.microsoft.com \
--cc=ssengar@linux.microsoft.com \
--cc=wei.liu@kernel.org \
--cc=yury.norov@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox