[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 6 Jun 2012 18:41:51 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: Yuval Mintz <yuvalmin@...adcom.com>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Eilon Greenstein <eilong@...adcom.com>,
"peppe.cavallaro@...com" <peppe.cavallaro@...com>
Subject: RE: [net-next PATCH v2 1/3] Added kernel support in EEE Ethtool
commands
On Wed, 2012-06-06 at 16:40 +0000, Yuval Mintz wrote:
> > > + * @supported: Link speeds for which there is eee support.
> > > + * @advertised: Link speeds the interface advertises (AN) as eee capable.
> > > + * @lp_advertised: Link speeds the link partner advertised as eee capable.
> >
> > And these are bitmasks of SUPPORTED_* & ADVERTISED_* flags, right?
>
> Right.
>
> > Maybe 'link modes' not 'link speeds'?
>
> Not that it matters greatly, but there are SUPPORTED & ADVERTISED flags for
> things other than link speeds, such as connection type and flow control,
> so using exactly the same semantic in description might confuse someone.
What I'm getting at is that we don't have flags for speeds; we have
flags for modes (speed/duplex combination). I think EEE only works with
full-duplex modes but clients and drivers will still have to specify
that explicitly in flag names.
I can see that 'link modes' might be slightly ambiguous, so how about:
@supported: Mask of %SUPPORTED_* flags for the speed/duplex
combinations for which there is EEE support.
and similarly for the other fields.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists