| Message ID | 1624545405-37050-1-git-send-email-huangguangbin2@huawei.com |
|---|---|
| Headers | show |
| Series | net: hns3: add new debugfs commands | expand |
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.
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. > . > Ok, thanks.
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" "Remote fault" Do you think these fault information can be added to ethtool extended link states? Thanks, Guangbin .
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? > "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 > 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?
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.
> > > 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. If the user directly writes to PHY registers, they should expect bad things to happen. They can do a lot more than power the PHY down. They could configure it into loopback mode, turn off autoneg and force a mode which is compatible with the peer, etc. I don't think you need to tell the user they have pointed a foot gun at their feet and pulled the trigger. Andrew
On 2021/7/5 3:57, Andrew Lunn wrote: >>>> 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. > > If the user directly writes to PHY registers, they should expect bad > things to happen. They can do a lot more than power the PHY down. They > could configure it into loopback mode, turn off autoneg and force a > mode which is compatible with the peer, etc. > > I don't think you need to tell the user they have pointed a foot gun > at their feet and pulled the trigger. > > Andrew > . > OK, I accept your point, thanks!