linux-kernel - Re: [PATCH net-next 3/3] net: hns3: add support for link diagnosis info in debugfs

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:   Sun, 4 Jul 2021 09:37:45 +0800
From:   "huangguangbin (A)" <huangguangbin2@...wei.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     <davem@...emloft.net>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <salil.mehta@...wei.com>,
        <lipeng321@...wei.com>
Subject: Re: [PATCH net-next 3/3] net: hns3: add support for link diagnosis
 info in debugfs



On 2021/7/1 23:54, Jakub Kicinski wrote:
> On Thu, 1 Jul 2021 17:03:32 +0800 huangguangbin (A) wrote:
>> On 2021/6/25 3:25, Jakub Kicinski wrote:
>>> On Thu, 24 Jun 2021 22:36:45 +0800 Guangbin Huang wrote:
>>>> In order to know reason why link down, add a debugfs file
>>>> "link_diagnosis_info" to get link faults from firmware, and each bit
>>>> represents one kind of fault.
>>>>
>>>> usage example:
>>>> $ cat link_diagnosis_info
>>>> Reference clock lost
>>>
>>> Please use ethtool->get_link_ext_state instead.
>>> .
>>>    
>> Hi Jakub, I have a question to consult you.
>> Some fault information in our patch are not existed in current ethtool extended
>> link states, for examples:
>> "Serdes reference clock lost"
>> "Serdes analog loss of signal"
>> "SFP tx is disabled"
>> "PHY power down"
> 
> Why would the PHY be powered down if user requested port to be up?
> 
In the case of other user may use MDIO tool to write PHY register directly to make
PHY power down, if link state can display this information, I think it is helpful.

>> "Remote fault"
> 
> I think we do have remote fault:
> 
>      state: ETHTOOL_LINK_EXT_STATE_LINK_TRAINING_FAILURE
>   substate: ETHTOOL_LINK_EXT_SUBSTATE_LT_REMOTE_FAULT
> 
OK.

>> Do you think these fault information can be added to ethtool extended link states?
> 
> Yes, would you mind categorizing them into state/substate and sharing
> the proposed additions with Amit, Ido, Andrew and other PHY experts?
> .
> 
OK.