All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vick, Matthew" <matthew.vick@intel.com>
To: Richard Cochran <richardcochran@gmail.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	"e1000-devel@lists.sourceforge.net"
	<e1000-devel@lists.sourceforge.net>,
	"Keller, Jacob E" <jacob.e.keller@intel.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>
Subject: Re: [PATCH net-next 4/4] igb: enable auxiliary PHC functions for the i210.
Date: Tue, 28 May 2013 17:49:21 +0000	[thread overview]
Message-ID: <CDCA3AA1.1E8D4%matthew.vick@intel.com> (raw)
In-Reply-To: <20130528162325.GD4678@netboy>

On 5/28/13 9:23 AM, "Richard Cochran" <richardcochran@gmail.com> wrote:

>On Tue, May 28, 2013 at 03:58:07PM +0000, Vick, Matthew wrote:
>> On 5/27/13 2:21 AM, "Richard Cochran" <richardcochran@gmail.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.

Personal preference would dictate a MAC check, but I'm alright with a
comment. :)

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

Ah, I didn't realize we had a precedent. Module param is fine with me,
then. ethtool does seem like the right long-term solution, but I don't
think that should gate your patchset if we already have a precedent for
this functionality.

>> >@@ -711,6 +800,68 @@ int igb_ptp_hwtstamp_ioctl(struct net_device
>>*netdev,
>> > 		-EFAULT : 0;
>> > }
>> > 
>> >+static int igb_sdp_init(struct igb_adapter *adapter)
>> >+{
>> >+	struct e1000_hw *hw = &adapter->hw;
>> >+	u32 ctrl, ctrl_ext, tssdp = 0;
>> >+
>> >+	if (igb_input_sdp == igb_output_sdp) {
>> >+		pr_err("SDP %d set as both input and output\n", igb_input_sdp);
>> >+		return -1;
>> 
>> Shouldn't this return -EINVAL?
>
>Maybe we don't need the return value at all. Just the message is
>important, I think.

I think an error is the right way to go, but if it's not then we should
print a warning instead of an error.

Also, on second thought, please use the dev_err or dev_warn macros for
consistency with the rest of the codebase.

> 
>> >@@ -785,6 +936,10 @@ void igb_ptp_init(struct igb_adapter *adapter)
>> > 		struct timespec ts = ktime_to_timespec(ktime_get_real());
>> > 
>> > 		igb_ptp_settime_i210(&adapter->ptp_caps, &ts);
>> >+		igb_sdp_init(adapter);
>> 
>> What if igb_sdp_init fails?
>
>Hmm, maybe we should then disable the extra features... will consider
>for V2.

That would be my vote, since we would have failed to initialize that extra
feature.

  parent reply	other threads:[~2013-05-28 17:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-27  9:21 [PATCH net-next 0/4] igb: auxiliary PHC functions for the i210 Richard Cochran
2013-05-27  9:21 ` [PATCH net-next 1/4] igb: refactor and simplify time sync interrupt handling Richard Cochran
2013-05-28  0:44   ` Jeff Kirsher
2013-05-28 15:24   ` Vick, Matthew
2013-05-27  9:21 ` [PATCH net-next 2/4] igb: add more register definitions for time sync functions Richard Cochran
2013-05-28  0:44   ` Jeff Kirsher
2013-05-27  9:21 ` [PATCH net-next 3/4] igb: do not clobber the TSAUXC bits on reset Richard Cochran
2013-05-28  0:44   ` Jeff Kirsher
2013-05-27  9:21 ` [PATCH net-next 4/4] igb: enable auxiliary PHC functions for the i210 Richard Cochran
2013-05-28  0:45   ` Jeff Kirsher
2013-05-28 15:58   ` Vick, Matthew
2013-05-28 16:23     ` Richard Cochran
2013-05-28 17:39       ` [E1000-devel] " Alexander Duyck
2013-05-28 17:49       ` Vick, Matthew [this message]
2013-05-28 21:12         ` Keller, Jacob E
2013-05-29  7:24           ` Richard Cochran
2013-05-29  7:34             ` David Miller
2013-05-29 20:32             ` Ben Hutchings
2013-05-28 15:58 ` [PATCH net-next 0/4] igb: " Vick, Matthew
  -- strict thread matches above, loose matches on Subject: below --
2014-11-17 23:06 Richard Cochran
2014-11-17 23:06 ` [PATCH net-next 4/4] igb: enable " Richard Cochran
2014-11-17 23:28   ` Keller, Jacob E

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=CDCA3AA1.1E8D4%matthew.vick@intel.com \
    --to=matthew.vick@intel.com \
    --cc=davem@davemloft.net \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=jacob.e.keller@intel.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.