On Thu, 22 Jun 2017 14:37:26 +0300, Gal Pressman wrote:
> > Any particular reason for implementing this ABI in ethtool rather than
> > via some netlink-based interface? Devlink naturally comes to mind,
> > given that cabling problems are not really related to the L2 and netdev
> > shouldn't be req
> Any particular reason for implementing this ABI in ethtool rather than
> via some netlink-based interface? Devlink naturally comes to mind,
> given that cabling problems are not really related to the L2 and netdev
> shouldn't be required for diagnostics..
ethtool is already used for reporting
> Ethtool doesn't work well as a monitoring/event interface.
> Maybe this would be better as extended information with the netlink UP/DOW
> event.
This API is not meant for monitoring events.
The main use case here is a new interface that's down and won't go up for some
reason.
Nothing will mag
On Wed, 21 Jun 2017 16:04:43 +0300, Gal Pressman wrote:
> Hi All,
>
> Currently, drivers can only tell whether the link is up/down through
> ETHTOOL_GLINK callback, but no additional information is given in case
> of link down/failure.
>
> This series provides an infrastructure to ethtool that al
On Wed, 21 Jun 2017 16:04:43 +0300
Gal Pressman wrote:
> Hi All,
>
> Currently, drivers can only tell whether the link is up/down through
> ETHTOOL_GLINK callback, but no additional information is given in case
> of link down/failure.
>
> This series provides an infrastructure to ethtool that a
Hi All,
Currently, drivers can only tell whether the link is up/down through
ETHTOOL_GLINK callback, but no additional information is given in case
of link down/failure.
This series provides an infrastructure to ethtool that allows
netdevice drivers to hint the user with the reason why the link
