On Sun, Jun 25, 2017 at 02:59:24PM +0300, Gal Pressman wrote:
>
> > 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,
You can probably get that from the PHY layer. You get both the local
and remote AN capabilities.
> unplugged, over temperature, power budget exceeded..
Don't you get over temperature from the SFF data? Also power budget?
And what does cable unplugged actually mean? Do you have a micro
switch inside the socket? So that is maybe a gpio-key?
Another thing to remember is that your device is the exception to the
rule. You have some firmware doing a lot of the work bringing this all
together. But nearly every other Ethernet interface has a discrete MAC
and PHY, I2C bus driver, EEPROM driver, generic SFF decoder, HWMON
temperature sensor, etc. How does your call work in this normal
situation? How do you make calls into all these subsystems to get the
information? You want a generic solution which can be made to work for
everybody.
Andrew
>
> 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.
