netdev - Re: [PATCH net-next 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: <20211005070747.1244a113@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Tue, 5 Oct 2021 07:07:47 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, andrew@...n.ch,
        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: [PATCH net-next 1/6] ethtool: Add ability to control
 transceiver modules' power mode

On Tue, 5 Oct 2021 15:04:02 +0300 Ido Schimmel wrote:
> > > Can't there be drivers which implement power but don't support the
> > > mode policy?  
> > 
> > I don't really see how. The policy is a host attribute (not module)
> > determining how the host configures the power mode of the module. It
> > always exists, but can be fixed.
> > 
> > Do you still think we should make the change below?
> > 
> > diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
> > index 1b126e8b5269..a2223b685451 100644
> > --- a/include/uapi/linux/ethtool.h
> > +++ b/include/uapi/linux/ethtool.h
> > @@ -721,7 +721,7 @@ enum ethtool_stringset {
> >   *     administratively down.
> >   */
> >  enum ethtool_module_power_mode_policy {
> > -       ETHTOOL_MODULE_POWER_MODE_POLICY_HIGH,
> > +       ETHTOOL_MODULE_POWER_MODE_POLICY_HIGH = 1,
> >         ETHTOOL_MODULE_POWER_MODE_POLICY_AUTO,
> >  };  
> 
> I read your reply again about "still need a valid bit, granted just
> internal to the core". My confusion was that I thought only the valid
> bit in the driver-facing API bothered you, but you actually wanted me to
> remove all of them.
> 
> How about the below (compile tested)?

Yup, exactly!