netdev - Re: [PATCH net-next 5/5] ice: Print human-friendly PHY types

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20220830145414.3a2ba804@kernel.org>
Date:   Tue, 30 Aug 2022 14:54:14 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Jesse Brandeburg <jesse.brandeburg@...el.com>
Cc:     Tony Nguyen <anthony.l.nguyen@...el.com>, <davem@...emloft.net>,
        <pabeni@...hat.com>, <edumazet@...gle.com>,
        "Anirudh Venkataramanan" <anirudh.venkataramanan@...el.com>,
        <netdev@...r.kernel.org>,
        Lukasz Plachno <lukasz.plachno@...el.com>,
        Alexander Lobakin <alexandr.lobakin@...el.com>,
        Gurucharan <gurucharanx.g@...el.com>
Subject: Re: [PATCH net-next 5/5] ice: Print human-friendly PHY types

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.