From: Jakub Kicinski <kuba@kernel.org>
To: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>, <davem@davemloft.net>,
<pabeni@redhat.com>, <edumazet@google.com>,
"Anirudh Venkataramanan" <anirudh.venkataramanan@intel.com>,
<netdev@vger.kernel.org>,
Lukasz Plachno <lukasz.plachno@intel.com>,
Alexander Lobakin <alexandr.lobakin@intel.com>,
Gurucharan <gurucharanx.g@intel.com>
Subject: Re: [PATCH net-next 5/5] ice: Print human-friendly PHY types
Date: Tue, 30 Aug 2022 14:54:14 -0700 [thread overview]
Message-ID: <20220830145414.3a2ba804@kernel.org> (raw)
In-Reply-To: <3b248522-3193-cd31-3452-78e02b95c369@intel.com>
On Tue, 30 Aug 2022 11:33:07 -0700 Jesse Brandeburg wrote:
> > Is this not something that can be read via ethtool -m ?
>
> Hi Jakub, I saw Dave committed this, but I wanted to answer.
>
> AFAIK ethtool -m just dumps the eeprom in a hexdump. This data is part
> of a firmware response about "all the things" that it knows about the
> current link and PHY/cable.
ethtool -m decodes the information into text format. Perhaps it doesn't
understand the EEPROM layout for the SFP type you're checking?
I'd be surprised but it's possible.
Obviously PHY stuff outside the SFP would not be reported there, but
most of the prints look like module info.
> these *debug* prints extra information on the phy that the driver gets
> in one call, but is not clearly mapped today to a single ethtool command.
>
> Would this be a good candidate for debugfs (read only) file for our
> driver, or should we just leave it as dev_dbg() output?
The prints themselves are not a big deal, but it'd be great if the info
which is available via ethtool -m was stripped. Just to move to
"standard APIs" wherever possible, it's not a big deal.
next prev parent reply other threads:[~2022-08-30 21:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-24 17:03 [PATCH net-next 0/5][pull request] Intel Wired LAN Driver Updates 2022-08-24 (ice) Tony Nguyen
2022-08-24 17:03 ` [PATCH net-next 1/5] ice: Add support for ip TTL & ToS offload Tony Nguyen
2022-08-24 17:03 ` [PATCH net-next 2/5] ice: Add port option admin queue commands Tony Nguyen
2022-08-24 17:03 ` [PATCH net-next 3/5] ice: Add additional flags to ice_nvm_write_activate Tony Nguyen
2022-08-24 17:03 ` [PATCH net-next 4/5] ice: Implement devlink port split operations Tony Nguyen
2022-08-24 17:03 ` [PATCH net-next 5/5] ice: Print human-friendly PHY types Tony Nguyen
2022-08-26 3:03 ` Jakub Kicinski
2022-08-30 18:33 ` Jesse Brandeburg
2022-08-30 21:54 ` Jakub Kicinski [this message]
2022-08-26 10:50 ` [PATCH net-next 0/5][pull request] Intel Wired LAN Driver Updates 2022-08-24 (ice) 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=20220830145414.3a2ba804@kernel.org \
--to=kuba@kernel.org \
--cc=alexandr.lobakin@intel.com \
--cc=anirudh.venkataramanan@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gurucharanx.g@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=lukasz.plachno@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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).