> On Thu, Jun 22, 2017 at 11:09:04AM +0300, Gal Pressman wrote:
>>>> +enum {
>>>> + ETHTOOL_LINK_VENDOR_SPECIFIC = -1, /* Vendor specific issue provided in
>>>> vendor_reason */
>>>> + ETHTOOL_LINK_NO_ISSUE, /* No issue observed with link */
>>>> + ETHTOOL_LINK_REASON_UNKNOWN, /* Unknown reason */
>>> I think OTHER would be better that UNKNOWN.
>> Fine with me.
>>>> + ETHTOOL_LINK_NETDEV_CARRIER_DOWN, /* Netdev carrier is down */
>>>> + ETHTOOL_LINK_ADMIN_DOWN, /* Admin down */
>>> These two are interesting. We have that information already. Why do we
>>> want it again?
>> My goal is to gather all link issue reasons in one place.
> I'm actually wondering if this is a user space problem. Nearly
> everything you list is already available. Some you get from ip link,
> others from ethtool or ethtool --module-info, including I2C bus
> error, since you would expect EIO or ETIMEOUT.
>
> If you were to write a user space tool using the information what is
> currently available, what would be missing?
>
> Andrew
I think most of the reasons in this list would be missing.
Auto negotiation failure, link training failure, remote fault indication, bad
signal integrity, cable protocol mismatch, cable unplugged,
over temperature, power budget exceeded..
Keep in mind that this is just an initial list, not to mention the vendor
reasons which are not part of any existing API.
I don't see how a user space tool that expects ETIMEOUT/EIO is better than this
suggestion.
