From: Andrew Lunn <andrew@lunn.ch>
To: Ido Schimmel <idosch@idosch.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, davem@davemloft.net, mkubecek@suse.cz,
pali@kernel.org, jacob.e.keller@intel.com, jiri@nvidia.com,
vadimp@nvidia.com, mlxsw@nvidia.com,
Ido Schimmel <idosch@nvidia.com>
Subject: Re: [RFC PATCH net-next v2 1/6] ethtool: Add ability to control transceiver modules' power mode
Date: Thu, 19 Aug 2021 15:13:10 +0200 [thread overview]
Message-ID: <YR5Y5hCavFaWZCFH@lunn.ch> (raw)
In-Reply-To: <YR4NTylFy2ejODV6@shredder>
> > Should we also document what the default is? Seems like
> > ETHTOOL_MODULE_POWER_MODE_POLICY_HIGH_ON_UP is the generic network
> > interface default, so maybe it should also be the default for SFPs?
>
> I will add a note in Documentation/networking/ethtool-netlink.rst that
> the default power mode policy is driver-dependent (can be queried) and
> that it can either be 'high' or 'auto'.
Hi Ido
That is kind of my question. Do you want the default driver defined,
and varying between implementations, or do we want a clearly defined
default?
The stack has a mixture of both. An interface is admin down by
default, but it is anybody guess how pause will be configured?
By making it driver undefined, you cannot assume anything, and you
require user space to always configure it.
I don't have too strong an opinion, i'm more interested in what others
say, those who have to live with this.
Andrew
next prev parent reply other threads:[~2021-08-19 13:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-18 15:51 [RFC PATCH net-next v2 0/6] ethtool: Add ability to control transceiver modules' power mode Ido Schimmel
2021-08-18 15:51 ` [RFC PATCH net-next v2 1/6] " Ido Schimmel
2021-08-18 22:32 ` Jakub Kicinski
2021-08-18 22:55 ` Andrew Lunn
2021-08-19 7:50 ` Ido Schimmel
2021-08-19 13:13 ` Andrew Lunn [this message]
2021-08-19 14:34 ` Ido Schimmel
2021-08-19 14:42 ` Jakub Kicinski
2021-08-19 22:38 ` Keller, Jacob E
2021-08-19 7:47 ` Ido Schimmel
2021-08-19 14:38 ` Jakub Kicinski
2021-08-18 15:51 ` [RFC PATCH net-next v2 2/6] mlxsw: reg: Add Port Module Memory Map Properties register Ido Schimmel
2021-08-18 15:51 ` [RFC PATCH net-next v2 3/6] mlxsw: reg: Add Management Cable IO and Notifications register Ido Schimmel
2021-08-18 15:52 ` [RFC PATCH net-next v2 4/6] mlxsw: Add ability to control transceiver modules' power mode Ido Schimmel
2021-08-18 15:52 ` [RFC PATCH net-next v2 5/6] ethtool: Add transceiver module extended states Ido Schimmel
2021-08-18 15:52 ` [RFC PATCH net-next v2 6/6] mlxsw: Add support for " Ido Schimmel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YR5Y5hCavFaWZCFH@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=idosch@idosch.org \
--cc=idosch@nvidia.com \
--cc=jacob.e.keller@intel.com \
--cc=jiri@nvidia.com \
--cc=kuba@kernel.org \
--cc=mkubecek@suse.cz \
--cc=mlxsw@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pali@kernel.org \
--cc=vadimp@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.