All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: ernis@linux.microsoft.com
Cc: Jakub Kicinski <kuba@kernel.org>,
	pabeni@redhat.com, linux-kernel@vger.kernel.org,
	yury.norov@gmail.com, kys@microsoft.com, decui@microsoft.com,
	kees@kernel.org, longli@microsoft.com,
	dipayanroy@linux.microsoft.com, davem@davemloft.net,
	netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
	kotaranov@microsoft.com, andrew+netdev@lunn.ch,
	linux-hyperv@vger.kernel.org, edumazet@google.com,
	haiyangz@microsoft.com, ssengar@linux.microsoft.com,
	shradhagupta@linux.microsoft.com, horms@kernel.org,
	shirazsaleem@microsoft.com, wei.liu@kernel.org
Subject: Re: [net-next] net: mana: Expose hardware diagnostic info via debugfs
Date: Fri,  6 Mar 2026 19:22:28 -0800	[thread overview]
Message-ID: <20260307032228.1379456-1-kuba@kernel.org> (raw)
In-Reply-To: <20260305205252.470089-1-ernis@linux.microsoft.com>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: mana: Expose hardware diagnostic info via debugfs

This commit adds debugfs entries to expose hardware configuration and
diagnostic information for the MANA driver. It creates device-level and
port-level debugfs entries to aid in debugging initialization and runtime
operations.

> diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> index aef8612b73cb..fb513d7802cb 100644
> --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
> +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> @@ -152,6 +152,11 @@ static int mana_gd_query_max_resources(struct pci_dev *pdev)
>  	if (gc->max_num_queues > gc->num_msix_usable - 1)
>  		gc->max_num_queues = gc->num_msix_usable - 1;
>
> +	debugfs_create_u32("num_msix_usable", 0400, gc->mana_pci_debugfs,
> +			   &gc->num_msix_usable);
> +	debugfs_create_u32("max_num_queues", 0400, gc->mana_pci_debugfs,
> +			   &gc->max_num_queues);
> +
>  	return 0;
>  }
>
> @@ -1222,6 +1227,13 @@ int mana_gd_verify_vf_version(struct pci_dev *pdev)
>  		return err ? err : -EPROTO;
>  	}
>  	gc->pf_cap_flags1 = resp.pf_cap_flags1;
> +	gc->gdma_protocol_ver = resp.gdma_protocol_ver;
> +
> +	debugfs_create_x64("gdma_protocol_ver", 0400, gc->mana_pci_debugfs,
> +			   &gc->gdma_protocol_ver);
> +	debugfs_create_x64("pf_cap_flags1", 0400, gc->mana_pci_debugfs,
> +			   &gc->pf_cap_flags1);
> +

Do these debugfs entries get recreated on every suspend/resume cycle?

Both mana_gd_query_max_resources() and mana_gd_verify_vf_version() are
called from mana_gd_setup() during device initialization. On suspend,
mana_gd_suspend() calls mana_gd_cleanup() which doesn't remove these
debugfs entries. When mana_gd_resume() calls mana_gd_setup() again, it
attempts to create the same debugfs entries a second time.

This means debugfs_start_creating() in fs/debugfs/inode.c will print an
error for each duplicate file:

    "'num_msix_usable' already exists in 'mana/<slot>/'"
    "'max_num_queues' already exists in 'mana/<slot>/'"
    "'gdma_protocol_ver' already exists in 'mana/<slot>/'"
    "'pf_cap_flags1' already exists in 'mana/<slot>/'"

This produces 4 error messages in dmesg on every suspend/resume cycle,
contradicting the commit message's goal of operating "without adding
noise to dmesg."

Should these device-level entries be removed during suspend (in
mana_gd_cleanup or mana_gd_suspend), or should their creation be moved
to mana_gd_probe where they're only created once?

[ ... ]
-- 
pw-bot: cr

  reply	other threads:[~2026-03-07  3:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-05 20:52 [PATCH net-next] net: mana: Expose hardware diagnostic info via debugfs Erni Sri Satya Vennela
2026-03-07  3:22 ` Jakub Kicinski [this message]
2026-03-09 11:49   ` [net-next] " 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=20260307032228.1379456-1-kuba@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=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 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.