* [PATCH] net: emaclite: Use resource_size
From: Tobias Klauser @ 2010-05-06 8:12 UTC (permalink / raw)
To: netdev, davem; +Cc: john.linn, kernel-janitors, Tobias Klauser
Use the resource_size function instead of manually calculating the
resource size. This reduces the chance of introducing off-by-one
errors.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/xilinx_emaclite.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index e9381fe..93828d5 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -1171,7 +1171,7 @@ static int __devinit xemaclite_of_probe(struct of_device *ofdev,
}
/* Get the virtual base address for the device */
- lp->base_addr = ioremap(r_mem.start, r_mem.end - r_mem.start + 1);
+ lp->base_addr = ioremap(r_mem.start, resource_size(&r_mem));
if (NULL == lp->base_addr) {
dev_err(dev, "EmacLite: Could not allocate iomem\n");
rc = -EIO;
@@ -1224,7 +1224,7 @@ static int __devinit xemaclite_of_probe(struct of_device *ofdev,
return 0;
error1:
- release_mem_region(ndev->mem_start, r_mem.end - r_mem.start + 1);
+ release_mem_region(ndev->mem_start, resource_size(&r_mem));
error2:
xemaclite_remove_ndev(ndev);
--
1.6.3.3
^ permalink raw reply related
* [PATCH] netpoll: Use 'bool' for netpoll_rx() return type.
From: David Miller @ 2010-05-06 8:20 UTC (permalink / raw)
To: netdev
Signed-off-by: David S. Miller <davem@davemloft.net>
---
I noticed this while validating and auditing Eric Dumazet's vnet
fix... applied to net-next-2.6
include/linux/netpoll.h | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/netpoll.h b/include/linux/netpoll.h
index 017e604..3688c83 100644
--- a/include/linux/netpoll.h
+++ b/include/linux/netpoll.h
@@ -55,19 +55,19 @@ void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb);
#ifdef CONFIG_NETPOLL
-static inline int netpoll_rx(struct sk_buff *skb)
+static inline bool netpoll_rx(struct sk_buff *skb)
{
struct netpoll_info *npinfo = skb->dev->npinfo;
unsigned long flags;
- int ret = 0;
+ int ret = false;
if (!npinfo || (list_empty(&npinfo->rx_np) && !npinfo->rx_flags))
- return 0;
+ return false;
spin_lock_irqsave(&npinfo->rx_lock, flags);
/* check rx_flags again with the lock held */
if (npinfo->rx_flags && __netpoll_rx(skb))
- ret = 1;
+ ret = true;
spin_unlock_irqrestore(&npinfo->rx_lock, flags);
return ret;
--
1.7.0.4
^ permalink raw reply related
* Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Gleb Natapov @ 2010-05-06 8:19 UTC (permalink / raw)
To: Pankaj Thakkar
Cc: Christoph Hellwig, Dmitry Torokhov, pv-drivers@vmware.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
In-Reply-To: <F1354E79A137A24CBA60059AA65CB1B802A235C535@EXCH-MBX-2.vmware.com>
On Wed, May 05, 2010 at 10:47:10AM -0700, Pankaj Thakkar wrote:
>
>
> > -----Original Message-----
> > From: Christoph Hellwig [mailto:hch@infradead.org]
> > Sent: Wednesday, May 05, 2010 10:40 AM
> > To: Dmitry Torokhov
> > Cc: Christoph Hellwig; pv-drivers@vmware.com; Pankaj Thakkar;
> > netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> > virtualization@lists.linux-foundation.org
> > Subject: Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for
> > vmxnet3
> >
> > On Wed, May 05, 2010 at 10:35:28AM -0700, Dmitry Torokhov wrote:
> > > Yes, with the exception that the only body of code that will be
> > > accepted by the shell should be GPL-licensed and thus open and
> > available
> > > for examining. This is not different from having a standard kernel
> > > module that is loaded normally and plugs into a certain subsystem.
> > > The difference is that the binary resides not on guest filesystem
> > > but elsewhere.
> >
> > Forget about the licensing. Loading binary blobs written to a shim
> > layer is a complete pain in the ass and totally unsupportable, and
> > also uninteresting because of the overhead.
>
> [PT] Why do you think it is unsupportable? How different is it from any module
> written against a well maintained interface? What overhead are you talking about?
>
Overhead of interpreting bytecode plugin is written in. Or are you
saying plugin is x86 assembly (32bit or 64bit btw?) and other arches
will have to have in kernel x86 emulator to use the plugin (like some
of them had for vgabios)?
--
Gleb.
^ permalink raw reply
* Re: [PATCH net-next-2.6] rps: consistent rxhash
From: David Miller @ 2010-05-06 8:06 UTC (permalink / raw)
To: therbert; +Cc: eric.dumazet, franco, xiaosuo, netdev
In-Reply-To: <g2m65634d661004211212t13714cccyd27936c520515684@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Wed, 21 Apr 2010 12:12:41 -0700
> On Tue, Apr 20, 2010 at 2:41 PM, David Miller <davem@davemloft.net> wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Tue, 20 Apr 2010 16:57:01 +0200
>>
>>> I know many applications using TCP on loopback, they are real :)
>>
>> This is all true and I support your hashing patch and all of that.
>>
>> But if we really want TCP over loopback to go fast, there are much
>> better ways to do this.
>>
>> Eric, do you remember that "TCP friends" rough patch I sent you last
>> year that essentailly made TCP sockets over loopback behave like
>> AF_UNIX ones and just queue the SKBs directly to the destination
>> socket without doing any protocol work?
>>
> This is sounds very interesting! Could you post a patch? :-)
I was finally able to unearth a copy, it's completely raw, it's at least
a year old, and it's not fully implemented at all.
But you asked for it :-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 299ec4b..7f855d3 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -206,6 +206,7 @@ typedef unsigned char *sk_buff_data_t;
* @mac_header: Link layer header
* @dst: destination entry
* @sp: the security path, used for xfrm
+ * @friend: loopback friend socket
* @cb: Control buffer. Free for use by every layer. Put private vars here
* @len: Length of actual data
* @data_len: Data length
@@ -262,6 +263,7 @@ struct sk_buff {
struct rtable *rtable;
};
struct sec_path *sp;
+ struct sock *friend;
/*
* This is the control buffer. It is free to use for every
diff --git a/include/net/request_sock.h b/include/net/request_sock.h
index b220b5f..52b2f7a 100644
--- a/include/net/request_sock.h
+++ b/include/net/request_sock.h
@@ -53,6 +53,7 @@ struct request_sock {
unsigned long expires;
const struct request_sock_ops *rsk_ops;
struct sock *sk;
+ struct sock *friend;
u32 secid;
u32 peer_secid;
};
diff --git a/include/net/sock.h b/include/net/sock.h
index dc42b44..3e86190 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -137,6 +137,7 @@ struct sock_common {
* @sk_userlocks: %SO_SNDBUF and %SO_RCVBUF settings
* @sk_lock: synchronizer
* @sk_rcvbuf: size of receive buffer in bytes
+ * @sk_friend: loopback friend socket
* @sk_sleep: sock wait queue
* @sk_dst_cache: destination cache
* @sk_dst_lock: destination cache lock
@@ -227,6 +228,7 @@ struct sock {
struct sk_buff *head;
struct sk_buff *tail;
} sk_backlog;
+ struct sock *sk_friend;
wait_queue_head_t *sk_sleep;
struct dst_entry *sk_dst_cache;
struct xfrm_policy *sk_policy[2];
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 4fe605f..0eef90a 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -435,6 +435,7 @@ static void __copy_skb_header(struct sk_buff *new, const struct sk_buff *old)
#ifdef CONFIG_INET
new->sp = secpath_get(old->sp);
#endif
+ new->friend = old->friend;
memcpy(new->cb, old->cb, sizeof(old->cb));
new->csum_start = old->csum_start;
new->csum_offset = old->csum_offset;
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 828ea21..375dc2e 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -503,6 +503,8 @@ struct sock *inet_csk_clone(struct sock *sk, const struct request_sock *req,
if (newsk != NULL) {
struct inet_connection_sock *newicsk = inet_csk(newsk);
+ newsk->sk_friend = req->friend;
+
newsk->sk_state = TCP_SYN_RECV;
newicsk->icsk_bind_hash = NULL;
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 58ac838..042ee1d 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -474,7 +474,8 @@ static inline int forced_push(struct tcp_sock *tp)
return after(tp->write_seq, tp->pushed_seq + (tp->max_window >> 1));
}
-static inline void skb_entail(struct sock *sk, struct sk_buff *skb)
+static inline void skb_entail(struct sock *sk, struct sk_buff *skb,
+ struct sk_buff_head *friend_queue)
{
struct tcp_sock *tp = tcp_sk(sk);
struct tcp_skb_cb *tcb = TCP_SKB_CB(skb);
@@ -484,7 +485,10 @@ static inline void skb_entail(struct sock *sk, struct sk_buff *skb)
tcb->flags = TCPCB_FLAG_ACK;
tcb->sacked = 0;
skb_header_release(skb);
- tcp_add_write_queue_tail(sk, skb);
+ if (sk->sk_friend)
+ __skb_queue_tail(friend_queue, skb);
+ else
+ tcp_add_write_queue_tail(sk, skb);
sk->sk_wmem_queued += skb->truesize;
sk_mem_charge(sk, skb->truesize);
if (tp->nonagle & TCP_NAGLE_PUSH)
@@ -501,7 +505,7 @@ static inline void tcp_mark_urg(struct tcp_sock *tp, int flags,
}
static inline void tcp_push(struct sock *sk, int flags, int mss_now,
- int nonagle)
+ int nonagle, struct sk_buff_head *friend_queue)
{
struct tcp_sock *tp = tcp_sk(sk);
@@ -512,6 +516,19 @@ static inline void tcp_push(struct sock *sk, int flags, int mss_now,
tcp_mark_urg(tp, flags, skb);
__tcp_push_pending_frames(sk, mss_now,
(flags & MSG_MORE) ? TCP_NAGLE_CORK : nonagle);
+ } else if (sk->sk_friend) {
+ struct sock *friend = sk->sk_friend;
+ struct sk_buff *skb;
+ unsigned int len;
+
+ spin_lock_bh(&friend->sk_lock.slock);
+ len = 0;
+ while ((skb = __skb_dequeue(friend_queue)) != NULL) {
+ len += skb->len;
+ __skb_queue_tail(&sk->sk_receive_queue, skb);
+ }
+ sk->sk_data_ready(friend, len);
+ spin_unlock_bh(&friend->sk_lock.slock);
}
}
@@ -658,6 +675,7 @@ static ssize_t do_tcp_sendpages(struct sock *sk, struct page **pages, int poffse
size_t psize, int flags)
{
struct tcp_sock *tp = tcp_sk(sk);
+ struct sk_buff_head friend_queue;
int mss_now, size_goal;
int err;
ssize_t copied;
@@ -674,6 +692,8 @@ static ssize_t do_tcp_sendpages(struct sock *sk, struct page **pages, int poffse
size_goal = tp->xmit_size_goal;
copied = 0;
+ skb_queue_head_init(&friend_queue);
+
err = -EPIPE;
if (sk->sk_err || (sk->sk_shutdown & SEND_SHUTDOWN))
goto do_error;
@@ -694,7 +714,7 @@ new_segment:
if (!skb)
goto wait_for_memory;
- skb_entail(sk, skb);
+ skb_entail(sk, skb, &friend_queue);
copy = size_goal;
}
@@ -749,7 +769,8 @@ wait_for_sndbuf:
set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
wait_for_memory:
if (copied)
- tcp_push(sk, flags & ~MSG_MORE, mss_now, TCP_NAGLE_PUSH);
+ tcp_push(sk, flags & ~MSG_MORE, mss_now, TCP_NAGLE_PUSH,
+ &friend_queue);
if ((err = sk_stream_wait_memory(sk, &timeo)) != 0)
goto do_error;
@@ -760,7 +781,7 @@ wait_for_memory:
out:
if (copied)
- tcp_push(sk, flags, mss_now, tp->nonagle);
+ tcp_push(sk, flags, mss_now, tp->nonagle, &friend_queue);
return copied;
do_error:
@@ -817,6 +838,7 @@ int tcp_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg,
struct sock *sk = sock->sk;
struct iovec *iov;
struct tcp_sock *tp = tcp_sk(sk);
+ struct sk_buff_head friend_queue;
struct sk_buff *skb;
int iovlen, flags;
int mss_now, size_goal;
@@ -849,6 +871,7 @@ int tcp_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg,
if (sk->sk_err || (sk->sk_shutdown & SEND_SHUTDOWN))
goto do_error;
+ skb_queue_head_init(&friend_queue);
while (--iovlen >= 0) {
int seglen = iov->iov_len;
unsigned char __user *from = iov->iov_base;
@@ -881,7 +904,7 @@ new_segment:
if (sk->sk_route_caps & NETIF_F_ALL_CSUM)
skb->ip_summed = CHECKSUM_PARTIAL;
- skb_entail(sk, skb);
+ skb_entail(sk, skb, &friend_queue);
copy = size_goal;
}
@@ -995,7 +1018,8 @@ wait_for_sndbuf:
set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
wait_for_memory:
if (copied)
- tcp_push(sk, flags & ~MSG_MORE, mss_now, TCP_NAGLE_PUSH);
+ tcp_push(sk, flags & ~MSG_MORE, mss_now,
+ TCP_NAGLE_PUSH, &friend_queue);
if ((err = sk_stream_wait_memory(sk, &timeo)) != 0)
goto do_error;
@@ -1007,7 +1031,7 @@ wait_for_memory:
out:
if (copied)
- tcp_push(sk, flags, mss_now, tp->nonagle);
+ tcp_push(sk, flags, mss_now, tp->nonagle, &friend_queue);
TCP_CHECK_TIMER(sk);
release_sock(sk);
return copied;
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index cdc051b..eb6f914 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4998,6 +4998,7 @@ static int tcp_rcv_synsent_state_process(struct sock *sk, struct sk_buff *skb,
* state to ESTABLISHED..."
*/
+ sk->sk_friend = skb->friend;
TCP_ECN_rcv_synack(tp, th);
tp->snd_wl1 = TCP_SKB_CB(skb)->seq;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 7766151..4d91ff4 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1289,6 +1289,7 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
if (!req)
goto drop;
+ req->friend = skb->friend;
#ifdef CONFIG_TCP_MD5SIG
tcp_rsk(req)->af_specific = &tcp_request_sock_ipv4_ops;
#endif
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index debf235..a4d4c14 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -577,6 +577,7 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
}
if (unlikely(tcb->flags & TCPCB_FLAG_SYN)) {
+ skb->friend = sk;
tcp_syn_build_options((__be32 *)(th + 1),
tcp_advertise_mss(sk),
(sysctl_flags & SYSCTL_FLAG_TSTAMPS),
@@ -1006,6 +1007,8 @@ unsigned int tcp_current_mss(struct sock *sk, int large_allowed)
xmit_size_goal = tcp_bound_to_half_wnd(tp, xmit_size_goal);
xmit_size_goal -= (xmit_size_goal % mss_now);
}
+ if (sk->sk_friend)
+ xmit_size_goal = ~(u16)0;
tp->xmit_size_goal = xmit_size_goal;
return mss_now;
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 715965f..c79d3ea 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1280,6 +1280,7 @@ static int tcp_v6_conn_request(struct sock *sk, struct sk_buff *skb)
if (req == NULL)
goto drop;
+ req->friend = skb->friend;
#ifdef CONFIG_TCP_MD5SIG
tcp_rsk(req)->af_specific = &tcp_request_sock_ipv6_ops;
#endif
^ permalink raw reply related
* Re: [PATCH 4/4 v2] ks8851: read/write MAC address on companion eeprom through debugfs
From: Sebastien Jan @ 2010-05-06 8:01 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, linux-omap@vger.kernel.org, Arce, Abraham,
ben-linux@fluff.org, Tristram.Ha@micrel.com
In-Reply-To: <20100506.002508.241926083.davem@davemloft.net>
Hi david,
On Thursday 06 May 2010 09:25:08 David Miller wrote:
> From: Sebastien Jan <s-jan@ti.com>
> Date: Wed, 5 May 2010 20:45:55 +0200
>
> > A more elegant alternative to ethtool for updating the ks8851
> > MAC address stored on its companion eeprom.
> > Using this debugfs interface does not require any knowledge on the
> > ks8851 companion eeprom organization to update the MAC address.
> >
> > Example to write 01:23:45:67:89:AB MAC address to the companion
> > eeprom (assuming debugfs is mounted in /sys/kernel/debug):
> > $ echo "01:23:45:67:89:AB" > /sys/kernel/debug/ks8851/mac_eeprom
> >
> > Signed-off-by: Sebastien Jan <s-jan@ti.com>
>
> Elegant? This commit message is the biggest lie ever told.
>
> What makes your ethernet driver so god-damn special that it deserves
> to have a private, completely unique, and obscure interface for
> setting the permanent ethernet address of a network device?
>
> Tell me how damn elegant it is that users have to learn about this
> special, unique, and common with no other driver, interface for
> performing this task?
>
> Tell me how damn elegant it is when another driver wants to provide
> users with a way to do this too, and they (like you) come up with
> their own unique and different interface for doing this.
>
> No, this is the most inelegant patch ever conceived because it totally
> ignores the way in which we handle issues like this.
>
> There is no way in the world I'm applying this garbage patch, sorry.
>
> We have an ETHTOOL_GPERMADDR, add a new ETHTOOL_SPERMADDR operation
> and then any driver (not just your's) can portably provide this
> facility and users will have one, and only one, way of performing this
> task.
>
I agree that my commit message was probably too provocative, sorry for that.
Thank you for shedding some light on ETHTOOL_GPERMADDR and ETHTOOL_SPERMADDR.
I will look into these interfaces for a proper and generic implementation.
^ permalink raw reply
* [net-next-2.6 PATCH 2/2] e1000e: Reset 82577/82578 PHY before first PHY register read
From: Jeff Kirsher @ 2010-05-06 8:00 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Bruce Allan, Jeff Kirsher
In-Reply-To: <20100506075959.8910.13493.stgit@localhost.localdomain>
From: Bruce Allan <bruce.w.allan@intel.com>
Reset the PHY before first accessing it. Doing so, ensure that the PHY is
in a known good state before we read/write PHY registers. This fixes a
driver probe failure.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/ich8lan.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c
index 0bfef8e..b8c4dce 100644
--- a/drivers/net/e1000e/ich8lan.c
+++ b/drivers/net/e1000e/ich8lan.c
@@ -294,6 +294,16 @@ static s32 e1000_init_phy_params_pchlan(struct e1000_hw *hw)
msleep(50);
}
+ /*
+ * Reset the PHY before any acccess to it. Doing so, ensures that
+ * the PHY is in a known good state before we read/write PHY registers.
+ * The generic reset is sufficient here, because we haven't determined
+ * the PHY type yet.
+ */
+ ret_val = e1000e_phy_hw_reset_generic(hw);
+ if (ret_val)
+ goto out;
+
phy->id = e1000_phy_unknown;
ret_val = e1000e_get_phy_id(hw);
if (ret_val)
^ permalink raw reply related
* [net-next-2.6 PATCH 1/2] e1000e: reset MAC-PHY interconnect on 82577/82578 during Sx->S0
From: Jeff Kirsher @ 2010-05-06 8:00 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Bruce Allan, Jeff Kirsher
From: Bruce Allan <bruce.w.allan@intel.com>
During Sx->S0 transitions, the interconnect between the MAC and PHY on
82577/82578 can remain in SMBus mode instead of transitioning to the
PCIe-like mode required during normal operation. Toggling the LANPHYPC
Value bit essentially resets the interconnect forcing it to the correct
mode.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/defines.h | 2 ++
drivers/net/e1000e/ich8lan.c | 20 ++++++++++++++++++++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000e/defines.h b/drivers/net/e1000e/defines.h
index e301e26..7f760aa 100644
--- a/drivers/net/e1000e/defines.h
+++ b/drivers/net/e1000e/defines.h
@@ -214,6 +214,8 @@
#define E1000_CTRL_SPD_1000 0x00000200 /* Force 1Gb */
#define E1000_CTRL_FRCSPD 0x00000800 /* Force Speed */
#define E1000_CTRL_FRCDPX 0x00001000 /* Force Duplex */
+#define E1000_CTRL_LANPHYPC_OVERRIDE 0x00010000 /* SW control of LANPHYPC */
+#define E1000_CTRL_LANPHYPC_VALUE 0x00020000 /* SW value of LANPHYPC */
#define E1000_CTRL_SWDPIN0 0x00040000 /* SWDPIN 0 value */
#define E1000_CTRL_SWDPIN1 0x00080000 /* SWDPIN 1 value */
#define E1000_CTRL_SWDPIO0 0x00400000 /* SWDPIN 0 Input or output */
diff --git a/drivers/net/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c
index 5059c22..0bfef8e 100644
--- a/drivers/net/e1000e/ich8lan.c
+++ b/drivers/net/e1000e/ich8lan.c
@@ -83,6 +83,8 @@
#define E1000_ICH_FWSM_RSPCIPHY 0x00000040 /* Reset PHY on PCI Reset */
+/* FW established a valid mode */
+#define E1000_ICH_FWSM_FW_VALID 0x00008000
#define E1000_ICH_MNG_IAMT_MODE 0x2
@@ -259,6 +261,7 @@ static inline void __ew32flash(struct e1000_hw *hw, unsigned long reg, u32 val)
static s32 e1000_init_phy_params_pchlan(struct e1000_hw *hw)
{
struct e1000_phy_info *phy = &hw->phy;
+ u32 ctrl;
s32 ret_val = 0;
phy->addr = 1;
@@ -274,6 +277,23 @@ static s32 e1000_init_phy_params_pchlan(struct e1000_hw *hw)
phy->ops.power_down = e1000_power_down_phy_copper_ich8lan;
phy->autoneg_mask = AUTONEG_ADVERTISE_SPEED_DEFAULT;
+ if (!(er32(FWSM) & E1000_ICH_FWSM_FW_VALID)) {
+ /*
+ * The MAC-PHY interconnect may still be in SMBus mode
+ * after Sx->S0. Toggle the LANPHYPC Value bit to force
+ * the interconnect to PCIe mode, but only if there is no
+ * firmware present otherwise firmware will have done it.
+ */
+ ctrl = er32(CTRL);
+ ctrl |= E1000_CTRL_LANPHYPC_OVERRIDE;
+ ctrl &= ~E1000_CTRL_LANPHYPC_VALUE;
+ ew32(CTRL, ctrl);
+ udelay(10);
+ ctrl &= ~E1000_CTRL_LANPHYPC_OVERRIDE;
+ ew32(CTRL, ctrl);
+ msleep(50);
+ }
+
phy->id = e1000_phy_unknown;
ret_val = e1000e_get_phy_id(hw);
if (ret_val)
^ permalink raw reply related
* Re: [PATCH v2] sctp: Fix a race between ICMP protocol unreachable and connect()
From: David Miller @ 2010-05-06 7:56 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: netdev, linux-sctp
In-Reply-To: <1273088166-18391-1-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Wed, 5 May 2010 15:36:06 -0400
> ICMP protocol unreachable handling completely disregarded
> the fact that the user may have locket the socket. It proceeded
> to destroy the association, even though the user may have
> held the lock and had a ref on the association. This resulted
> in the following:
>
> Attempt to release alive inet socket f6afcc00
...
> This was because the sctp_wait_for_connect() would aqcure the socket
> lock and then proceed to release the last reference count on the
> association, thus cause the fully destruction path to finish freeing
> the socket.
>
> The simplest solution is to start a very short timer in case the socket
> is owned by user. When the timer expires, we can do some verification
> and be able to do the release properly.
>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied and queued up for -stable, thanks Vlad.
^ permalink raw reply
* Re: kernel panic when using netns+bridges+tc(netem)
From: David Miller @ 2010-05-06 7:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: martin.ferrari, arnd, netdev, mathieu.lacage
In-Reply-To: <1273129187.2304.14.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 06 May 2010 08:59:47 +0200
> David, this is a stable candidate, once tested and acked, thanks !
>
> [PATCH] veth: Dont kfree_skb() after dev_forward_skb()
>
> In case of congestion, netif_rx() frees the skb, so we must assume
> dev_forward_skb() also consume skb.
>
> Bug introduced by commit 445409602c092
> (veth: move loopback logic to common location)
>
> We must change dev_forward_skb() to always consume skb, and veth to not
> double free it.
>
> Bug report : http://marc.info/?l=linux-netdev&m=127310770900442&w=3
>
> Reported-by: Martín Ferrari <martin.ferrari@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Ugh, applied and queued up for -stable, thanks Eric!
^ permalink raw reply
* Re: [v5 Patch 1/3] netpoll: add generic support for bridge and bonding devices
From: David Miller @ 2010-05-06 7:44 UTC (permalink / raw)
To: mpm
Cc: amwang, linux-kernel, netdev, bridge, gospo, nhorman, jmoyer,
shemminger, bonding-devel, fubar
In-Reply-To: <1273111530.21962.2753.camel@calx>
From: Matt Mackall <mpm@selenic.com>
Date: Wed, 05 May 2010 21:05:30 -0500
> On Wed, 2010-05-05 at 04:11 -0400, Amerigo Wang wrote:
>> V5:
>> Fix coding style problems pointed by David.
>
> Aside from my concern about the policy of disabling netpoll on
> bridges/bonds with only partial netpoll support, I don't have any
> remaining issues with this. But I'll leave it to other folks to ack the
> underlying driver bits for this series.
Yes the partial support handling is a thorny issue.
But this patch set makes things better than they were before, because
support over such devices didn't work at all previously.
So I'll toss these patches into net-next-2.6, thanks everyone!
^ permalink raw reply
* Re: [net-next-2.6 PATCH] igb: reduce cache misses on tx cleanup
From: David Miller @ 2010-05-06 7:36 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, nicholasx.d.nunley
In-Reply-To: <20100505075733.5474.37834.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 05 May 2010 00:58:07 -0700
> From: Nick Nunley <nicholasx.d.nunley@intel.com>
>
> This patch reduces the number of skb cache misses in the
> clean_tx_irq path, and results in an overall increase
> in tx packet throughput.
>
> Signed-off-by: Nicholas Nunley <nicholasx.d.nunley@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bonding: fix arp_validate on bonds inside a bridge
From: David Miller @ 2010-05-06 7:35 UTC (permalink / raw)
To: jbohac; +Cc: fubar, bonding-devel, netdev
In-Reply-To: <20100505133301.GA18493@midget.suse.cz>
From: Jiri Bohac <jbohac@suse.cz>
Date: Wed, 5 May 2010 15:33:01 +0200
> If either of the ptype_all or ptype_base_predecap[] method is
> preferred, I'll be happy to re-work the patch. I just thought
> performance had bigger priority here.
Well, let's do some thinking.
If there are any ptype_all[] entries at all, processing of every
packet will be expensive.
Also, the ptype_base_predecap[] is unlikely to have any entries
unless bonding is on in this special mode. But if it is, we
can accept a little bit of extra overhead.
So we can address all of this without adding undue overhead for people
not using this stuff, by simply having an atomic counter which shows
how many ptype_all[] or ptype_base_predecap[] entries exist.
And at the top level we test that __read_mostly atomic variable before
traversing the ptype_all[] and ptype_base_predecap[] lists.
That should address all of the issues.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/3] ixgbevf: Cache PF ack bit in interrupt
From: David Miller @ 2010-05-06 7:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, gregory.v.rose
In-Reply-To: <20100506055748.8482.25239.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 05 May 2010 22:57:49 -0700
> From: Greg Rose <gregory.v.rose@intel.com>
>
> When the PF acks a message from the VF the VF gets an interrupt. It
> must cache the ack bit so that polling SW will not miss the ack. Also
> avoid reading the message buffer on acks because that also will clear
> the ack bit.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/3] ixgbe: Streamline MC filter setup for VFs
From: David Miller @ 2010-05-06 7:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, gregory.v.rose
In-Reply-To: <20100506055728.8482.77386.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 05 May 2010 22:57:30 -0700
> From: Greg Rose <gregory.v.rose@intel.com>
>
> The driver was calling the set Rx mode function for every multicast
> filter set by the VF. When starting many VMs where each might have
> multiple VLAN interfaces this would result in the function being
> called hundreds or even thousands of times. This is unnecessary
> for the case of the imperfect filters used in the MTA and has been
> streamlined to be more efficient.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/3] ixgbe: Remove unneeded register writes in VF VLAN setup
From: David Miller @ 2010-05-06 7:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, gregory.v.rose
In-Reply-To: <20100506055703.8482.16515.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 05 May 2010 22:57:10 -0700
> From: Greg Rose <gregory.v.rose@intel.com>
>
> The driver is unnecessarily writing values to VLAN control registers.
> These writes already done elsewhere and are superfluous here.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [GIT PULL] amended: first round of vhost-net enhancements for net-next
From: David Miller @ 2010-05-06 7:29 UTC (permalink / raw)
To: mst; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20100504112100.GA22172@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Tue, 4 May 2010 14:21:01 +0300
> This is an amended pull request: I have rebased the tree to the
> correct patches. This has been through basic tests and seems
> to work fine here.
>
> The following tree includes a couple of enhancements that help vhost-net.
> Please pull them for net-next. Another set of patches is under
> debugging/testing and I hope to get them ready in time for 2.6.35,
> so there may be another pull request later.
Pulled, thanks Michael.
^ permalink raw reply
* Re: [PATCH v2] net/gianfar: drop recycled skbs on MTU change
From: David Miller @ 2010-05-06 7:26 UTC (permalink / raw)
To: afleming; +Cc: sebastian, afleming, netdev
In-Reply-To: <C4C9C232-1DA6-43BE-A9FF-4A591E3FF672@freescale.com>
From: Andy Fleming <afleming@freescale.com>
Date: Wed, 5 May 2010 10:18:40 -0500
>
> On May 5, 2010, at 3:30 AM, Sebastian Andrzej Siewior wrote:
>
>> From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>>
>> The size for skbs which is added to the recycled list is using the
>> current descriptor size which is current MTU. gfar_new_skb() is also
>> using this size. So after changing or alteast increasing the MTU all
>> recycled skbs should be dropped.
>>
>> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
...
> Acked-by: Andy Fleming <afleming@freescale.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/2] e1000/e1000e: implement a simple interrupt moderation
From: David Miller @ 2010-05-06 7:25 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, jesse.brandeburg
In-Reply-To: <20100505082601.5956.29024.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 05 May 2010 01:26:03 -0700
> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
>
> Back before e1000-7.3.20, the e1000 driver had a simple algorithm that
> managed interrupt moderation. The driver was updated in 7.3.20 to
> have the new "adaptive" interrupt moderation but we have customer
> requests to redeploy the old way as an option. This patch adds the
> old functionality back. The new functionality can be enabled via
> module parameter or at runtime via ethtool.
> Module parameter: (InterruptThrottleRate=4) to use this new
> moderation method.
> Ethtool method: ethtool -C ethX rx-usecs 4
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/2] e1000e: increase rx fifo size to 36K on 82574 and 82583
From: David Miller @ 2010-05-06 7:25 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20100505082537.5956.86868.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 05 May 2010 01:25:42 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change increases the RX fifo size to 36K for standard frames and
> decreases the TX fifo size to 4K. The reason for this change is that on
> slower systems the RX is much more likely to backfill and need space than
> the TX is. As long as the TX fifo is twice the size of the MTU we should
> have more than enough TX fifo.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/2] ixgbe: Add support for VF MAC and VLAN configuration
From: David Miller @ 2010-05-06 7:25 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, gregory.v.rose
In-Reply-To: <20100505081204.5709.63340.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 05 May 2010 01:12:06 -0700
> From: Greg Rose <gregory.v.rose@intel.com>
>
> Add support for the "ip link set" and "ip link show" commands that allow
> configuration of the virtual functions' MAC and port VLAN via user space
> command line.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/2] ixgbe: Add boolean parameter to ixgbe_set_vmolr
From: David Miller @ 2010-05-06 7:25 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, gregory.v.rose
In-Reply-To: <20100505081129.5709.39430.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 05 May 2010 01:11:46 -0700
> From: Greg Rose <gregory.v.rose@intel.com>
>
> Add a boolean parameter to ixgbe-set_vmolr so that the caller can
> specify whether the pool should accept untagged packets. Required
> for a follow on patch to enable administrative configuration of port
> VLAN for virtual functions.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* RE: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Shreyas Bhatewara @ 2010-05-06 7:25 UTC (permalink / raw)
To: Scott Feldman, Arnd Bergmann, Dmitry Torokhov
Cc: Christoph Hellwig, pv-drivers@vmware.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, Pankaj Thakkar
In-Reply-To: <C807719A.2E910%scofeldm@cisco.com>
> -----Original Message-----
> From: Scott Feldman [mailto:scofeldm@cisco.com]
> Sent: Wednesday, May 05, 2010 7:04 PM
> To: Shreyas Bhatewara; Arnd Bergmann; Dmitry Torokhov
> Cc: Christoph Hellwig; pv-drivers@vmware.com; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; virtualization@lists.linux-
> foundation.org; Pankaj Thakkar
> Subject: Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for
> vmxnet3
>
> On 5/5/10 10:29 AM, "Dmitry Torokhov" <dtor@vmware.com> wrote:
>
> > It would not be a binary blob but software properly released under
> GPL.
> > The current plan is for the shell to enforce GPL requirement on the
> > plugin code, similar to what module loaded does for regular kernel
> > modules.
>
> On 5/5/10 3:05 PM, "Shreyas Bhatewara" <sbhatewara@vmware.com> wrote:
>
> > The plugin image is not linked against Linux kernel. It is OS
> agnostic infact
> > (Eg. same plugin works for Linux and Windows VMs)
>
> Are there any issues with injecting the GPL-licensed plug-in into the
> Windows vmxnet3 NDIS driver?
>
> -scott
^ permalink raw reply
* RE: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Shreyas Bhatewara @ 2010-05-06 7:25 UTC (permalink / raw)
To: Scott Feldman, Arnd Bergmann, Dmitry Torokhov
Cc: Christoph Hellwig, pv-drivers@vmware.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, Pankaj Thakkar
In-Reply-To: <C807719A.2E910%scofeldm@cisco.com>
> -----Original Message-----
> From: Scott Feldman [mailto:scofeldm@cisco.com]
> Sent: Wednesday, May 05, 2010 7:04 PM
> To: Shreyas Bhatewara; Arnd Bergmann; Dmitry Torokhov
> Cc: Christoph Hellwig; pv-drivers@vmware.com; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; virtualization@lists.linux-
> foundation.org; Pankaj Thakkar
> Subject: Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for
> vmxnet3
>
> On 5/5/10 10:29 AM, "Dmitry Torokhov" <dtor@vmware.com> wrote:
>
> > It would not be a binary blob but software properly released under
> GPL.
> > The current plan is for the shell to enforce GPL requirement on the
> > plugin code, similar to what module loaded does for regular kernel
> > modules.
>
> On 5/5/10 3:05 PM, "Shreyas Bhatewara" <sbhatewara@vmware.com> wrote:
>
> > The plugin image is not linked against Linux kernel. It is OS
> agnostic infact
> > (Eg. same plugin works for Linux and Windows VMs)
>
> Are there any issues with injecting the GPL-licensed plug-in into the
> Windows vmxnet3 NDIS driver?
>
> -scott
Scott,
Thanks for pointing out. This issue can be resolved by adding exception to the plugin license which allows it to link to a non-free program .(http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF)
->Shreyas
^ permalink raw reply
* Re: [PATCH 4/4 v2] ks8851: read/write MAC address on companion eeprom through debugfs
From: David Miller @ 2010-05-06 7:25 UTC (permalink / raw)
To: s-jan; +Cc: netdev, linux-omap, x0066660, ben-linux, Tristram.Ha
In-Reply-To: <1273085155-1260-5-git-send-email-s-jan@ti.com>
From: Sebastien Jan <s-jan@ti.com>
Date: Wed, 5 May 2010 20:45:55 +0200
> A more elegant alternative to ethtool for updating the ks8851
> MAC address stored on its companion eeprom.
> Using this debugfs interface does not require any knowledge on the
> ks8851 companion eeprom organization to update the MAC address.
>
> Example to write 01:23:45:67:89:AB MAC address to the companion
> eeprom (assuming debugfs is mounted in /sys/kernel/debug):
> $ echo "01:23:45:67:89:AB" > /sys/kernel/debug/ks8851/mac_eeprom
>
> Signed-off-by: Sebastien Jan <s-jan@ti.com>
Elegant? This commit message is the biggest lie ever told.
What makes your ethernet driver so god-damn special that it deserves
to have a private, completely unique, and obscure interface for
setting the permanent ethernet address of a network device?
Tell me how damn elegant it is that users have to learn about this
special, unique, and common with no other driver, interface for
performing this task?
Tell me how damn elegant it is when another driver wants to provide
users with a way to do this too, and they (like you) come up with
their own unique and different interface for doing this.
No, this is the most inelegant patch ever conceived because it totally
ignores the way in which we handle issues like this.
There is no way in the world I'm applying this garbage patch, sorry.
We have an ETHTOOL_GPERMADDR, add a new ETHTOOL_SPERMADDR operation
and then any driver (not just your's) can portably provide this
facility and users will have one, and only one, way of performing this
task.
^ permalink raw reply
* Re: [PATCH 3/4 v2] ks8851: companion eeprom access through ethtool
From: David Miller @ 2010-05-06 7:20 UTC (permalink / raw)
To: s-jan; +Cc: netdev, linux-omap, x0066660, ben-linux, Tristram.Ha
In-Reply-To: <1273085155-1260-4-git-send-email-s-jan@ti.com>
From: Sebastien Jan <s-jan@ti.com>
Date: Wed, 5 May 2010 20:45:54 +0200
> Accessing ks8851 companion eeprom permits modifying the ks8851 stored
> MAC address.
>
> Example how to change the MAC address using ethtool, to set the
> 01:23:45:67:89:AB MAC address:
> $ echo "0:AB8976452301" | xxd -r > mac.bin
> $ sudo ethtool -E eth0 magic 0x8870 offset 2 < mac.bin
>
> Signed-off-by: Sebastien Jan <s-jan@ti.com>
Applied.
^ 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