netdev - Re: [PATCH 1/2] smsc95xx: add module parameter to turn off NIC status leds

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] [day] [month] [year] [list]

Date:	Thu, 9 Feb 2012 16:18:44 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Peter Meerwald <pmeerw@...erw.net>
CC:	David Miller <davem@...emloft.net>, <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/2] smsc95xx: add module parameter to turn off NIC
 status leds

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.

--
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