From: Jakub Kicinski <kuba@kernel.org>
To: Michael Chan <michael.chan@broadcom.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
pabeni@redhat.com, andrew+netdev@lunn.ch,
pavan.chebbi@broadcom.com, andrew.gospodarek@broadcom.com,
Ajit Khaparde <ajit.khaparde@broadcom.com>,
Kalesh AP <kalesh-anakkur.purayil@broadcom.com>,
Somnath Kotur <somnath.kotur@broadcom.com>
Subject: Re: [PATCH net-next v2 5/6] bnxt_en: Skip reading PXP registers during ethtool -d if unsupported
Date: Thu, 19 Dec 2024 06:59:53 -0800 [thread overview]
Message-ID: <20241219065953.73e08f77@kernel.org> (raw)
In-Reply-To: <CACKFLimq7juLHbEs9gbuzRm7mFGvD62RsgrXdxr-fmj5e+zBbw@mail.gmail.com>
On Wed, 18 Dec 2024 22:57:09 -0800 Michael Chan wrote:
> > On Tue, 17 Dec 2024 10:26:19 -0800 Michael Chan wrote:
> > > Newer firmware does not allow reading the PXP registers during
> > > ethtool -d, so skip the firmware call in that case. Userspace
> > > (bnxt.c) always expects the register block to be populated so
> > > zeroes will be returned instead.
> >
> > We have both the ability to return the number of registers (regs_len),
> > and the regs->version. Are you sure you don't want to use either option
> > to let user space know the regs aren't there?
>
> The existing bnxt.c in userspace since 2020 always assumes that the
> beginning part always contains the PXP register block regardless of
> regs->version as long as the register length >= the length of the
> register block. I guess we didn't anticipate that this PXP block
> would ever be changed or FW would disallow reading it.
So if you bumped the version the existing userspace wouldn't care but
then you _could_ follow up and update user space to ignore these
registers when version is 1?
It's alright, it's just debug, I got curious recently about how little
use the version field gets. I'm not sure anyone has a good idea on
what to do with it.
next prev parent reply other threads:[~2024-12-19 14:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-17 18:26 [PATCH net-next v2 0/6] bnxt_en: Driver update Michael Chan
2024-12-17 18:26 ` [PATCH net-next v2 1/6] bnxt_en: Use FW defined resource limits for RoCE Michael Chan
2024-12-17 18:26 ` [PATCH net-next v2 2/6] bnxt_en: Do not allow ethtool -m on an untrusted VF Michael Chan
2024-12-17 18:26 ` [PATCH net-next v2 3/6] bnxt_en: Skip PHY loopback ethtool selftest if unsupported by FW Michael Chan
2024-12-17 18:26 ` [PATCH net-next v2 4/6] bnxt_en: Skip MAC loopback selftest if it is " Michael Chan
2024-12-18 8:44 ` Michal Swiatkowski
2024-12-17 18:26 ` [PATCH net-next v2 5/6] bnxt_en: Skip reading PXP registers during ethtool -d if unsupported Michael Chan
2024-12-19 3:13 ` Jakub Kicinski
2024-12-19 6:57 ` Michael Chan
2024-12-19 14:59 ` Jakub Kicinski [this message]
2024-12-19 17:53 ` Michael Chan
2024-12-19 19:18 ` Michael Chan
2024-12-17 18:26 ` [PATCH net-next v2 6/6] MAINTAINERS: bnxt_en: Add Pavan Chebbi as co-maintainer Michael Chan
2024-12-20 2:20 ` [PATCH net-next v2 0/6] bnxt_en: Driver update patchwork-bot+netdevbpf
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=20241219065953.73e08f77@kernel.org \
--to=kuba@kernel.org \
--cc=ajit.khaparde@broadcom.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew.gospodarek@broadcom.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kalesh-anakkur.purayil@broadcom.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=somnath.kotur@broadcom.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.