netdev - RE: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for physical identification

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

Message-ID: <8DD2590731AB5D4C9DBF71A877482A90018A2A3559@orsmsx509.amr.corp.intel.com>
Date:	Tue, 12 Apr 2011 11:17:00 -0700
From:	"Allan, Bruce W" <bruce.w.allan@...el.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	Stephen Hemminger <shemminger@...tta.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for
 physical identification

>-----Original Message-----
>From: Ben Hutchings [mailto:bhutchings@...arflare.com]
>Sent: Tuesday, April 12, 2011 9:28 AM
>To: Allan, Bruce W
>Cc: Stephen Hemminger; netdev@...r.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?

Bruce.