* Re: [net-next-2.6 PATCH] e1000/e1000e/igb/ixgb/ixgbe: set NETIF_F_HIGHDMA for VLAN feature flags
From: Eric Dumazet @ 2010-09-23 6:13 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: David Miller, netdev, gospo, bphilips, yi.zou
In-Reply-To: <AANLkTikDdxFho2ioBHMbze685+garDWF9kF3qFXZA9Hr@mail.gmail.com>
Le mercredi 22 septembre 2010 à 23:06 -0700, Jeff Kirsher a écrit :
> Good suggestion! Do you plan on making a patch Eric? Let me know of
> any assistance
> you need with the Intel LAN dirvers.
Yes, I'll do it, no worry :)
Thanks !
^ permalink raw reply
* Re: [net-next-2.6 PATCH] e1000/e1000e/igb/ixgb/ixgbe: set NETIF_F_HIGHDMA for VLAN feature flags
From: Jeff Kirsher @ 2010-09-23 6:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, gospo, bphilips, yi.zou
In-Reply-To: <1285219690.2380.70.camel@edumazet-laptop>
On Wed, Sep 22, 2010 at 22:28, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 22 septembre 2010 à 21:20 -0700, David Miller a écrit :
>> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Date: Wed, 22 Sep 2010 20:57:58 -0700
>>
>> > From: Yi Zou <yi.zou@intel.com>
>> >
>> > If the netdev->features is set with NETIF_F_HIGHDMA, we should set the
>> > corresponding netdev->vlan_features as well to allow VLAN netdev created
>> > on top of the real netdev to be able to also benefit from HIGHDMA on 32bit
>> > system, reducing the performance hit that is caused by __skb_linearize(),
>> > particularly for large send. This is fixed in this patch for all Intel e1000,
>> > e1000e, igb, ixgbe, and ixgbe drivers since this should be beneficial
>> > to all devices supported by these drivers.
>> >
>> > Signed-off-by: Yi Zou <yi.zou@intel.com>
>> > Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
>> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>
>> Applied.
>
>
> Maybe this could be done in core network.
>
>
Good suggestion! Do you plan on making a patch Eric? Let me know of
any assistance
you need with the Intel LAN dirvers.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] e1000/e1000e/igb/ixgb/ixgbe: set NETIF_F_HIGHDMA for VLAN feature flags
From: David Miller @ 2010-09-23 6:00 UTC (permalink / raw)
To: eric.dumazet; +Cc: jeffrey.t.kirsher, netdev, gospo, bphilips, yi.zou
In-Reply-To: <1285219690.2380.70.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 23 Sep 2010 07:28:10 +0200
> Le mercredi 22 septembre 2010 à 21:20 -0700, David Miller a écrit :
>> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Date: Wed, 22 Sep 2010 20:57:58 -0700
>>
>> > From: Yi Zou <yi.zou@intel.com>
>> >
>> > If the netdev->features is set with NETIF_F_HIGHDMA, we should set the
>> > corresponding netdev->vlan_features as well to allow VLAN netdev created
>> > on top of the real netdev to be able to also benefit from HIGHDMA on 32bit
>> > system, reducing the performance hit that is caused by __skb_linearize(),
>> > particularly for large send. This is fixed in this patch for all Intel e1000,
>> > e1000e, igb, ixgbe, and ixgbe drivers since this should be beneficial
>> > to all devices supported by these drivers.
>> >
>> > Signed-off-by: Yi Zou <yi.zou@intel.com>
>> > Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
>> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>
>> Applied.
>
> Maybe this could be done in core network.
Indeeed, just as we do for NETIF_F_GRO now.
^ permalink raw reply
* Re: [PATCH] net: fix a lockdep splat
From: Eric Dumazet @ 2010-09-23 5:42 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Tetsuo Handa, David Miller, linux-fsdevel, netdev
In-Reply-To: <1285195419.2380.39.camel@edumazet-laptop>
Le jeudi 23 septembre 2010 à 00:43 +0200, Eric Dumazet a écrit :
>
> [PATCH v2] net: fix a lockdep splat
>
...
> lockdep is not happy with this, as reported by Tetsuo Handa
>
> It seems only way to deal with this is to use read_lock_bh(callbacklock)
> everywhere.
>
> Thanks to Jarek for pointing a bug in my first attempt and suggesting
> this solution.
>
> Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Jarek Poplawski <jarkao2@gmail.com>
Tested-by: Eric Dumazet <eric.dumazet@gmail.com>
I tested it on my machine and could not reproduce the lockdep splat.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next-2.6 PATCH] e1000/e1000e/igb/ixgb/ixgbe: set NETIF_F_HIGHDMA for VLAN feature flags
From: Eric Dumazet @ 2010-09-23 5:28 UTC (permalink / raw)
To: David Miller; +Cc: jeffrey.t.kirsher, netdev, gospo, bphilips, yi.zou
In-Reply-To: <20100922.212023.91330415.davem@davemloft.net>
Le mercredi 22 septembre 2010 à 21:20 -0700, David Miller a écrit :
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Wed, 22 Sep 2010 20:57:58 -0700
>
> > From: Yi Zou <yi.zou@intel.com>
> >
> > If the netdev->features is set with NETIF_F_HIGHDMA, we should set the
> > corresponding netdev->vlan_features as well to allow VLAN netdev created
> > on top of the real netdev to be able to also benefit from HIGHDMA on 32bit
> > system, reducing the performance hit that is caused by __skb_linearize(),
> > particularly for large send. This is fixed in this patch for all Intel e1000,
> > e1000e, igb, ixgbe, and ixgbe drivers since this should be beneficial
> > to all devices supported by these drivers.
> >
> > Signed-off-by: Yi Zou <yi.zou@intel.com>
> > Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Applied.
Maybe this could be done in core network.
^ permalink raw reply
* Re: [PATCH] net: fix a lockdep splat
From: Eric Dumazet @ 2010-09-23 5:05 UTC (permalink / raw)
To: David Miller; +Cc: jarkao2, penguin-kernel, linux-fsdevel, netdev
In-Reply-To: <20100922.212332.45886457.davem@davemloft.net>
Le mercredi 22 septembre 2010 à 21:23 -0700, David Miller a écrit :
> From: David Miller <davem@davemloft.net>
> Date: Wed, 22 Sep 2010 20:53:24 -0700 (PDT)
>
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Thu, 23 Sep 2010 00:43:39 +0200
> >
> >> (A) (this is used in net/sunrpc/xprtsock.c)
> >> read_lock(&sk->sk_callback_lock) (without blocking BH)
> >> <BH>
> >> spin_lock(&sk->sk_slock.slock);
> >> ...
> >> read_lock(&sk->sk_callback_lock);
> >> ...
> >
> > What's the exact path that leads to this? I looked quickly and couldn't
> > find which sunrpc callback override does it.
>
> Sorry, I'm being unusually dense at the moment, ignore this question :-)
No problem ;)
But we might answer it anyway for other readers :
vi +1417 net/sunrpc/xprtsock.c
static void xs_udp_write_space(struct sock *sk)
{
read_lock(&sk->sk_callback_lock);
// We can be interrupted here and call INPUT_PATH()
/* from net/core/sock.c:sock_def_write_space */
if (sock_writeable(sk))
xs_write_space(sk);
read_unlock(&sk->sk_callback_lock);
}
INPUT_PATH()
{
spin_lock(&sk->slock);
queue skb to receive queue or backlog
spin_unlock(&sk->slock);
}
If another cpu does (C), we can deadlock.
C)
spin_lock_bh(&sk->sk_slock)
...
write_lock_bh(&sk->sk_callback_lock)
...
Then we can have a deadlock with (A)
CPU1 [A] CPU2 [C]
read_lock(&sk->sk_callback_lock)
<BH> spin_lock_bh(&sk->sk_slock)
<wait to spin_lock(slock)>
<wait to write_lock_bh(callback_lock)>
It seems only TCP stack contains [C] cases, in very unlikely paths, but still...
Since all AF_INET sockets share the same af_callback_key
*and* the same af_family_slock_keys, lockdep warned Tetsuo because
it detects an UDP [A] case and a TCP [C] case.
^ permalink raw reply
* Re: [PATCH] net: fix a lockdep splat
From: David Miller @ 2010-09-23 4:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: jarkao2, penguin-kernel, linux-fsdevel, netdev
In-Reply-To: <20100922.205324.68141587.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 22 Sep 2010 20:53:24 -0700 (PDT)
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 23 Sep 2010 00:43:39 +0200
>
>> (A) (this is used in net/sunrpc/xprtsock.c)
>> read_lock(&sk->sk_callback_lock) (without blocking BH)
>> <BH>
>> spin_lock(&sk->sk_slock.slock);
>> ...
>> read_lock(&sk->sk_callback_lock);
>> ...
>
> What's the exact path that leads to this? I looked quickly and couldn't
> find which sunrpc callback override does it.
Sorry, I'm being unusually dense at the moment, ignore this question :-)
^ permalink raw reply
* [net-next-2.6 PATCH 3/3] e1000: use GRO for receive
From: Jeff Kirsher @ 2010-09-23 4:23 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Jesse Brandeburg, Jeff Kirsher
In-Reply-To: <20100923042126.11798.49675.stgit@localhost.localdomain>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
E1000 can benefit from calling the GRO receive functions.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000/e1000_main.c | 19 ++++++++-----------
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index c88439d..796523f 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3664,13 +3664,14 @@ static void e1000_consume_page(struct e1000_buffer *bi, struct sk_buff *skb,
static void e1000_receive_skb(struct e1000_adapter *adapter, u8 status,
__le16 vlan, struct sk_buff *skb)
{
- if (unlikely(adapter->vlgrp && (status & E1000_RXD_STAT_VP))) {
- vlan_hwaccel_receive_skb(skb, adapter->vlgrp,
- le16_to_cpu(vlan) &
- E1000_RXD_SPC_VLAN_MASK);
- } else {
- netif_receive_skb(skb);
- }
+ skb->protocol = eth_type_trans(skb, adapter->netdev);
+
+ if ((unlikely(adapter->vlgrp && (status & E1000_RXD_STAT_VP))))
+ vlan_gro_receive(&adapter->napi, adapter->vlgrp,
+ le16_to_cpu(vlan) & E1000_RXD_SPC_VLAN_MASK,
+ skb);
+ else
+ napi_gro_receive(&adapter->napi, skb);
}
/**
@@ -3828,8 +3829,6 @@ static bool e1000_clean_jumbo_rx_irq(struct e1000_adapter *adapter,
goto next_desc;
}
- skb->protocol = eth_type_trans(skb, netdev);
-
e1000_receive_skb(adapter, status, rx_desc->special, skb);
next_desc:
@@ -3992,8 +3991,6 @@ static bool e1000_clean_rx_irq(struct e1000_adapter *adapter,
((u32)(rx_desc->errors) << 24),
le16_to_cpu(rx_desc->csum), skb);
- skb->protocol = eth_type_trans(skb, netdev);
-
e1000_receive_skb(adapter, status, rx_desc->special, skb);
next_desc:
^ permalink raw reply related
* [net-next-2.6 PATCH 2/3] e1000: fix occasional panic on unload
From: Jeff Kirsher @ 2010-09-23 4:22 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Jesse Brandeburg, Jeff Kirsher
In-Reply-To: <20100923042126.11798.49675.stgit@localhost.localdomain>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
Net drivers in general have an issue where timers fired
by mod_timer or work threads with schedule_work are running
outside of the rtnl_lock.
With no other lock protection these routines are vulnerable
to races with driver unload or reset paths.
The longer term solution to this might be a redesign with
safer locks being taken in the driver to guarantee no
reentrance, but for now a safe and effective fix is
to take the rtnl_lock in these routines.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000/e1000_main.c | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 5b4c6c0..c88439d 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -521,8 +521,21 @@ void e1000_down(struct e1000_adapter *adapter)
e1000_clean_all_rx_rings(adapter);
}
+void e1000_reinit_safe(struct e1000_adapter *adapter)
+{
+ while (test_and_set_bit(__E1000_RESETTING, &adapter->flags))
+ msleep(1);
+ rtnl_lock();
+ e1000_down(adapter);
+ e1000_up(adapter);
+ rtnl_unlock();
+ clear_bit(__E1000_RESETTING, &adapter->flags);
+}
+
void e1000_reinit_locked(struct e1000_adapter *adapter)
{
+ /* if rtnl_lock is not held the call path is bogus */
+ ASSERT_RTNL();
WARN_ON(in_interrupt());
while (test_and_set_bit(__E1000_RESETTING, &adapter->flags))
msleep(1);
@@ -2247,7 +2260,10 @@ static void e1000_update_phy_info_task(struct work_struct *work)
struct e1000_adapter,
phy_info_task);
struct e1000_hw *hw = &adapter->hw;
+
+ rtnl_lock();
e1000_phy_get_info(hw, &adapter->phy_info);
+ rtnl_unlock();
}
/**
@@ -2273,6 +2289,7 @@ static void e1000_82547_tx_fifo_stall_task(struct work_struct *work)
struct net_device *netdev = adapter->netdev;
u32 tctl;
+ rtnl_lock();
if (atomic_read(&adapter->tx_fifo_stall)) {
if ((er32(TDT) == er32(TDH)) &&
(er32(TDFT) == er32(TDFH)) &&
@@ -2293,6 +2310,7 @@ static void e1000_82547_tx_fifo_stall_task(struct work_struct *work)
mod_timer(&adapter->tx_fifo_stall_timer, jiffies + 1);
}
}
+ rtnl_unlock();
}
bool e1000_has_link(struct e1000_adapter *adapter)
@@ -3160,7 +3178,7 @@ static void e1000_reset_task(struct work_struct *work)
struct e1000_adapter *adapter =
container_of(work, struct e1000_adapter, reset_task);
- e1000_reinit_locked(adapter);
+ e1000_reinit_safe(adapter);
}
/**
^ permalink raw reply related
* [net-next-2.6 PATCH 1/3] e1000: use work queues
From: Jeff Kirsher @ 2010-09-23 4:22 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Jesse Brandeburg, Jeff Kirsher
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
E1000 is using several timers that in a follow on patch
will need to acquire the rtnl_lock in order to be safe.
This patch moves the timer bodies into work queues which
will allow the next patch to add rtnl_lock.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000/e1000.h | 3 +++
drivers/net/e1000/e1000_main.c | 25 ++++++++++++++++++++++++-
2 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index 99288b9..a881dd0 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -310,6 +310,9 @@ struct e1000_adapter {
int need_ioport;
bool discarding;
+
+ struct work_struct fifo_stall_task;
+ struct work_struct phy_info_task;
};
enum e1000_state_t {
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index a1dacea..5b4c6c0 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -123,8 +123,10 @@ static void e1000_clean_rx_ring(struct e1000_adapter *adapter,
struct e1000_rx_ring *rx_ring);
static void e1000_set_rx_mode(struct net_device *netdev);
static void e1000_update_phy_info(unsigned long data);
+static void e1000_update_phy_info_task(struct work_struct *work);
static void e1000_watchdog(unsigned long data);
static void e1000_82547_tx_fifo_stall(unsigned long data);
+static void e1000_82547_tx_fifo_stall_task(struct work_struct *work);
static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
struct net_device *netdev);
static struct net_device_stats * e1000_get_stats(struct net_device *netdev);
@@ -1047,7 +1049,9 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
adapter->phy_info_timer.function = e1000_update_phy_info;
adapter->phy_info_timer.data = (unsigned long)adapter;
+ INIT_WORK(&adapter->fifo_stall_task, e1000_82547_tx_fifo_stall_task);
INIT_WORK(&adapter->reset_task, e1000_reset_task);
+ INIT_WORK(&adapter->phy_info_task, e1000_update_phy_info_task);
e1000_check_options(adapter);
@@ -2234,6 +2238,14 @@ static void e1000_set_rx_mode(struct net_device *netdev)
static void e1000_update_phy_info(unsigned long data)
{
struct e1000_adapter *adapter = (struct e1000_adapter *)data;
+ schedule_work(&adapter->phy_info_task);
+}
+
+static void e1000_update_phy_info_task(struct work_struct *work)
+{
+ struct e1000_adapter *adapter = container_of(work,
+ struct e1000_adapter,
+ phy_info_task);
struct e1000_hw *hw = &adapter->hw;
e1000_phy_get_info(hw, &adapter->phy_info);
}
@@ -2242,10 +2254,21 @@ static void e1000_update_phy_info(unsigned long data)
* e1000_82547_tx_fifo_stall - Timer Call-back
* @data: pointer to adapter cast into an unsigned long
**/
-
static void e1000_82547_tx_fifo_stall(unsigned long data)
{
struct e1000_adapter *adapter = (struct e1000_adapter *)data;
+ schedule_work(&adapter->fifo_stall_task);
+}
+
+/**
+ * e1000_82547_tx_fifo_stall_task - task to complete work
+ * @work: work struct contained inside adapter struct
+ **/
+static void e1000_82547_tx_fifo_stall_task(struct work_struct *work)
+{
+ struct e1000_adapter *adapter = container_of(work,
+ struct e1000_adapter,
+ fifo_stall_task);
struct e1000_hw *hw = &adapter->hw;
struct net_device *netdev = adapter->netdev;
u32 tctl;
^ permalink raw reply related
* Re: [net-next-2.6 PATCH] e1000/e1000e/igb/ixgb/ixgbe: set NETIF_F_HIGHDMA for VLAN feature flags
From: David Miller @ 2010-09-23 4:20 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, yi.zou
In-Reply-To: <20100923035755.11561.14170.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 22 Sep 2010 20:57:58 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> If the netdev->features is set with NETIF_F_HIGHDMA, we should set the
> corresponding netdev->vlan_features as well to allow VLAN netdev created
> on top of the real netdev to be able to also benefit from HIGHDMA on 32bit
> system, reducing the performance hit that is caused by __skb_linearize(),
> particularly for large send. This is fixed in this patch for all Intel e1000,
> e1000e, igb, ixgbe, and ixgbe drivers since this should be beneficial
> to all devices supported by these drivers.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/2] igb: Add support for DH89xxCC
From: David Miller @ 2010-09-23 4:20 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, joseph.gasparakis
In-Reply-To: <20100923035641.11511.84199.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 22 Sep 2010 20:56:44 -0700
> From: Joseph Gasparakis <joseph.gasparakis@intel.com>
>
> This patch adds support for the Intel(r) DH89xxCC series. The new
> device will be using Intel(r) i347-AT4 and Marvell(r) M88E1322 and
> M88E1112 PHYs. Support for these devices has also been added here.
>
> Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/2] igb: clear VF_PROMISC bits instead of setting all other bits
From: David Miller @ 2010-09-23 4:20 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, alexander.h.duyck
In-Reply-To: <20100923035538.11511.16233.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 22 Sep 2010 20:56:20 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change corrects an issue in which we were setting all flag bits except
> for promisc instead of clearing the promisc bits due to the incorrect use
> of an |= instead of an &=.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 6/6] e1000e: 82579 do not gate auto config of PHY by hardware during nominal use
From: David Miller @ 2010-09-23 4:11 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100923031700.10976.38.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 22 Sep 2010 20:17:01 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> For non-managed versions of 82579, set the bit that prevents the hardware
> from automatically configuring the PHY after resets only when the driver
> performs a reset, clear the bit after resets. This is so the hardware can
> configure the PHY automatically when the part is reset in a manner that is
> not controlled by the driver (e.g. in a virtual environment via PCI FLR)
> otherwise the PHY will be mis-configured causing issues such as failing to
> link at 1000Mbps.
> For managed versions of 82579, keep the previous behavior since the
> manageability firmware will handle the PHY configuration.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 5/6] e1000e: 82579 jumbo frame workaround causing CRC errors
From: David Miller @ 2010-09-23 4:11 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100923031639.10976.20852.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 22 Sep 2010 20:16:40 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> The subject workaround was causing CRC errors due to writing the wrong
> register with updates of the RCTL register. It was also found that the
> workaround function which modifies the RCTL register was being called in
> the middle of a read-modify-write operation of the RCTL register, so the
> function call has been moved appropriately. Lastly, jumbo frames must not
> be allowed when CRC stripping is disabled by a module parameter because the
> workaround requires the CRC be stripped.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 4/6] e1000e: 82579 unaccounted missed packets
From: David Miller @ 2010-09-23 4:11 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100923031617.10976.68976.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 22 Sep 2010 20:16:18 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> On 82579, there is a hardware bug that can cause received packets to not
> get transferred from the PHY to the MAC due to K1 (a power saving feature
> of the PHY-MAC interconnect similar to ASPM L1). Since the MAC controls
> the accounting of missed packets, these will go unnoticed. Workaround the
> issue by setting the K1 beacon duration according to the link speed.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 3/6] e1000e: 82566DC fails to get link
From: David Miller @ 2010-09-23 4:10 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, stable, bruce.w.allan
In-Reply-To: <20100923031553.10976.18727.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 22 Sep 2010 20:15:54 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Two recent patches to cleanup the reset[1] and initial PHY configuration[2]
> code paths for ICH/PCH devices inadvertently left out a 10msec delay and
> device ID check respectively which are necessary for the 82566DC (device id
> 0x104b) to be configured properly, otherwise it will not get link.
>
> [1] commit e98cac447cc1cc418dff1d610a5c79c4f2bdec7f
> [2] commit 3f0c16e84438d657d29446f85fe375794a93f159
>
> CC: stable@kernel.org
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/6] e1000e: 82579 SMBus address and LEDs incorrect after device reset
From: David Miller @ 2010-09-23 4:10 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100923031532.10976.41477.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 22 Sep 2010 20:15:33 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Since the hardware is prevented from performing automatic PHY configuration
> (the driver does it instead), the OEM_WRITE_ENABLE bit in the EXTCNF_CTRL
> register will not get cleared preventing the SMBus address and the LED
> configuration to be written to the PHY registers. On 82579, do not check
> the OEM_WRITE_ENABLE bit.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/6] e1000e: 82577/8/9 issues with device in Sx
From: David Miller @ 2010-09-23 4:10 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100923031432.10976.81909.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 22 Sep 2010 20:15:08 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> When going to Sx, disable gigabit in PHY (e1000_oem_bits_config_ich8lan)
> in addition to the MAC before configuring PHY wakeup otherwise the PHY
> configuration writes might be missed. Also write the LED configuration
> and SMBus address to the PHY registers (e1000_oem_bits_config_ich8lan and
> e1000_write_smbus_addr, respectively). The reset is no longer needed
> since re-auto-negotiation is forced in e1000_oem_bits_config_ich8lan and
> leaving it in causes issues with auto-negotiating the link.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* [net-next-2.6 PATCH] e1000/e1000e/igb/ixgb/ixgbe: set NETIF_F_HIGHDMA for VLAN feature flags
From: Jeff Kirsher @ 2010-09-23 3:57 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Yi Zou, Jeff Kirsher
From: Yi Zou <yi.zou@intel.com>
If the netdev->features is set with NETIF_F_HIGHDMA, we should set the
corresponding netdev->vlan_features as well to allow VLAN netdev created
on top of the real netdev to be able to also benefit from HIGHDMA on 32bit
system, reducing the performance hit that is caused by __skb_linearize(),
particularly for large send. This is fixed in this patch for all Intel e1000,
e1000e, igb, ixgbe, and ixgbe drivers since this should be beneficial
to all devices supported by these drivers.
Signed-off-by: Yi Zou <yi.zou@intel.com>
Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000/e1000_main.c | 4 +++-
drivers/net/e1000e/netdev.c | 4 +++-
drivers/net/igb/igb_main.c | 4 +++-
drivers/net/ixgb/ixgb_main.c | 4 +++-
drivers/net/ixgbe/ixgbe_main.c | 4 +++-
5 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 8d9269d..a1dacea 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -988,8 +988,10 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
(hw->mac_type != e1000_82547))
netdev->features |= NETIF_F_TSO;
- if (pci_using_dac)
+ if (pci_using_dac) {
netdev->features |= NETIF_F_HIGHDMA;
+ netdev->vlan_features |= NETIF_F_HIGHDMA;
+ }
netdev->vlan_features |= NETIF_F_TSO;
netdev->vlan_features |= NETIF_F_HW_CSUM;
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index e2c7e0d..4630bad 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -5683,8 +5683,10 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
netdev->vlan_features |= NETIF_F_HW_CSUM;
netdev->vlan_features |= NETIF_F_SG;
- if (pci_using_dac)
+ if (pci_using_dac) {
netdev->features |= NETIF_F_HIGHDMA;
+ netdev->vlan_features |= NETIF_F_HIGHDMA;
+ }
if (e1000e_enable_mng_pass_thru(&adapter->hw))
adapter->flags |= FLAG_MNG_PT_ENABLED;
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 61892b8..f915e9c 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -1858,8 +1858,10 @@ static int __devinit igb_probe(struct pci_dev *pdev,
netdev->vlan_features |= NETIF_F_IPV6_CSUM;
netdev->vlan_features |= NETIF_F_SG;
- if (pci_using_dac)
+ if (pci_using_dac) {
netdev->features |= NETIF_F_HIGHDMA;
+ netdev->vlan_features |= NETIF_F_HIGHDMA;
+ }
if (hw->mac.type >= e1000_82576)
netdev->features |= NETIF_F_SCTP_CSUM;
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index c2f6e71..80e6257 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -446,8 +446,10 @@ ixgb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
NETIF_F_HW_VLAN_FILTER;
netdev->features |= NETIF_F_TSO;
- if (pci_using_dac)
+ if (pci_using_dac) {
netdev->features |= NETIF_F_HIGHDMA;
+ netdev->vlan_features |= NETIF_F_HIGHDMA;
+ }
/* make sure the EEPROM is good */
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index d03eef9..0ec4ef2 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -6842,8 +6842,10 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
netdev->vlan_features |= NETIF_F_FCOE_MTU;
}
#endif /* IXGBE_FCOE */
- if (pci_using_dac)
+ if (pci_using_dac) {
netdev->features |= NETIF_F_HIGHDMA;
+ netdev->vlan_features |= NETIF_F_HIGHDMA;
+ }
if (adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED)
netdev->features |= NETIF_F_LRO;
^ permalink raw reply related
* [net-next-2.6 PATCH 2/2] igb: Add support for DH89xxCC
From: Jeff Kirsher @ 2010-09-23 3:56 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Joseph Gasparakis, Jeff Kirsher
In-Reply-To: <20100923035538.11511.16233.stgit@localhost.localdomain>
From: Joseph Gasparakis <joseph.gasparakis@intel.com>
This patch adds support for the Intel(r) DH89xxCC series. The new
device will be using Intel(r) i347-AT4 and Marvell(r) M88E1322 and
M88E1112 PHYs. Support for these devices has also been added here.
Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/igb/e1000_82575.c | 18 +++
drivers/net/igb/e1000_defines.h | 31 ++++++
drivers/net/igb/e1000_hw.h | 2
drivers/net/igb/e1000_phy.c | 206 +++++++++++++++++++++++++++++++++++++--
drivers/net/igb/e1000_phy.h | 2
drivers/net/igb/igb_main.c | 2
6 files changed, 247 insertions(+), 14 deletions(-)
diff --git a/drivers/net/igb/e1000_82575.c b/drivers/net/igb/e1000_82575.c
index 187622f..bc183f5 100644
--- a/drivers/net/igb/e1000_82575.c
+++ b/drivers/net/igb/e1000_82575.c
@@ -132,6 +132,8 @@ static s32 igb_get_invariants_82575(struct e1000_hw *hw)
case E1000_DEV_ID_82580_SERDES:
case E1000_DEV_ID_82580_SGMII:
case E1000_DEV_ID_82580_COPPER_DUAL:
+ case E1000_DEV_ID_DH89XXCC_SGMII:
+ case E1000_DEV_ID_DH89XXCC_SERDES:
mac->type = e1000_82580;
break;
case E1000_DEV_ID_I350_COPPER:
@@ -282,10 +284,18 @@ static s32 igb_get_invariants_82575(struct e1000_hw *hw)
/* Verify phy id and set remaining function pointers */
switch (phy->id) {
+ case I347AT4_E_PHY_ID:
+ case M88E1112_E_PHY_ID:
case M88E1111_I_PHY_ID:
phy->type = e1000_phy_m88;
phy->ops.get_phy_info = igb_get_phy_info_m88;
- phy->ops.get_cable_length = igb_get_cable_length_m88;
+
+ if (phy->id == I347AT4_E_PHY_ID ||
+ phy->id == M88E1112_E_PHY_ID)
+ phy->ops.get_cable_length = igb_get_cable_length_m88_gen2;
+ else
+ phy->ops.get_cable_length = igb_get_cable_length_m88;
+
phy->ops.force_speed_duplex = igb_phy_force_speed_duplex_m88;
break;
case IGP03E1000_E_PHY_ID:
@@ -1058,7 +1068,11 @@ static s32 igb_setup_copper_link_82575(struct e1000_hw *hw)
}
switch (hw->phy.type) {
case e1000_phy_m88:
- ret_val = igb_copper_link_setup_m88(hw);
+ if (hw->phy.id == I347AT4_E_PHY_ID ||
+ hw->phy.id == M88E1112_E_PHY_ID)
+ ret_val = igb_copper_link_setup_m88_gen2(hw);
+ else
+ ret_val = igb_copper_link_setup_m88(hw);
break;
case e1000_phy_igp_3:
ret_val = igb_copper_link_setup_igp(hw);
diff --git a/drivers/net/igb/e1000_defines.h b/drivers/net/igb/e1000_defines.h
index bbd2ec3..6222279 100644
--- a/drivers/net/igb/e1000_defines.h
+++ b/drivers/net/igb/e1000_defines.h
@@ -634,6 +634,8 @@
* E = External
*/
#define M88E1111_I_PHY_ID 0x01410CC0
+#define M88E1112_E_PHY_ID 0x01410C90
+#define I347AT4_E_PHY_ID 0x01410DC0
#define IGP03E1000_E_PHY_ID 0x02A80390
#define I82580_I_PHY_ID 0x015403A0
#define I350_I_PHY_ID 0x015403B0
@@ -702,6 +704,35 @@
#define M88E1000_EPSCR_SLAVE_DOWNSHIFT_1X 0x0100
#define M88E1000_EPSCR_TX_CLK_25 0x0070 /* 25 MHz TX_CLK */
+/* Intel i347-AT4 Registers */
+
+#define I347AT4_PCDL 0x10 /* PHY Cable Diagnostics Length */
+#define I347AT4_PCDC 0x15 /* PHY Cable Diagnostics Control */
+#define I347AT4_PAGE_SELECT 0x16
+
+/* i347-AT4 Extended PHY Specific Control Register */
+
+/*
+ * Number of times we will attempt to autonegotiate before downshifting if we
+ * are the master
+ */
+#define I347AT4_PSCR_DOWNSHIFT_ENABLE 0x0800
+#define I347AT4_PSCR_DOWNSHIFT_MASK 0x7000
+#define I347AT4_PSCR_DOWNSHIFT_1X 0x0000
+#define I347AT4_PSCR_DOWNSHIFT_2X 0x1000
+#define I347AT4_PSCR_DOWNSHIFT_3X 0x2000
+#define I347AT4_PSCR_DOWNSHIFT_4X 0x3000
+#define I347AT4_PSCR_DOWNSHIFT_5X 0x4000
+#define I347AT4_PSCR_DOWNSHIFT_6X 0x5000
+#define I347AT4_PSCR_DOWNSHIFT_7X 0x6000
+#define I347AT4_PSCR_DOWNSHIFT_8X 0x7000
+
+/* i347-AT4 PHY Cable Diagnostics Control */
+#define I347AT4_PCDC_CABLE_LENGTH_UNIT 0x0400 /* 0=cm 1=meters */
+
+/* Marvell 1112 only registers */
+#define M88E1112_VCT_DSP_DISTANCE 0x001A
+
/* M88EC018 Rev 2 specific DownShift settings */
#define M88EC018_EPSCR_DOWNSHIFT_COUNTER_MASK 0x0E00
#define M88EC018_EPSCR_DOWNSHIFT_COUNTER_5X 0x0800
diff --git a/drivers/net/igb/e1000_hw.h b/drivers/net/igb/e1000_hw.h
index cb8db78..c0b017f 100644
--- a/drivers/net/igb/e1000_hw.h
+++ b/drivers/net/igb/e1000_hw.h
@@ -54,6 +54,8 @@ struct e1000_hw;
#define E1000_DEV_ID_82580_SERDES 0x1510
#define E1000_DEV_ID_82580_SGMII 0x1511
#define E1000_DEV_ID_82580_COPPER_DUAL 0x1516
+#define E1000_DEV_ID_DH89XXCC_SGMII 0x0436
+#define E1000_DEV_ID_DH89XXCC_SERDES 0x0438
#define E1000_DEV_ID_I350_COPPER 0x1521
#define E1000_DEV_ID_I350_FIBER 0x1522
#define E1000_DEV_ID_I350_SERDES 0x1523
diff --git a/drivers/net/igb/e1000_phy.c b/drivers/net/igb/e1000_phy.c
index cf1f323..ddd036a 100644
--- a/drivers/net/igb/e1000_phy.c
+++ b/drivers/net/igb/e1000_phy.c
@@ -570,6 +570,89 @@ out:
}
/**
+ * igb_copper_link_setup_m88_gen2 - Setup m88 PHY's for copper link
+ * @hw: pointer to the HW structure
+ *
+ * Sets up MDI/MDI-X and polarity for i347-AT4, m88e1322 and m88e1112 PHY's.
+ * Also enables and sets the downshift parameters.
+ **/
+s32 igb_copper_link_setup_m88_gen2(struct e1000_hw *hw)
+{
+ struct e1000_phy_info *phy = &hw->phy;
+ s32 ret_val;
+ u16 phy_data;
+
+ if (phy->reset_disable) {
+ ret_val = 0;
+ goto out;
+ }
+
+ /* Enable CRS on Tx. This must be set for half-duplex operation. */
+ ret_val = phy->ops.read_reg(hw, M88E1000_PHY_SPEC_CTRL, &phy_data);
+ if (ret_val)
+ goto out;
+
+ /*
+ * Options:
+ * MDI/MDI-X = 0 (default)
+ * 0 - Auto for all speeds
+ * 1 - MDI mode
+ * 2 - MDI-X mode
+ * 3 - Auto for 1000Base-T only (MDI-X for 10/100Base-T modes)
+ */
+ phy_data &= ~M88E1000_PSCR_AUTO_X_MODE;
+
+ switch (phy->mdix) {
+ case 1:
+ phy_data |= M88E1000_PSCR_MDI_MANUAL_MODE;
+ break;
+ case 2:
+ phy_data |= M88E1000_PSCR_MDIX_MANUAL_MODE;
+ break;
+ case 3:
+ /* M88E1112 does not support this mode) */
+ if (phy->id != M88E1112_E_PHY_ID) {
+ phy_data |= M88E1000_PSCR_AUTO_X_1000T;
+ break;
+ }
+ case 0:
+ default:
+ phy_data |= M88E1000_PSCR_AUTO_X_MODE;
+ break;
+ }
+
+ /*
+ * Options:
+ * disable_polarity_correction = 0 (default)
+ * Automatic Correction for Reversed Cable Polarity
+ * 0 - Disabled
+ * 1 - Enabled
+ */
+ phy_data &= ~M88E1000_PSCR_POLARITY_REVERSAL;
+ if (phy->disable_polarity_correction == 1)
+ phy_data |= M88E1000_PSCR_POLARITY_REVERSAL;
+
+ /* Enable downshift and setting it to X6 */
+ phy_data &= ~I347AT4_PSCR_DOWNSHIFT_MASK;
+ phy_data |= I347AT4_PSCR_DOWNSHIFT_6X;
+ phy_data |= I347AT4_PSCR_DOWNSHIFT_ENABLE;
+
+ ret_val = phy->ops.write_reg(hw, M88E1000_PHY_SPEC_CTRL, phy_data);
+ if (ret_val)
+ goto out;
+
+ /* Commit the changes. */
+ ret_val = igb_phy_sw_reset(hw);
+ if (ret_val) {
+ hw_dbg("Error committing the PHY changes\n");
+ goto out;
+ }
+
+out:
+ return ret_val;
+}
+
+/**
* igb_copper_link_setup_igp - Setup igp PHY's for copper link
* @hw: pointer to the HW structure
*
@@ -1124,18 +1207,25 @@ s32 igb_phy_force_speed_duplex_m88(struct e1000_hw *hw)
goto out;
if (!link) {
- /*
- * We didn't get link.
- * Reset the DSP and cross our fingers.
- */
- ret_val = phy->ops.write_reg(hw,
- M88E1000_PHY_PAGE_SELECT,
- 0x001d);
- if (ret_val)
- goto out;
- ret_val = igb_phy_reset_dsp(hw);
- if (ret_val)
- goto out;
+ if (hw->phy.type != e1000_phy_m88 ||
+ hw->phy.id == I347AT4_E_PHY_ID ||
+ hw->phy.id == M88E1112_E_PHY_ID) {
+ hw_dbg("Link taking longer than expected.\n");
+ } else {
+
+ /*
+ * We didn't get link.
+ * Reset the DSP and cross our fingers.
+ */
+ ret_val = phy->ops.write_reg(hw,
+ M88E1000_PHY_PAGE_SELECT,
+ 0x001d);
+ if (ret_val)
+ goto out;
+ ret_val = igb_phy_reset_dsp(hw);
+ if (ret_val)
+ goto out;
+ }
}
/* Try once more */
@@ -1145,6 +1235,11 @@ s32 igb_phy_force_speed_duplex_m88(struct e1000_hw *hw)
goto out;
}
+ if (hw->phy.type != e1000_phy_m88 ||
+ hw->phy.id == I347AT4_E_PHY_ID ||
+ hw->phy.id == M88E1112_E_PHY_ID)
+ goto out;
+
ret_val = phy->ops.read_reg(hw, M88E1000_EXT_PHY_SPEC_CTRL, &phy_data);
if (ret_val)
goto out;
@@ -1557,6 +1652,93 @@ out:
return ret_val;
}
+s32 igb_get_cable_length_m88_gen2(struct e1000_hw *hw)
+{
+ struct e1000_phy_info *phy = &hw->phy;
+ s32 ret_val;
+ u16 phy_data, phy_data2, index, default_page, is_cm;
+
+ switch (hw->phy.id) {
+ case I347AT4_E_PHY_ID:
+ /* Remember the original page select and set it to 7 */
+ ret_val = phy->ops.read_reg(hw, I347AT4_PAGE_SELECT,
+ &default_page);
+ if (ret_val)
+ goto out;
+
+ ret_val = phy->ops.write_reg(hw, I347AT4_PAGE_SELECT, 0x07);
+ if (ret_val)
+ goto out;
+
+ /* Get cable length from PHY Cable Diagnostics Control Reg */
+ ret_val = phy->ops.read_reg(hw, (I347AT4_PCDL + phy->addr),
+ &phy_data);
+ if (ret_val)
+ goto out;
+
+ /* Check if the unit of cable length is meters or cm */
+ ret_val = phy->ops.read_reg(hw, I347AT4_PCDC, &phy_data2);
+ if (ret_val)
+ goto out;
+
+ is_cm = !(phy_data & I347AT4_PCDC_CABLE_LENGTH_UNIT);
+
+ /* Populate the phy structure with cable length in meters */
+ phy->min_cable_length = phy_data / (is_cm ? 100 : 1);
+ phy->max_cable_length = phy_data / (is_cm ? 100 : 1);
+ phy->cable_length = phy_data / (is_cm ? 100 : 1);
+
+ /* Reset the page selec to its original value */
+ ret_val = phy->ops.write_reg(hw, I347AT4_PAGE_SELECT,
+ default_page);
+ if (ret_val)
+ goto out;
+ break;
+ case M88E1112_E_PHY_ID:
+ /* Remember the original page select and set it to 5 */
+ ret_val = phy->ops.read_reg(hw, I347AT4_PAGE_SELECT,
+ &default_page);
+ if (ret_val)
+ goto out;
+
+ ret_val = phy->ops.write_reg(hw, I347AT4_PAGE_SELECT, 0x05);
+ if (ret_val)
+ goto out;
+
+ ret_val = phy->ops.read_reg(hw, M88E1112_VCT_DSP_DISTANCE,
+ &phy_data);
+ if (ret_val)
+ goto out;
+
+ index = (phy_data & M88E1000_PSSR_CABLE_LENGTH) >>
+ M88E1000_PSSR_CABLE_LENGTH_SHIFT;
+ if (index >= M88E1000_CABLE_LENGTH_TABLE_SIZE - 1) {
+ ret_val = -E1000_ERR_PHY;
+ goto out;
+ }
+
+ phy->min_cable_length = e1000_m88_cable_length_table[index];
+ phy->max_cable_length = e1000_m88_cable_length_table[index + 1];
+
+ phy->cable_length = (phy->min_cable_length +
+ phy->max_cable_length) / 2;
+
+ /* Reset the page select to its original value */
+ ret_val = phy->ops.write_reg(hw, I347AT4_PAGE_SELECT,
+ default_page);
+ if (ret_val)
+ goto out;
+
+ break;
+ default:
+ ret_val = -E1000_ERR_PHY;
+ goto out;
+ }
+
+out:
+ return ret_val;
+}
+
/**
* igb_get_cable_length_igp_2 - Determine cable length for igp2 PHY
* @hw: pointer to the HW structure
diff --git a/drivers/net/igb/e1000_phy.h b/drivers/net/igb/e1000_phy.h
index 565a6db..2cc1177 100644
--- a/drivers/net/igb/e1000_phy.h
+++ b/drivers/net/igb/e1000_phy.h
@@ -45,9 +45,11 @@ s32 igb_check_downshift(struct e1000_hw *hw);
s32 igb_check_reset_block(struct e1000_hw *hw);
s32 igb_copper_link_setup_igp(struct e1000_hw *hw);
s32 igb_copper_link_setup_m88(struct e1000_hw *hw);
+s32 igb_copper_link_setup_m88_gen2(struct e1000_hw *hw);
s32 igb_phy_force_speed_duplex_igp(struct e1000_hw *hw);
s32 igb_phy_force_speed_duplex_m88(struct e1000_hw *hw);
s32 igb_get_cable_length_m88(struct e1000_hw *hw);
+s32 igb_get_cable_length_m88_gen2(struct e1000_hw *hw);
s32 igb_get_cable_length_igp_2(struct e1000_hw *hw);
s32 igb_get_phy_id(struct e1000_hw *hw);
s32 igb_get_phy_info_igp(struct e1000_hw *hw);
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index fd922e7..61892b8 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -71,6 +71,8 @@ static DEFINE_PCI_DEVICE_TABLE(igb_pci_tbl) = {
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_82580_SERDES), board_82575 },
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_82580_SGMII), board_82575 },
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_82580_COPPER_DUAL), board_82575 },
+ { PCI_VDEVICE(INTEL, E1000_DEV_ID_DH89XXCC_SGMII), board_82575 },
+ { PCI_VDEVICE(INTEL, E1000_DEV_ID_DH89XXCC_SERDES), board_82575 },
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_82576), board_82575 },
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_82576_NS), board_82575 },
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_82576_NS_SERDES), board_82575 },
^ permalink raw reply related
* [net-next-2.6 PATCH 1/2] igb: clear VF_PROMISC bits instead of setting all other bits
From: Jeff Kirsher @ 2010-09-23 3:56 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Alexander Duyck, Jeff Kirsher
From: Alexander Duyck <alexander.h.duyck@intel.com>
This change corrects an issue in which we were setting all flag bits except
for promisc instead of clearing the promisc bits due to the incorrect use
of an |= instead of an &=.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/igb/igb_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index c4d861b..fd922e7 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -4659,12 +4659,13 @@ static int igb_set_vf_promisc(struct igb_adapter *adapter, u32 *msgbuf, u32 vf)
u32 vmolr = rd32(E1000_VMOLR(vf));
struct vf_data_storage *vf_data = &adapter->vf_data[vf];
- vf_data->flags |= ~(IGB_VF_FLAG_UNI_PROMISC |
+ vf_data->flags &= ~(IGB_VF_FLAG_UNI_PROMISC |
IGB_VF_FLAG_MULTI_PROMISC);
vmolr &= ~(E1000_VMOLR_ROPE | E1000_VMOLR_ROMPE | E1000_VMOLR_MPME);
if (*msgbuf & E1000_VF_SET_PROMISC_MULTICAST) {
vmolr |= E1000_VMOLR_MPME;
+ vf_data->flags |= IGB_VF_FLAG_MULTI_PROMISC;
*msgbuf &= ~E1000_VF_SET_PROMISC_MULTICAST;
} else {
/*
^ permalink raw reply related
* Re: [PATCH] net: fix a lockdep splat
From: David Miller @ 2010-09-23 3:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: jarkao2, penguin-kernel, linux-fsdevel, netdev
In-Reply-To: <1285195419.2380.39.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 23 Sep 2010 00:43:39 +0200
> (A) (this is used in net/sunrpc/xprtsock.c)
> read_lock(&sk->sk_callback_lock) (without blocking BH)
> <BH>
> spin_lock(&sk->sk_slock.slock);
> ...
> read_lock(&sk->sk_callback_lock);
> ...
What's the exact path that leads to this? I looked quickly and couldn't
find which sunrpc callback override does it.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/6] netfilter: netfilter fixes
From: Patrick McHardy @ 2010-09-23 3:49 UTC (permalink / raw)
To: David Miller; +Cc: netfilter-devel, netdev
In-Reply-To: <20100922.131232.59680750.davem@davemloft.net>
Am 22.09.2010 22:12, schrieb David Miller:
> From: kaber@trash.net
> Date: Wed, 22 Sep 2010 09:17:28 +0200
>
>> Please apply or pull from:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
>
> Patrick I can't pull from this, it's not based upon net-2.6
Indeed, that's what I've always based my nf-2.6 tree on for one
or two years now, but this time I made a fresh clone at a quite
late time because of my absence.
> It looks like it's based upon Linus's tree, because when I pull
> I get a bunch of changes that are in Linus's tree but aren't
> in net-2.6
I didn't notice that, sorry.
> Please base all future pull requests on net-2.6, thanks.
Sure, will do.
> I'll apply these patches by hand (and also this will allow me
> to fix Eric's author email in that one patch).
>
> Thanks again.
Thanks Dave!
^ permalink raw reply
* Re: [net-next-2.6 RFC PATCH] e1000e: NUMA changes, add Node= parameter
From: David Miller @ 2010-09-23 3:36 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, jesse.brandeburg
In-Reply-To: <20100923032534.11274.77976.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 22 Sep 2010 20:28:10 -0700
> Although a module parameter is not the preferred way for
> in-tree modules, this problem is not solvable in ethtool without
> mod params because of needing the information at probe time to
> control early allocations of memory. Ideally there would even be
> a way to control the node where the memory of the netdev struct
> would be allocated also.
Sorry, no.
Various folks are working on infrastructure such that the Numa node of
everything other than the netdev struct can be dynamically choosen.
I'm sure we can find a way to dynamically reallocate and re-attach the
netdev structure as well.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox