netdev - Re: [RFC PATCH net-next v2 1/6] ethtool: Add ability to control transceiver modules' power mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YR5Y5hCavFaWZCFH@lunn.ch>
Date:   Thu, 19 Aug 2021 15:13:10 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        davem@...emloft.net, mkubecek@...e.cz, pali@...nel.org,
        jacob.e.keller@...el.com, jiri@...dia.com, vadimp@...dia.com,
        mlxsw@...dia.com, Ido Schimmel <idosch@...dia.com>
Subject: Re: [RFC PATCH net-next v2 1/6] ethtool: Add ability to control
 transceiver modules' power mode

> > 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