netdev - Re: [E1000-devel] [PATCH net-next 4/4] igb: enable auxiliary PHC functions for the i210.

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]

Date:	Tue, 28 May 2013 10:39:58 -0700
From:	Alexander Duyck <alexander.h.duyck@...el.com>
To:	Richard Cochran <richardcochran@...il.com>
CC:	"Vick, Matthew" <matthew.vick@...el.com>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	"Keller, Jacob E" <jacob.e.keller@...el.com>
Subject: Re: [E1000-devel] [PATCH net-next 4/4] igb: enable auxiliary PHC
 functions for the i210.

On 05/28/2013 09:23 AM, Richard Cochran wrote:
> On Tue, May 28, 2013 at 03:58:07PM +0000, Vick, Matthew wrote:
>> On 5/27/13 2:21 AM, "Richard Cochran" <richardcochran@...il.com> wrote:
>  
>> I would prefer it if we did a MAC check before these two TSICR checks,
>> since we're making some assumptions about the hardware within the
>> interrupt cases. At the very least, a comment that these are only
>> applicable to I210/I211 would be nice.
> I can respin with a comment that the additional bits are i210 only. I
> think this is better than adding more checks into ISR. Since we only
> enable these bits for the i210, the checks would be redundant.
>
>>> diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c
>>> b/drivers/net/ethernet/intel/igb/igb_ptp.c
>>> index 5944de0..8cf4b8a 100644
>>> --- a/drivers/net/ethernet/intel/igb/igb_ptp.c
>>> +++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
>>> @@ -23,6 +23,15 @@
>>>
>>> #include "igb.h"
>>>
>>> +static int igb_input_sdp = 0;
>>> +static int igb_output_sdp = 1;
>>> +module_param(igb_input_sdp, int, 0444);
>>> +module_param(igb_output_sdp, int, 0444);
>>> +MODULE_PARM_DESC(igb_input_sdp,
>>> +		 "The SDP used as an input, to time stamp external events");
>>> +MODULE_PARM_DESC(igb_output_sdp,
>>> +		 "The SDP used to output the programmable periodic signal");
>>> +
>> Is there any other mechanism we could use to control this? I would imagine
>> not, but I know module parameters are generally frowned upon.
> This the way I handled it for the PHYTER, and I think it is the best
> way from our three choices:
>
> 1. kconfig option (inflexible)
> 2. module param
> 3. ethtool (can o'worms)

I really think the ethtool approach would be preferred since it is the
most flexible.  The problem with module parameters is that it only
really works with one port.

Couldn't you use the ethtool private flags interface or something
similar to achieve the same result?

Thanks,

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