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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 30 Aug 2022 11:33:07 -0700
From:   Jesse Brandeburg <jesse.brandeburg@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Tony Nguyen <anthony.l.nguyen@...el.com>
CC:     <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 8/25/2022 8:03 PM, Jakub Kicinski wrote:
>> New:
>> [ 1128.297347] ice 0000:16:00.0: get phy caps dump
>> [ 1128.297351] ice 0000:16:00.0: phy_caps_active: phy_type_low: 0x0108021020502000
>> [ 1128.297355] ice 0000:16:00.0: phy_caps_active:   bit(13): 10G_SFI_DA
>> [ 1128.297359] ice 0000:16:00.0: phy_caps_active:   bit(20): 25GBASE_CR
>> [ 1128.297362] ice 0000:16:00.0: phy_caps_active:   bit(22): 25GBASE_CR1
>> [ 1128.297365] ice 0000:16:00.0: phy_caps_active:   bit(29): 25G_AUI_C2C
>> [ 1128.297368] ice 0000:16:00.0: phy_caps_active:   bit(36): 50GBASE_CR2
>> [ 1128.297371] ice 0000:16:00.0: phy_caps_active:   bit(41): 50G_LAUI2
>> [ 1128.297374] ice 0000:16:00.0: phy_caps_active:   bit(51): 100GBASE_CR4
>> [ 1128.297377] ice 0000:16:00.0: phy_caps_active:   bit(56): 100G_CAUI4
>> [ 1128.297380] ice 0000:16:00.0: phy_caps_active: phy_type_high: 0x0000000000000000
>> [ 1128.297383] ice 0000:16:00.0: phy_caps_active: report_mode = 0x4
>> [ 1128.297386] ice 0000:16:00.0: phy_caps_active: caps = 0xc8
>> [ 1128.297389] ice 0000:16:00.0: phy_caps_active: low_power_ctrl_an = 0x4
>> [ 1128.297392] ice 0000:16:00.0: phy_caps_active: eee_cap = 0x0
>> [ 1128.297394] ice 0000:16:00.0: phy_caps_active: eeer_value = 0x0
>> [ 1128.297397] ice 0000:16:00.0: phy_caps_active: link_fec_options = 0xdf
>> [ 1128.297400] ice 0000:16:00.0: phy_caps_active: module_compliance_enforcement = 0x0
>> [ 1128.297402] ice 0000:16:00.0: phy_caps_active: extended_compliance_code = 0xb
>> [ 1128.297405] ice 0000:16:00.0: phy_caps_active: module_type[0] = 0x11
>> [ 1128.297408] ice 0000:16:00.0: phy_caps_active: module_type[1] = 0x1
>> [ 1128.297411] ice 0000:16:00.0: phy_caps_active: module_type[2] = 0x0
> 
> 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.

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?