public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: "Allan, Bruce W" <bruce.w.allan@intel.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: RE: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for physical identification
Date: Tue, 12 Apr 2011 19:23:19 +0100	[thread overview]
Message-ID: <1302632599.2880.26.camel@bwh-desktop> (raw)
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A90018A2A3559@orsmsx509.amr.corp.intel.com>

On Tue, 2011-04-12 at 11:17 -0700, Allan, Bruce W wrote:
> >-----Original Message-----
> >From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> >Sent: Tuesday, April 12, 2011 9:28 AM
> >To: Allan, Bruce W
> >Cc: Stephen Hemminger; netdev@vger.kernel.org
> >Subject: RE: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for
> >physical identification
> >
> >I enquired here and found that we do have an OEM specifying 1 Hz.
> >
> >> FWIW, without digging too deep into how other drivers identify their
> >> respective ports through software, it appears it was split:
> >> * bnx2*, cxgb3, niu, s2io, sfc, sky2, tg3 - once per second
> >> * e100*, igb, ixgb*, pcnet32, ewrk3, cxgb4 - approx. twice per second
> >>
> >> AFAIK for parts that can set the physical identification through hardware,
> >> the Intel drivers set the on/off intervals to approximately twice/second;
> >> I don't know what other drivers do in that situation.
> >>
> >> So, I would guess it is not a common requirement to blink at a specific Hz.
> >> I have no problem with changing the hard-coded blink frequency to what our
> >> OEMs expect, but that might be an issue for those other vendors; I was just
> >> trying to make it flexible.
> >
> >Sadly it appears this is necessary.
> >
> >Let's define the return value for drivers wanting periodic callbacks to
> >be the blink frequency in Hz (normally 1 or 2), and get rid of the
> >special case of -EINVAL.  This also removes the rather inelegant
> >semantic that drivers may need to change their state despite returning
> >an error code.
> >
> >Ben.
> 
> OK.  Would you like me to send an updated patch?

Please.

Ben.

-- 
Ben Hutchings, Senior Software 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.


      reply	other threads:[~2011-04-12 18:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-11 23:16 [net-next-2.6 RFC PATCH] ethtool: allow custom interval for physical identification Bruce Allan
2011-04-11 23:26 ` Stephen Hemminger
2011-04-11 23:30   ` Allan, Bruce W
2011-04-12  0:00     ` Ben Hutchings
2011-04-12  1:07       ` Allan, Bruce W
2011-04-12 16:28         ` Ben Hutchings
2011-04-12 18:17           ` Allan, Bruce W
2011-04-12 18:23             ` Ben Hutchings [this message]

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=1302632599.2880.26.camel@bwh-desktop \
    --to=bhutchings@solarflare.com \
    --cc=bruce.w.allan@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox