netdev - RE: [RFC PATCH net-next v3 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 for Android: free password hash cracker in your pocket

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

Message-ID: <CO1PR11MB5089E122FEE8FEA720EE58B1D6C69@CO1PR11MB5089.namprd11.prod.outlook.com>
Date:   Wed, 25 Aug 2021 07:35:06 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Ido Schimmel <idosch@...sch.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "mkubecek@...e.cz" <mkubecek@...e.cz>,
        "pali@...nel.org" <pali@...nel.org>,
        "jiri@...dia.com" <jiri@...dia.com>,
        "vadimp@...dia.com" <vadimp@...dia.com>,
        "mlxsw@...dia.com" <mlxsw@...dia.com>,
        Ido Schimmel <idosch@...dia.com>
Subject: RE: [RFC PATCH net-next v3 1/6] ethtool: Add ability to control
 transceiver modules' power mode



> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Tuesday, August 24, 2021 4:48 PM
> To: Keller, Jacob E <jacob.e.keller@...el.com>
> Cc: Ido Schimmel <idosch@...sch.org>; netdev@...r.kernel.org;
> davem@...emloft.net; andrew@...n.ch; mkubecek@...e.cz; pali@...nel.org;
> jiri@...dia.com; vadimp@...dia.com; mlxsw@...dia.com; Ido Schimmel
> <idosch@...dia.com>
> Subject: Re: [RFC PATCH net-next v3 1/6] ethtool: Add ability to control
> transceiver modules' power mode
> 
> On Tue, 24 Aug 2021 23:18:56 +0000 Keller, Jacob E wrote:
> > > > + * @mode_valid: Indicates the validity of the @mode field. Should be set
> by
> > > > + * device drivers on get operations when a module is plugged-in.
> > >
> > > Should we make a firm decision on whether we want to use these kind of
> > > valid bits or choose invalid defaults? As you may guess my preference
> > > is the latter since that's what I usually do, that way drivers don't
> > > have to write two fields.
> > >
> > > Actually I think this may be the first "valid" in ethtool, I thought we
> > > already had one but I don't see it now..
> >
> > coalesce settings have a valid mode don't they? Or at least an "accepted
> modes"?
> 
> That's a static per-driver bitmask 'cause we don't trust driver writers
> to error out on all the unsupported fields. The driver code doesn't
> operate on it in the callbacks.

Ahh. Right. Ok yea this is different here.

If we can keep it simple in the drivers, great! I usually like the valid approach, but mostly if its kernel-core code doing it since we're more likely to catch and review that as opposed to individual drivers.

If we're expecting drivers to set validity, a simpler interface would be preferable.

Thanks,
Jake