From: Ben Hutchings <bhutchings@solarflare.com>
To: Peter Meerwald <pmeerw@pmeerw.net>
Cc: David Miller <davem@davemloft.net>, <netdev@vger.kernel.org>
Subject: Re: [PATCH 1/2] smsc95xx: add module parameter to turn off NIC status leds
Date: Thu, 9 Feb 2012 16:18:44 +0000 [thread overview]
Message-ID: <1328804324.2562.6.camel@bwh-desktop> (raw)
In-Reply-To: <alpine.DEB.2.01.1202091024250.8085@pmeerw.net>
On Thu, 2012-02-09 at 10:38 +0100, Peter Meerwald wrote:
> Hello David,
>
> > > add module parameter to allow to turn off NIC status leds (link,
> > > speed, activity); blinking LEDs are annoying outside the server room :)
>
> > No. Create a generic mechanism, perhaps via ethtool, for users to
> > configure something like this.
>
> > Otherwise the next driver that wants to provide this kind of knob
> > will add yet another module parameter with yet another name, and
> > this kind of ad-hoc set of interfaces absolutely sucks for users.
>
> I am not sure how many NICs provide that functionality, so a specific knob
> seemed reasonable
I think this has been controllable on all the PHYs I've dealt with.
Generally they need to be adaptable to the requirements for different
boards. So in theory this is generic.
However I just don't see this being a popular enough option for many
driver maintainers to implement it. Those status LEDs are useful. Put
a piece of tape over them if you don't like them. :-) Or if you're
designing a board then put them somewhere out of the way (but your users
may hate you for it).
> I had a look at ethtool, there are ETHTOOL_GFLAGS and ETHTOOL_GPFLAGS (and
> the respective setters) which could be used -- but noone seems to use
> those for any purpose
>
> a private flag for LED control (via ETHTOOL_GPFLAGS) is pretty much the
> same knob as a module parameter, so not an option
In my view it's slightly preferable because private flags are
per-device. Not sure whether David would agree.
Ben.
> so the remaining option is to add something like ETHTOOL_GLEDCONTROL /
> ETHTOOL_SLEDCONTROL with likely only one user (smsc95xx)
>
> regards, p.
>
--
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.
next prev parent reply other threads:[~2012-02-09 16:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1328699332-9024-1-git-send-email-pmeerw@pmeerw.net>
[not found] ` <20120208.152624.1844477840327789365.davem@davemloft.net>
2012-02-09 9:38 ` [PATCH 1/2] smsc95xx: add module parameter to turn off NIC status leds Peter Meerwald
2012-02-09 16:18 ` Ben Hutchings [this message]
[not found] ` <1328699332-9024-2-git-send-email-pmeerw@pmeerw.net>
[not found] ` <20120208.152647.2150915591550944292.davem@davemloft.net>
2012-02-09 9:59 ` [PATCH 2/2] smsc95xx: allow to re-use MAC address already programmed Peter Meerwald
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=1328804324.2562.6.camel@bwh-desktop \
--to=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
/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;
as well as URLs for NNTP newsgroup(s).