Thread (31 messages) 31 messages, 4 authors, 2021-02-02

Re: [PATCH net-next v3 2/7] ethtool: Get link mode in use instead of speed and duplex parameters

From: Edwin Peer <hidden>
Date: 2021-01-31 20:05:13

On Sun, Jan 31, 2021 at 7:33 AM Danielle Ratson [off-list ref] wrote:
Edwin, adding the a new parameter requires a new patchset in my opinion.
Implementing the symmetrical side of the link_mode get, however can be a
part of this set. But, the problem with that would be that, as Michal said,
speed lanes and duplex can't provide us a single link_mode because of the
media. And since link_mode is one bit parameter, passing it to the driver
while randomly choosing the media, may cause either information loss, or
even fail to sync on a link mode if the chosen media is specifically not
supported in the lower levels. So, in my opinion it is related to adding the
new parameter we discussed, and should be done in a separate set.
Media is a little special in the sense that it physically depends on
what's plugged in. In that sense, media is truly read only. Setting it
won't change what's plugged in, so not having a separate knob for it
is probably okay, as it can be inferred from the active link mode on
the query side.

I don't see why the driver can't error if asked to set a link mode
having an incompatible media? The link modes corresponding to media
that's not plugged in wouldn't be listed in the supported set, so
there's no reason the user should expect to be able to set those.
There's no ambiguity or information loss if you refuse to set modes
that don't have the matching media attached.

Regards,
Edwin Peer

Attachments

  • smime.p7s [application/pkcs7-signature] 4160 bytes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help