* [PATCH net-next RFC 3/5] net-timestamp: no-payload option in txtimestamp test
From: Willem de Bruijn @ 2015-01-09 17:31 UTC (permalink / raw)
To: netdev; +Cc: davem, richardcochran, eric.dumazet, luto, Willem de Bruijn
In-Reply-To: <1420824719-28848-1-git-send-email-willemb@google.com>
From: Willem de Bruijn <willemb@google.com>
Demonstrate how SOF_TIMESTAMPING_OPT_TSONLY can be used and
test the implementation.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
.../networking/timestamping/txtimestamp.c | 28 ++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/Documentation/networking/timestamping/txtimestamp.c b/Documentation/networking/timestamping/txtimestamp.c
index 8778e68..1171ebf 100644
--- a/Documentation/networking/timestamping/txtimestamp.c
+++ b/Documentation/networking/timestamping/txtimestamp.c
@@ -68,6 +68,7 @@ static int do_ipv6 = 1;
static int cfg_payload_len = 10;
static bool cfg_show_payload;
static bool cfg_do_pktinfo;
+static bool cfg_loop_nodata;
static uint16_t dest_port = 9000;
static struct sockaddr_in daddr;
@@ -139,6 +140,9 @@ static void print_payload(char *data, int len)
{
int i;
+ if (!len)
+ return;
+
if (len > 70)
len = 70;
@@ -175,6 +179,7 @@ static void __recv_errmsg_cmsg(struct msghdr *msg, int payload_len)
struct sock_extended_err *serr = NULL;
struct scm_timestamping *tss = NULL;
struct cmsghdr *cm;
+ int batch = 0;
for (cm = CMSG_FIRSTHDR(msg);
cm && cm->cmsg_len;
@@ -207,10 +212,18 @@ static void __recv_errmsg_cmsg(struct msghdr *msg, int payload_len)
} else
fprintf(stderr, "unknown cmsg %d,%d\n",
cm->cmsg_level, cm->cmsg_type);
+
+ if (serr && tss) {
+ print_timestamp(tss, serr->ee_info, serr->ee_data,
+ payload_len);
+ serr = NULL;
+ tss = NULL;
+ batch++;
+ }
}
- if (serr && tss)
- print_timestamp(tss, serr->ee_info, serr->ee_data, payload_len);
+ if (batch > 1)
+ fprintf(stderr, "batched %d timestamps\n", batch);
}
static int recv_errmsg(int fd)
@@ -242,7 +255,7 @@ static int recv_errmsg(int fd)
if (ret == -1 && errno != EAGAIN)
error(1, errno, "recvmsg");
- if (ret > 0) {
+ if (ret >= 0) {
__recv_errmsg_cmsg(&msg, ret);
if (cfg_show_payload)
print_payload(data, cfg_payload_len);
@@ -307,6 +320,9 @@ static void do_test(int family, unsigned int opt)
opt |= SOF_TIMESTAMPING_SOFTWARE |
SOF_TIMESTAMPING_OPT_CMSG |
SOF_TIMESTAMPING_OPT_ID;
+ if (cfg_loop_nodata)
+ opt |= SOF_TIMESTAMPING_OPT_TSONLY;
+
if (setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING,
(char *) &opt, sizeof(opt)))
error(1, 0, "setsockopt timestamping");
@@ -376,6 +392,7 @@ static void __attribute__((noreturn)) usage(const char *filepath)
" -h: show this message\n"
" -I: request PKTINFO\n"
" -l N: send N bytes at a time\n"
+ " -n: set no-payload option\n"
" -r: use raw\n"
" -R: use raw (IP_HDRINCL)\n"
" -p N: connect to port N\n"
@@ -390,7 +407,7 @@ static void parse_opt(int argc, char **argv)
int proto_count = 0;
char c;
- while ((c = getopt(argc, argv, "46hIl:p:rRux")) != -1) {
+ while ((c = getopt(argc, argv, "46hIl:np:rRux")) != -1) {
switch (c) {
case '4':
do_ipv6 = 0;
@@ -401,6 +418,9 @@ static void parse_opt(int argc, char **argv)
case 'I':
cfg_do_pktinfo = true;
break;
+ case 'n':
+ cfg_loop_nodata = true;
+ break;
case 'r':
proto_count++;
cfg_proto = SOCK_RAW;
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next RFC 2/5] net-timestamp: no-payload only sysctl
From: Willem de Bruijn @ 2015-01-09 17:31 UTC (permalink / raw)
To: netdev; +Cc: davem, richardcochran, eric.dumazet, luto, Willem de Bruijn
In-Reply-To: <1420824719-28848-1-git-send-email-willemb@google.com>
From: Willem de Bruijn <willemb@google.com>
Tx timestamps are looped onto the error queue on top of an skb. This
mechanism leaks packet headers to processes unless the no-payload
options SOF_TIMESTAMPING_OPT_TSONLY is set.
Add a sysctl that optionally drops looped timestamps with data for
unprivileged users.
The policy is checked when timestamps are generated in the stack.
It is possible for timestamps with data to be reported after the
sysctl is set, if these were queued internally earlier.
No vulnerability is immediately known that exploits knowledge
gleaned from packet headers, but it may still be preferable to allow
administrators to lock down this path at the cost of possible
breakage of legacy applications.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
include/net/sock.h | 1 +
net/core/skbuff.c | 11 ++++++++++-
net/core/sock.c | 3 +++
net/core/sysctl_net_core.c | 9 +++++++++
4 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 2210fec..9729171 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2262,6 +2262,7 @@ bool sk_net_capable(const struct sock *sk, int cap);
extern __u32 sysctl_wmem_max;
extern __u32 sysctl_rmem_max;
+extern int sysctl_tstamp_allow_data;
extern int sysctl_optmem_max;
extern __u32 sysctl_wmem_default;
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index ece2bb8..e5f4c06 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3690,11 +3690,20 @@ static void __skb_complete_tx_timestamp(struct sk_buff *skb,
kfree_skb(skb);
}
+static bool skb_may_tx_timestamp(struct sock *sk)
+{
+ return sysctl_tstamp_allow_data || capable(CAP_NET_RAW) ||
+ sk->sk_tsflags & SOF_TIMESTAMPING_OPT_TSONLY;
+}
+
void skb_complete_tx_timestamp(struct sk_buff *skb,
struct skb_shared_hwtstamps *hwtstamps)
{
struct sock *sk = skb->sk;
+ if (!skb_may_tx_timestamp(sk))
+ return;
+
/* take a reference to prevent skb_orphan() from freeing the socket */
sock_hold(sk);
@@ -3712,7 +3721,7 @@ void __skb_tstamp_tx(struct sk_buff *orig_skb,
struct sk_buff *skb;
bool tsonly = sk->sk_tsflags & SOF_TIMESTAMPING_OPT_TSONLY;
- if (!sk)
+ if (!sk || !skb_may_tx_timestamp(sk))
return;
if (tsonly)
diff --git a/net/core/sock.c b/net/core/sock.c
index 1c7a33d..93c8b20 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -325,6 +325,8 @@ __u32 sysctl_rmem_default __read_mostly = SK_RMEM_MAX;
int sysctl_optmem_max __read_mostly = sizeof(unsigned long)*(2*UIO_MAXIOV+512);
EXPORT_SYMBOL(sysctl_optmem_max);
+int sysctl_tstamp_allow_data __read_mostly = 1;
+
struct static_key memalloc_socks = STATIC_KEY_INIT_FALSE;
EXPORT_SYMBOL_GPL(memalloc_socks);
@@ -840,6 +842,7 @@ set_rcvbuf:
ret = -EINVAL;
break;
}
+
if (val & SOF_TIMESTAMPING_OPT_ID &&
!(sk->sk_tsflags & SOF_TIMESTAMPING_OPT_ID)) {
if (sk->sk_protocol == IPPROTO_TCP) {
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index 31baba2..fde21d1 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -321,6 +321,15 @@ static struct ctl_table net_core_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "tstamp_allow_data",
+ .data = &sysctl_tstamp_allow_data,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &one
+ },
#ifdef CONFIG_RPS
{
.procname = "rps_sock_flow_entries",
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next RFC 1/5] net-timestamp: no-payload option
From: Willem de Bruijn @ 2015-01-09 17:31 UTC (permalink / raw)
To: netdev; +Cc: davem, richardcochran, eric.dumazet, luto, Willem de Bruijn
In-Reply-To: <1420824719-28848-1-git-send-email-willemb@google.com>
From: Willem de Bruijn <willemb@google.com>
Add timestamping option SOF_TIMESTAMPING_OPT_TSONLY. For transmit
timestamps, this loops timestamps on top of empty packets.
Doing so reduces the pressure on SO_RCVBUF. Payload inspection and
cmsg reception (aside from timestamps) are no longer possible. This
works together with a follow on patch that allows administrators to
only allow tx timestamping if it does not loop payload or metadata.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
include/uapi/linux/net_tstamp.h | 3 ++-
net/core/skbuff.c | 19 ++++++++++++++-----
net/ipv4/ip_sockglue.c | 9 +++++----
net/ipv6/datagram.c | 4 ++--
net/rxrpc/ar-error.c | 5 +++++
5 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
index edbc888..6d1abea 100644
--- a/include/uapi/linux/net_tstamp.h
+++ b/include/uapi/linux/net_tstamp.h
@@ -24,8 +24,9 @@ enum {
SOF_TIMESTAMPING_TX_SCHED = (1<<8),
SOF_TIMESTAMPING_TX_ACK = (1<<9),
SOF_TIMESTAMPING_OPT_CMSG = (1<<10),
+ SOF_TIMESTAMPING_OPT_TSONLY = (1<<11),
- SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_OPT_CMSG,
+ SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_OPT_TSONLY,
SOF_TIMESTAMPING_MASK = (SOF_TIMESTAMPING_LAST - 1) |
SOF_TIMESTAMPING_LAST
};
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 5a2a2e8..ece2bb8 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3710,19 +3710,28 @@ void __skb_tstamp_tx(struct sk_buff *orig_skb,
struct sock *sk, int tstype)
{
struct sk_buff *skb;
+ bool tsonly = sk->sk_tsflags & SOF_TIMESTAMPING_OPT_TSONLY;
if (!sk)
return;
- if (hwtstamps)
- *skb_hwtstamps(orig_skb) = *hwtstamps;
+ if (tsonly)
+ skb = alloc_skb(0, GFP_ATOMIC);
else
- orig_skb->tstamp = ktime_get_real();
-
- skb = skb_clone(orig_skb, GFP_ATOMIC);
+ skb = skb_clone(orig_skb, GFP_ATOMIC);
if (!skb)
return;
+ if (tsonly) {
+ skb_shinfo(skb)->tx_flags = skb_shinfo(orig_skb)->tx_flags;
+ skb_shinfo(skb)->tskey = skb_shinfo(orig_skb)->tskey;
+ }
+
+ if (hwtstamps)
+ *skb_hwtstamps(skb) = *hwtstamps;
+ else
+ skb->tstamp = ktime_get_real();
+
__skb_complete_tx_timestamp(skb, sk, tstype);
}
EXPORT_SYMBOL_GPL(__skb_tstamp_tx);
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index a317797..d81ef70 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -440,7 +440,7 @@ static bool ipv4_pktinfo_prepare_errqueue(const struct sock *sk,
if ((ee_origin != SO_EE_ORIGIN_TIMESTAMPING) ||
(!(sk->sk_tsflags & SOF_TIMESTAMPING_OPT_CMSG)) ||
- (!skb->dev))
+ (!skb->dev) || (!skb->len))
return false;
info->ipi_spec_dst.s_addr = ip_hdr(skb)->saddr;
@@ -483,7 +483,7 @@ int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
serr = SKB_EXT_ERR(skb);
- if (sin) {
+ if (sin && skb->len) {
sin->sin_family = AF_INET;
sin->sin_addr.s_addr = *(__be32 *)(skb_network_header(skb) +
serr->addr_offset);
@@ -496,8 +496,9 @@ int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
sin = &errhdr.offender;
sin->sin_family = AF_UNSPEC;
- if (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP ||
- ipv4_pktinfo_prepare_errqueue(sk, skb, serr->ee.ee_origin)) {
+ if (skb->len &&
+ (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP ||
+ ipv4_pktinfo_prepare_errqueue(sk, skb, serr->ee.ee_origin))) {
struct inet_sock *inet = inet_sk(sk);
sin->sin_family = AF_INET;
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 100c589..91a31ea 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -369,7 +369,7 @@ int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
serr = SKB_EXT_ERR(skb);
- if (sin) {
+ if (sin && skb->len) {
const unsigned char *nh = skb_network_header(skb);
sin->sin6_family = AF_INET6;
sin->sin6_flowinfo = 0;
@@ -394,7 +394,7 @@ int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
memcpy(&errhdr.ee, &serr->ee, sizeof(struct sock_extended_err));
sin = &errhdr.offender;
sin->sin6_family = AF_UNSPEC;
- if (serr->ee.ee_origin != SO_EE_ORIGIN_LOCAL) {
+ if (serr->ee.ee_origin != SO_EE_ORIGIN_LOCAL && skb->len) {
sin->sin6_family = AF_INET6;
sin->sin6_flowinfo = 0;
sin->sin6_port = 0;
diff --git a/net/rxrpc/ar-error.c b/net/rxrpc/ar-error.c
index 74c0fcd..5394b6b 100644
--- a/net/rxrpc/ar-error.c
+++ b/net/rxrpc/ar-error.c
@@ -42,6 +42,11 @@ void rxrpc_UDP_error_report(struct sock *sk)
_leave("UDP socket errqueue empty");
return;
}
+ if (!skb->len) {
+ _leave("UDP empty message");
+ kfree_skb(skb);
+ return;
+ }
rxrpc_new_skb(skb);
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* [PATCH net-next RFC 0/5] net-timestamp: address blinding and batching
From: Willem de Bruijn @ 2015-01-09 17:31 UTC (permalink / raw)
To: netdev; +Cc: davem, richardcochran, eric.dumazet, luto, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
Two issues were raised during recent timestamping discussions:
1. looping full packets on the error queue exposes packet headers
2. TCP timestamping with retransmissions generates many timestamps
This RFC patchset is an attempt at addressing both without breaking
legacy behavior.
Patch 1 reintroduces the "no payload" timestamp option, which loops
timestamps onto an empty skb. Patch 2 then gives administrators the
power to block all timestamp requests by unprivileged users that
contain data. I proposed this earlier as a backward compatible
workaround in the discussion of
net-timestamp: pull headers for SOCK_STREAM
http://patchwork.ozlabs.org/patch/414810/
Patch 3 only updates the txtimestamp example to test this option.
When looping timestamps without data, there is no need to associate
a timestamp with a specific packet. Patch 4 loops multiple timestamps
onto a single outstanding packet if this has no payload. It is a
variant of the cookies approach that David proposed in
net-timestamp: TCP timestamping
http://patchwork.ozlabs.org/patch/376513/
That patch turns out to introduce a quite a bit of code to save
relatively few bytes because
1. no-payload already limits the per-skb size that is queued and
2. batching is limited by send() failing as soon as there is an
outstanding packet on the error queue. Therefore, I'm fine
with dropping this. By now, it is at least recorded in patchwork.
Patch 5, finally, creates a new short SO_TIMESTAMPING option,
SOF_TIMESTAMPING_TX, that combines all recent options, as a push
to get future applications to use the new ID and no-payload based
API by default.
Willem de Bruijn (5):
net-timestamp: no-payload option
net-timestamp: no-payload only sysctl
net-timestamp: no-payload option in txtimestamp test
net-timestamp: tx timestamp cookies
net-timestamp: tx timestamping default mode flag
.../networking/timestamping/txtimestamp.c | 28 ++++-
include/linux/skbuff.h | 12 ++
include/net/sock.h | 4 +-
include/uapi/linux/errqueue.h | 1 +
include/uapi/linux/net_tstamp.h | 11 +-
net/core/skbuff.c | 134 ++++++++++++++++++---
net/core/sock.c | 3 +
net/core/sysctl_net_core.c | 9 ++
net/ipv4/ip_sockglue.c | 9 +-
net/ipv6/datagram.c | 4 +-
net/rxrpc/ar-error.c | 5 +
net/socket.c | 64 +++++++++-
12 files changed, 250 insertions(+), 34 deletions(-)
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply
* Re: [net-next PATCH v1 00/11] A flow API
From: John Fastabend @ 2015-01-09 17:26 UTC (permalink / raw)
To: Or Gerlitz
Cc: Thomas Graf, Scott Feldman, Jiří Pírko,
Jamal Hadi Salim, simon.horman, Linux Netdev List, David Miller,
Andy Gospodarek
In-Reply-To: <CAJ3xEMjb+pG3TR+r0huNVSGkuPE9i7EZeHO4SQkcfm=WA6zMeA@mail.gmail.com>
On 01/08/2015 07:14 AM, Or Gerlitz wrote:
> On Wed, Dec 31, 2014 at 9:45 PM, John Fastabend
> <john.fastabend@gmail.com> wrote:
>> For some examples and maybe a bit more illustrative description I
>> posted a quickly typed up set of notes on github io pages. Here we
>> can show the description along with images produced by the flow tool
>> showing the pipeline. Once we settle a bit more on the API we should
>> probably do a clean up of this and other threads happening and commit
>> something to the Documentation directory.
>>
>> http://jrfastab.github.io/jekyll/update/2014/12/21/flow-api.html
>
> John, Going over your excellent tutorial, the distinction between
> action and operation isn’t clear... specifically, the paragraph
> “Although this gives us a list of actions we can perform on a packet
> and a set of argument to give the action so we can use them it does
> not supply the operations performed on the packet” is a bit vague.
>
> Or.
>
Agreed that is a bit confusing. What I was trying to show is if two
hardware devices give you the same action but with different names
showing they are equivalent is not possible with the current API.
So either (a) you need to enforce every device names their actions
correctly or (b) provide a mechanism to describe the actions so we
can evaluate their equivalence.
Its actually worse then this what I want to eventually show is if
device A has support for a set of actions and device B has support
for another set. I want to be able to say things about the devices
like device A can support any action B can do but it may require
applying a 2 actions from A's collection of actions. (clear as mud?)
I'll try to clear it up in the documentation.
Thanks for looking it over.
.John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH] net: wireless: rtlwifi: btcoexist: halbtc8821a2ant: Remove some unused functions
From: Rickard Strandqvist @ 2015-01-09 17:23 UTC (permalink / raw)
To: Kalle Valo
Cc: Larry Finger, Chaoming Li, Greg Kroah-Hartman, Fengguang Wu,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List
In-Reply-To: <871tn7zsie.fsf@kamboji.qca.qualcomm.com>
Hi All
Yes I use sed as Julian said. I have it as part of my git send-email
script, until a few week ago, it was enough that I removed the
"drivers/" and changed all "/" to ": "
I have now been expanded my sed pipe a lot (tell me if anyone is interested).
But a real script to do this would have been very good I think!
It may be, there was some mail problems during the holiday season :-(
There is not a total consensus on how patcher will was designed.
I have previously received complaints that I made for large patches of
too many files.
Have since tried to make small patches, and it also fit better to have
more specific paths in the subject line.
But I'll try to gather all in one patchset instead this weekend.
Kind regards
Rickard Strandqvist
2015-01-06 19:14 GMT+01:00 Kalle Valo <kvalo@codeaurora.org>:
> Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> writes:
>
>> Removes some functions that are not used anywhere:
>> ex_halbtc8821a2ant_periodical() ex_halbtc8821a2ant_halt_notify()
>> ex_halbtc8821a2ant_bt_info_notify()
>> ex_halbtc8821a2ant_special_packet_notify()
>> ex_halbtc8821a2ant_connect_notify() ex_halbtc8821a2ant_scan_notify()
>> ex_halbtc8821a2ant_lps_notify() ex_halbtc8821a2ant_ips_notify()
>> ex_halbtc8821a2ant_display_coex_info() ex_halbtc8821a2ant_init_coex_dm()
>> ex_halbtc8821a2ant_init_hwconfig()
>>
>> This was partially found by using a static code analysis program called cppcheck.
>>
>> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
>
> Rickard, I have dropped all your patches because I lost track which I
> should apply and which not and I do not want to waste half an hour
> figuring out. Please resend the ones which are still valid.
>
> And to make it easier for everyone please group these wireless-drivers
> cleanup patches into a larger patchset (like 10-15 patches max per
> patchset). That way it's a lot easier for me tomanage them. Sending one
> patch a day is not recommended, especially when we are talking trivial
> cleanup patches like this.
>
> --
> Kalle Valo
^ permalink raw reply
* Re: Fw: iproute2: segfault with ip link show dev
From: Vadim Kochan @ 2015-01-09 16:59 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, vadim4j
In-Reply-To: <20150107114217.42bf2392@urahara>
On Wed, Jan 07, 2015 at 11:42:17AM -0800, Stephen Hemminger wrote:
> Looks like one VF info changes broke old code
>
> Begin forwarded message:
>
> Date: Wed, 7 Jan 2015 04:06:53 -0800
> From: William Dauchy <william@gandi.net>
> To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> Subject: iproute2: segfault with ip link show dev
>
>
> Hi,
>
> I was using iproute2 3.15.
> My network card in using igb driver with VF enable, e.g igb.max_vfs=2
> After upgrading to 3.16, I have now a segfault while doing a
> usual `ip link show dev eth1`.
> Disabling VFS make the segafult disappear.
>
> Here is the gdb trace even if it does not contain much info.
> The segfault occurs when at the VF step.
>
> (gdb) break print_linkinfo
> Breakpoint 1 at 0x40782d
> (gdb) set args link show dev eth1
> (gdb) r
> Starting program: /sbin/ip link show dev eth1
>
> Breakpoint 1, 0x000000000040782d in print_linkinfo ()
> (gdb) n
> Single stepping until exit from function print_linkinfo,
> which has no line number information.
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP
> mode DEFAULT group default qlen 10000
> link/ether 00:26:6c:ff:b5:c1 brd ff:ff:ff:ff:ff:ff
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004070eb in print_vfinfo ()
> (gdb) bt
> #0 0x00000000004070eb in print_vfinfo ()
> #1 0x0000000000407f9f in print_linkinfo ()
> #2 0x000000000041f266 in iplink_get ()
> #3 0x0000000000409c69 in ipaddr_list_flush_or_save ()
> #4 0x000000000040a113 in ipaddr_list_link ()
> #5 0x00000000004203f6 in do_iplink ()
> #6 0x0000000000405a07 in do_cmd ()
> #7 0x000000000040621e in main ()
>
> The expected output is for example:
>
> # ip link show dev eth1
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 10000
> link/ether 00:26:6c:ff:b3:8d brd ff:ff:ff:ff:ff:ff
> vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
> vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
>
>
> I'm using my own kernel build, a stable v3.14.x
>
> Regards,
> --
> William
I have a working patch which was tested by William and will send it
soon.
Regards,
Vadim Kochan
^ permalink raw reply
* Re: [PATCH RESEND 2/2] wlcore: align member-assigns in a structure-copy block
From: Kalle Valo @ 2015-01-09 17:03 UTC (permalink / raw)
To: Giel van Schijndel
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eliad Peller,
John W. Linville, Arik Nemtsov, open list:TI WILINK WIRELES...,
open list:NETWORKING DRIVERS
In-Reply-To: <1420659525-22975-2-git-send-email-me-sZ9Uef1cvPWHXe+LvDLADg@public.gmane.org>
Giel van Schijndel <me-sZ9Uef1cvPWHXe+LvDLADg@public.gmane.org> writes:
> This highlights the differences (e.g. the bug fixed in the previous
> commit).
>
> Signed-off-by: Giel van Schijndel <me-sZ9Uef1cvPWHXe+LvDLADg@public.gmane.org>
> ---
> drivers/net/wireless/ti/wlcore/acx.c | 22 +++++++++++-----------
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/acx.c b/drivers/net/wireless/ti/wlcore/acx.c
> index f28fa3b..93a2fa8 100644
> --- a/drivers/net/wireless/ti/wlcore/acx.c
> +++ b/drivers/net/wireless/ti/wlcore/acx.c
> @@ -1715,17 +1715,17 @@ int wl12xx_acx_config_hangover(struct wl1271 *wl)
> goto out;
> }
>
> - acx->recover_time = cpu_to_le32(conf->recover_time);
> - acx->hangover_period = conf->hangover_period;
> - acx->dynamic_mode = conf->dynamic_mode;
> - acx->early_termination_mode = conf->early_termination_mode;
> - acx->max_period = conf->max_period;
> - acx->min_period = conf->min_period;
> - acx->increase_delta = conf->increase_delta;
> - acx->decrease_delta = conf->decrease_delta;
> - acx->quiet_time = conf->quiet_time;
> - acx->increase_time = conf->increase_time;
> - acx->window_size = conf->window_size;
> + acx->recover_time = cpu_to_le32(conf->recover_time);
> + acx->hangover_period = conf->hangover_period;
> + acx->dynamic_mode = conf->dynamic_mode;
> + acx->early_termination_mode = conf->early_termination_mode;
> + acx->max_period = conf->max_period;
> + acx->min_period = conf->min_period;
> + acx->increase_delta = conf->increase_delta;
> + acx->decrease_delta = conf->decrease_delta;
> + acx->quiet_time = conf->quiet_time;
> + acx->increase_time = conf->increase_time;
> + acx->window_size = conf->window_size;
I would like to get an ACK from one of the wlcore developers if I should
apply this (or not).
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH] i40e: don't enable and init FCOE by default when do PF reset
From: Ronciak, John @ 2015-01-09 16:41 UTC (permalink / raw)
To: Ethan Zhao, Kirsher, Jeffrey T, Brandeburg, Jesse, Allan, Bruce W,
Wyborny, Carolyn, Skidmore, Donald C, Rose, Gregory V,
Vick, Matthew, Williams, Mitch A, Dev, Vasu, Parikh, Neerav
Cc: Linux NICS, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
ethan.kernel@gmail.com, brian.maly@oracle.com
In-Reply-To: <1420821466-5747-1-git-send-email-ethan.zhao@oracle.com>
Adding Vasu and Neerav
Cheers,
John
> -----Original Message-----
> From: Ethan Zhao [mailto:ethan.zhao@oracle.com]
> Sent: Friday, January 9, 2015 8:38 AM
> To: Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Wyborny, Carolyn;
> Skidmore, Donald C; Rose, Gregory V; Vick, Matthew; Ronciak, John;
> Williams, Mitch A
> Cc: Linux NICS; e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; ethan.kernel@gmail.com;
> brian.maly@oracle.com; Ethan Zhao
> Subject: [PATCH] i40e: don't enable and init FCOE by default when do PF
> reset
>
> While do PF reset with function i40e_reset_and_rebuild(), it will call
> i40e_init_pf_fcoe() by default if FCOE is defined, thus if the PF is resetted,
> FCOE will be enabled whatever it was - enabled or not.
>
> Such bug might be hit when PF resumes from suspend, run diagnostic test
> with ethtool, setup VLAN etc.
>
> Passed building with v3.19-rc3.
>
> Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index a5f2660..a2572cc 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -6180,9 +6180,12 @@ static void i40e_reset_and_rebuild(struct i40e_pf
> *pf, bool reinit)
> }
> #endif /* CONFIG_I40E_DCB */
> #ifdef I40E_FCOE
> - ret = i40e_init_pf_fcoe(pf);
> - if (ret)
> - dev_info(&pf->pdev->dev, "init_pf_fcoe failed: %d\n", ret);
> + if (pf->flags & I40E_FLAG_FCOE_ENABLED) {
> + ret = i40e_init_pf_fcoe(pf);
> + if (ret)
> + dev_info(&pf->pdev->dev,
> + "init_pf_fcoe failed: %d\n", ret);
> + }
>
> #endif
> /* do basic switch setup */
> --
> 1.8.3.1
^ permalink raw reply
* [PATCH] i40e: don't enable and init FCOE by default when do PF reset
From: Ethan Zhao @ 2015-01-09 16:37 UTC (permalink / raw)
To: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, gregory.v.rose, matthew.vick,
john.ronciak, mitch.a.williams
Cc: Ethan Zhao, linux.nics, e1000-devel, netdev, brian.maly,
linux-kernel, ethan.kernel
While do PF reset with function i40e_reset_and_rebuild(), it will
call i40e_init_pf_fcoe() by default if FCOE is defined, thus if the
PF is resetted, FCOE will be enabled whatever it was - enabled or
not.
Such bug might be hit when PF resumes from suspend, run diagnostic
test with ethtool, setup VLAN etc.
Passed building with v3.19-rc3.
Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index a5f2660..a2572cc 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -6180,9 +6180,12 @@ static void i40e_reset_and_rebuild(struct i40e_pf *pf, bool reinit)
}
#endif /* CONFIG_I40E_DCB */
#ifdef I40E_FCOE
- ret = i40e_init_pf_fcoe(pf);
- if (ret)
- dev_info(&pf->pdev->dev, "init_pf_fcoe failed: %d\n", ret);
+ if (pf->flags & I40E_FLAG_FCOE_ENABLED) {
+ ret = i40e_init_pf_fcoe(pf);
+ if (ret)
+ dev_info(&pf->pdev->dev,
+ "init_pf_fcoe failed: %d\n", ret);
+ }
#endif
/* do basic switch setup */
--
1.8.3.1
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* pull-request: wireless-drivers 2015-01-09
From: Kalle Valo @ 2015-01-09 16:31 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here are few more fixes to 3.19. Please let me know if there are any
problems.
Kalle
The following changes since commit 7ce67a38f799d1fb332f672b117efbadedaa5352:
net: ethernet: cpsw: fix hangs with interrupts (2015-01-04 22:18:34 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2015-01-09
for you to fetch changes up to c702674f99e612a22cf6e8f9b4bec341257970c0:
Merge tag 'iwlwifi-for-kalle-2015-01-05' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes (2015-01-05 12:07:04 +0200)
----------------------------------------------------------------
* rtlwifi: fix a regression in large skb allocation failure
iwlwifi:
* fix for 7265D NVM check
* fixes for scan: fix long scanning times and network discovery
* new firmware API for iwlmvm supported devices
* fixes in rate control
----------------------------------------------------------------
Arik Nemtsov (1):
iwlwifi: pcie: correctly define 7265-D cfg
David Spinadel (2):
iwlwifi: mvm: add a flag to enable match found notification
iwlwifi: mvm: scan dwell time corrections
Emmanuel Grumbach (2):
iwlwifi: 7000: fix reported firmware name for 7265D
iwlwifi: bump firmware API for mvm devices to 12
Eyal Shapira (2):
iwlwifi: mvm: fix Rx with both chains
iwlwifi: mvm: fix out of bounds access to tid_to_mac80211_ac
Kalle Valo (1):
Merge tag 'iwlwifi-for-kalle-2015-01-05' of https://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Larry Finger (1):
rtlwifi: Fix error when accessing unmapped memory in skb
drivers/net/wireless/iwlwifi/iwl-7000.c | 6 ++---
drivers/net/wireless/iwlwifi/iwl-8000.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-fw-file.h | 4 +++
drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h | 2 ++
drivers/net/wireless/iwlwifi/mvm/scan.c | 19 ++++++++++----
drivers/net/wireless/iwlwifi/mvm/tx.c | 8 ++++--
drivers/net/wireless/iwlwifi/mvm/utils.c | 2 +-
drivers/net/wireless/iwlwifi/pcie/drv.c | 4 ++-
drivers/net/wireless/rtlwifi/pci.c | 32 ++++++++++++++++++------
9 files changed, 58 insertions(+), 21 deletions(-)
--
Kalle Valo
^ permalink raw reply
* Re: [Patch net-next] ipv6: fix redefinition of in6_pktinfo and ip6_mtuinfo
From: Carlos O'Donell @ 2015-01-09 16:27 UTC (permalink / raw)
To: David Miller, xiyou.wangcong; +Cc: netdev, vlee
In-Reply-To: <20150108.193819.258816805892789860.davem@davemloft.net>
On 01/08/2015 10:38 PM, David Miller wrote:
> From: Cong Wang <xiyou.wangcong@gmail.com>
> Date: Tue, 6 Jan 2015 15:45:31 -0800
>
>> Both netinet/in.h and linux/ipv6.h define these two structs,
>> if we include both of them, we got:
>>
>> /usr/include/linux/ipv6.h:19:8: error: redefinition of ‘struct in6_pktinfo’
>> struct in6_pktinfo {
>> ^
>> In file included from /usr/include/arpa/inet.h:22:0,
>> from txtimestamp.c:33:
>> /usr/include/netinet/in.h:524:8: note: originally defined here
>> struct in6_pktinfo
>> ^
>> In file included from txtimestamp.c:40:0:
>> /usr/include/linux/ipv6.h:24:8: error: redefinition of ‘struct ip6_mtuinfo’
>> struct ip6_mtuinfo {
>> ^
>> In file included from /usr/include/arpa/inet.h:22:0,
>> from txtimestamp.c:33:
>> /usr/include/netinet/in.h:531:8: note: originally defined here
>> struct ip6_mtuinfo
>> ^
>> So similarly to what we did for in6_addr, we need to sync with
>> libc header on their definitions.
>>
>> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>
> Applied.
>
I'm reviewing the glibc side and will apply there if nobody has done so yet.
Cheers,
Carlos.
^ permalink raw reply
* RE: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of fdb entries learnt via br_fdb_external_learn_add()
From: Arad, Ronen @ 2015-01-09 16:15 UTC (permalink / raw)
To: Scott Feldman, Jiri Pirko; +Cc: Siva Mannem, Netdev
In-Reply-To: <CAE4R7bBRboCfhRKFKgVVAGt1f-m6wkXNfaej4RjuaCKPypABeA@mail.gmail.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of Scott Feldman
>Sent: Friday, January 09, 2015 3:47 AM
>To: Jiri Pirko
>Cc: Siva Mannem; Netdev
>Subject: Re: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of
>fdb entries learnt via br_fdb_external_learn_add()
>
>On Wed, Jan 7, 2015 at 4:53 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Tue, Dec 30, 2014 at 07:20:21PM CET, siva.mannem.lnx@gmail.com wrote:
>>>Hi,
>>>
>>>I am trying to understand the ongoing switch device offload effort and
>>>am following the discussions. I have a question regarding
>>>IFLA_BRPORT_LEARNING_SYNC flag and how aging happens when this flag is
>>>enabled on a port that is attached to a bridge that has vlan filtering
>>>enabled.
>>>
>>>If I understand correctly, when IFLA_BRPORT_LEARNING_SYNC is set on a
>>>bridge port, fdb entries that are learnt externally(may be learnt by
>>>hardware and driver is notified) are synced to bridges fdb using
>>>br_fdb_external_learn_add(). The fdb
>>>entries(fdb->added_by_external_learn set to true) that are learnt via
>>>this method are also deleted by the aging logic after the aging time
>>>even though L2 data forwadring happens in hardware.
>
>This is correct...
>
>>> Is there a way
>>>where aging can be disabled for these entries? and let the entries be
>>>removed only via br_fdb_external_learn_delete()? or am I missing
>>>something?
>>
>> Currently extenaly learned fdb entries are indeed removed during aging
>> cleanup. I believe that br_fdb_cleanup should check added_by_external_learn
>> and not remove that fdbs. What do you think Scott?
>
>Something like that would work, if we added another brport flag to
>control that. With the current arrangement, using bridge for aging
>out entries, we want br_fdb_cleanup removing the external_learned
>fdbs, but if there was another brport flag we could fine tune that.
>Say new flag is IFLA_BRPORT_AGING_OFFLOAD or something like that. I'm
>not sure how aging settings for the bridge are pushed down to offload
>hw, or if there is a different set for hw.
>
>But, isn't it nice to let Linux bridge control aging? That way,
>bridge -s fdb dump shows nice statistics on fdb entries. Hardware
>isn't involved in the aging processes (other than being told to remove
>an entry). Simple hardware equals simple driver. Linux remains
>control point.
>
It is indeed simpler. However, if the overhead of reading hit bits from the HW
and updating freshness of entries using br_fdb_external_learn_add() is too
expensive, it would force such platforms to disable learning sync altogether.
Therefore, I believe aging offload flag (could be sufficient at bridge level)
and external aging interval (possibly longer than the software aging interval)
will encourage drivers to use leaning sync.
>-scott
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" 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
* [PATCH] net: unisys: adding unisys virtnic driver
From: Neil Horman @ 2015-01-09 16:13 UTC (permalink / raw)
To: earfvids; +Cc: netdev
In-Reply-To: <1418842340-29894-1-git-send-email-earfvids@redhat.com>
>The purpose of this patch is to add Unisys virtual network driver
>into the network directory and also to start a discussion about
>the requirements needed.
>
>Signed-off-by: Erik Arfvidson <earfvids@redhat.com>
>---
> drivers/net/virtnic.c | 2475 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 2475 insertions(+)
> create mode 100644 drivers/net/virtnic.c
><driver mostly snipped>
>+
>+/*****************************************************/
>+/* Module init & exit functions */
>+/*****************************************************/
>+
>+static int __init
>+virtnic_mod_init(void)
>+{
>+ int error, i;
>+
>+ LOGINF("entering virtnic_mod_init");
>+ /* ASSERT RCVPOST_BUF_SIZE < 4K */
>+ if (RCVPOST_BUF_SIZE > PI_PAGE_SIZE) {
>+ LOGERR("**** FAILED RCVPOST_BUF_SIZE:%d larger than a page\n",
>+ RCVPOST_BUF_SIZE);
>+ return -1;
>+ }
>+ /* ASSERT RCVPOST_BUF_SIZE is big enough to hold eth header */
>+ if (RCVPOST_BUF_SIZE < ETH_HEADER_SIZE) {
>+ LOGERR("**** FAILED RCVPOST_BUF_SIZE:%d is <
ETH_HEADER_SIZE:%d\n",
>+ RCVPOST_BUF_SIZE, ETH_HEADER_SIZE);
>+ return -1;
>+ }
>+
>+ /* clear out array */
>+ for (i = 0; i < VIRTNICSOPENMAX; i++) {
>+ num_virtnic_open[i].netdev = NULL;
>+ num_virtnic_open[i].vnicinfo = NULL;
>+ }
>+ /* create workqueue for serverdown completion */
>+ virtnic_serverdown_workqueue =
>+ create_singlethread_workqueue("virtnic_serverdown");
>+ if (virtnic_serverdown_workqueue == NULL) {
>+ LOGERR("**** FAILED virtnic_serverdown_workqueue creation\n");
>+ return -1;
>+ }
>+ /* create workqueue for tx timeout reset */
>+ virtnic_timeout_reset_workqueue =
>+ create_singlethread_workqueue("virtnic_timeout_reset");
>+ if (virtnic_timeout_reset_workqueue == NULL) {
>+ LOGERR
>+ ("**** FAILED virtnic_timeout_reset_workqueue creation\n");
>+ return -1;
>+ }
>+ virtnic_debugfs_dir = debugfs_create_dir("virtnic", NULL);
>+ debugfs_create_file("info", S_IRUSR, virtnic_debugfs_dir,
>+ NULL, &debugfs_info_fops);
>+ debugfs_create_file("enable_ints", S_IWUSR,
>+ virtnic_debugfs_dir, NULL,
>+ &debugfs_enable_ints_fops);
>+
>+ error = virtpci_register_driver(&virtnic_driver);
>+ if (error < 0) {
So, I've been trying to puzzle out what the architecture of this driver is.
>From what I've been able to gather:
1) The device this driver interfaces too is not a real device, but rather some
multipurpose chip that can expose network functions as well as several other
devices.
2) It's (the hardware's) device exposure is driven by some sideband interface
outside of the purview of the operating system
3) The virtpci driver that you have in the staging tree is responsible for
interfacing the root pci bridge to your hardware so that it (again your
hardware) can act like a pci bus to interface to these administratively plumbed
devices.
4) The net devices that this driver registers are typically meant (though not
required) to be used by guests via pci passthrough.
Is that all about correct? Just trying to get a handle on what all is going on
here.
Operating under the assumption that the above is correct (please correct me if
I'm wrong), I've got a few comments.
A) This isn't going to be accepted until the bus driver that provides access to
the pci interface for this hardware is merged. Without that bit, this driver
can't do anything.
B) Looking at the virtpci driver, it neds alot of cleanup before it has a hope
of going in. On the upside though, I think most of the code that needs cleaning
up, really just needs removal. 90% of that file in staging isn't called by
anything that I can tell. Thats not completely accrurate, in that you seem to
have a side band input path via virtpci_ctrlchan_func, which gets called from
the uisctrl library that appears to be used to create and manage devices, but it
all deadends there. See uislib_client_inject_add_vhba or
uislib_client_inject_add_vnic for examples. So I don't see a whole lot of need
for (at least not yet). I presume that, if this stuff works, theres some other
method of plumbing devices on the hardware asside from the uislib in staging.
As such, you can remove it for now. If thats not the case, then you have much
bigger problems, as I'm not sure how any of this works at all, since I don't see
a path for plumbing devices.
C) This isn't really a virtio driver, in the sense that virtio_net or veth is,
its more of an SRIOV device by another name, in that it drives real hardware, or
at least a virtual function on a real pci device.
I think, if you want to get it accepted, the fastest road forward would be to do
the following:
1) Gut virtpci.c. Remove anything non-functional from it. That would separate
you from your uislib, and make virtpci both fairly standalone and reasonably
small. That (I think) should make virtpci more amenable to mainline acceptance
if you repost it (I'll have to let the linux-pci list review that
more closely however). If thats accepted it should allow the pci core to
properly probe devices belonging to the above virtnic driver
2) rework virtnic to register with the pci core, not the redundant
virtpci_driver_register api. There should be no need for that. That will make
this a full fledged pci driver, which will be nice. Perhaps also rename it
(unisys_vfnic or something more indicative of its nature, so as to separate it
from the virtio family of devices. There may be other cleanups to do in the
driver as well (I've not looked at it in depth yet)
That should put you in a position where you have a functioning nic driver for
your hardware that you can either pass to a guest via pci passthrough, or use as
backing for a virtio_nic or veth device. It will be much more lean, and
maintainable, and from there you can start adding management bits back in.
Regards
Neil
^ permalink raw reply
* Re: [PATCH v2 1/3] dtb: xgene: fix: Backward compatibility with older firmware
From: Ian Campbell @ 2015-01-09 15:59 UTC (permalink / raw)
To: Iyappan Subramanian
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
patches-qTEPVZfXA3Y, kchudgar-qTEPVZfXA3Y
In-Reply-To: <1415044796-5081-2-git-send-email-isubramanian-qTEPVZfXA3Y@public.gmane.org>
Hi Iyappan,
On Mon, 2014-11-03 at 11:59 -0800, Iyappan Subramanian wrote:
> The following kernel crash was reported when using older firmware (<= 1.13.28).
>
> [ 0.980000] libphy: APM X-Gene MDIO bus: probed
> [ 1.130000] Unhandled fault: synchronous external abort (0x96000010) at 0xffffff800009a17c
> [ 1.140000] Internal error: : 96000010 [#1] SMP
> [ 1.140000] Modules linked in:
> [ 1.140000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0+ #21
> [ 1.140000] task: ffffffc3f0110000 ti: ffffffc3f0064000 task.ti: ffffffc3f0064000
> [ 1.140000] PC is at ioread32+0x58/0x68
> [ 1.140000] LR is at xgene_enet_setup_ring+0x18c/0x1cc
I'm seeing what appears to be a similar crash (see the end) when booting
using UEFI firmware, which provides the DTB itself (as opposed to using
the kernel provided one like with u-boot).
Trying to boot using the kernel DTB instead of the firmware provided one
fails, I think because the UEFI firmware normally updates a bunch of
stuff at runtime in what it provides, but it can't in the external one.
(i.e. it has the wrong spintable stuff for cpu bringup)
This is running Debian's 3.16 kernel, which has the APM Ethernet related
stuff backported:
$ git log --oneline v3.16.7..debian/jessie/xgene
b2553d6 arm64: removed using of the mask attribute in the dts for reset bit.
2d209a4 arm64: add missing dts entry for X-Gene platform.
60651f8 dtb: Add SGMII based 1GbE node to APM X-Gene SoC device tree
3f3c3da dtb: Add 10GbE node to APM X-Gene SoC device tree
33b5408 drivers: net: xgene: fix: Use separate resources
092e35e drivers: net: xgene: Backward compatibility with older firmware
9f2bc2c drivers: net: xgene: Rewrite buggy loop in xgene_enet_ecc_init()
c566829 drivers: net: xgene: Add SGMII based 1GbE ethtool support
30bf224 drivers: net: xgene: Add SGMII based 1GbE support
0d03931 drivers: net: xgene: Preparing for adding SGMII based 1GbE
23a92cd drivers: net: xgene: Add 10GbE ethtool support
226068a drivers: net: xgene: Add 10GbE support
33f8dba drivers: net: xgene: Preparing for adding 10GbE support
a7b5fd0 dts: Add bindings for APM X-Gene SoC ethernet driver
82df3ba drivers: net: NET_XGENE should depend on HAS_DMA
0dcba55 net: xgene: fix possible NULL dereference in xgene_enet_free_desc_rings()
2aa3e0d net: xgene: Check negative return value of xgene_enet_get_ring_size()
589e045 drivers: net: Add APM X-Gene SoC ethernet driver support.
With the builtin DTB I see:
(initramfs) od -A x -t x4 /proc/device-tree/soc/ethernet@17020000/reg
000000 00000000 00000217 00000000 00d10000
000010 00000000 00000317 00000000 00040000
000020 00000000 00000010 00000000 00020000
Which seems to correspond to before your patch.
I'm running mustang_sw_1.13.29-beta, using the mustang_tianocore_ubt.fd
method to launch from u-boot.
Ian.
[ 7.662085] Unhandled fault: synchronous external abort (0x96000010) at 0xffffff800009a208
[ 7.670332] Internal error: : 96000010 [#1] SMP
[ 7.674839] Modules linked in: xgene_enet(+) of_mdio libphy dm_mod(+)
[ 7.681300] CPU: 0 PID: 97 Comm: systemd-udevd Not tainted 3.16.0-4-arm64 #1 Debian 3.16.7-ckt2-1
[ 7.690126] task: ffffffc3f9ca0c80 ti: ffffffc3f9d2c000 task.ti: ffffffc3f9d2c000
[ 7.697571] PC is at ioread32+0x58/0x68
[ 7.701388] LR is at xgene_ring_mgr_init+0x28/0x58 [xgene_enet]
[ 7.707276] pc : [<ffffffc0002e5318>] lr : [<ffffffbffc035d18>] pstate: a0000145
[ 7.714632] sp : ffffffc3f9d2f9c0
[ 7.717926] x29: ffffffc3f9d2f9c0 x28: 0000000000000001
[ 7.723229] x27: ffffffc0006fa000 x26: 0000000000000000
[ 7.728533] x25: ffffffc3f9ce9000 x24: ffffffc3f9ce9000
[ 7.733836] x23: ffffffc3eb876010 x22: ffffffc3eb876000
[ 7.739138] x21: ffffffc000763000 x20: ffffffc3f9ce98c0
[ 7.744443] x19: ffffffc3f9ce98c0 x18: 00000000c3663f63
[ 7.749745] x17: 00000000c14123be x16: 00000000ca92bd38
[ 7.755048] x15: 00000000d02a0bde x14: 0000000000000000
[ 7.760350] x13: 0000000000000000 x12: 0000000000000000
[ 7.765652] x11: 0000000000000000 x10: 0000000000000000
[ 7.770955] x9 : 0000000000000000 x8 : 0000000000000000
[ 7.776257] x7 : 0000000000000000 x6 : 0000000000000000
[ 7.781559] x5 : ffffffc00074b310 x4 : 0000000000000000
[ 7.786861] x3 : 0000000000000000 x2 : 000000000003ffff
[ 7.792165] x1 : ffffff800009a208 x0 : ffffff800009a208
[ 7.797467]
[ 7.798948] Process systemd-udevd (pid: 97, stack limit = 0xffffffc3f9d2c058)
[ 7.806046] Stack: (0xffffffc3f9d2f9c0 to 0xffffffc3f9d30000)
[ 7.811762] f9c0: f9d2f9d0 ffffffc3 fc035d18 ffffffbf f9d2f9f0 ffffffc3 fc035d6c ffffffbf
[ 7.819897] f9e0: f9ce98c0 ffffffc3 f9d2f9e0 ffffffc3 f9d2fa30 ffffffc3 fc038110 ffffffbf
[ 7.828032] fa00: f9ce98c0 ffffffc3 f9ce9000 ffffffc3 00763000 ffffffc0 f9ce9000 ffffffc3
[ 7.836167] fa20: 0000005c 00000000 00000000 00000000 f9d2fa80 ffffffc3 00343d24 ffffffc0
[ 7.844302] fa40: eb876010 ffffffc3 fc039f38 ffffffbf 0075d000 ffffffc0 00000000 00000000
[ 7.852436] fa60: fc039f60 ffffffbf 00000000 00000000 00000001 00000000 00000000 00000000
[ 7.860571] fa80: f9d2faa0 ffffffc3 00341ad0 ffffffc0 eb876010 ffffffc3 007cb000 ffffffc0
[ 7.868706] faa0: f9d2faf0 ffffffc3 00341edc ffffffc0 eb876010 ffffffc3 fc039f60 ffffffbf
[ 7.876840] fac0: eb876070 ffffffc3 00000000 00000000 0073d000 ffffffc0 00000000 00000000
[ 7.884974] fae0: fec449c0 ffffffc0 0033fa04 ffffffc0 f9d2fb20 ffffffc3 0033f9f8 ffffffc0
[ 7.893109] fb00: 00000000 00000000 fc039f60 ffffffbf 00341e30 ffffffc0 00000000 00000000
[ 7.901244] fb20: f9d2fb70 ffffffc3 003414f8 ffffffc0 fc039f60 ffffffbf f9c5d100 ffffffc3
[ 7.909378] fb40: 0073dd40 ffffffc0 ffffffe0 00000000 f9d2fb70 ffffffc3 00000000 00000000
[ 7.917512] fb60: eba48aa8 ffffffc3 ff4328e8 ffffffc3 f9d2fb90 ffffffc3 003410b4 ffffffc0
[ 7.925647] fb80: fc039f60 ffffffbf fc039f60 ffffffbf f9d2fbd0 ffffffc3 0034276c ffffffc0
[ 7.933781] fba0: fc039f60 ffffffbf fec4df00 ffffffc0 00000000 00000000 fc03d000 ffffffbf
[ 7.941916] fbc0: f9d2c000 ffffffc3 0073dd40 ffffffc0 f9d2fc00 ffffffc3 00343cec ffffffc0
[ 7.950050] fbe0: fc039f38 ffffffbf fec4df00 ffffffc0 006e07a0 ffffffc0 f9d2fc40 ffffffc3
[ 7.958185] fc00: f9d2fc30 ffffffc3 fc03d01c ffffffbf 006e07a0 ffffffc0 00081490 ffffffc0
[ 7.966319] fc20: 006e07a0 ffffffc0 fc03a240 ffffffbf f9d2fc40 ffffffc3 000814a0 ffffffc0
[ 7.974453] fc40: f9d2fcc0 ffffffc3 00109f30 ffffffc0 f9d2fe70 ffffffc3 00000001 00000000
[ 7.982588] fc60: fc03a258 ffffffbf f9d2c000 ffffffc3 fc03a290 ffffffbf fc03a240 ffffffbf
[ 7.990723] fc80: 0007d000 ffffff80 00000001 00000000 fc03a258 ffffffbf f9d2c000 ffffffc3
[ 7.998857] fca0: f9d2fcc0 ffffffc3 00109efc ffffffc0 f9d2fe70 ffffffc3 0010a264 ffffffc0
[ 8.006992] fcc0: f9d2fe40 ffffffc3 0010a8d8 ffffffc0 00000000 00000000 00000009 00000000
[ 8.015126] fce0: 94b29108 0000007f 94c78ee4 0000007f 60000000 00000000 00000015 00000000
[ 8.023261] fd00: 00000118 00000000 00000111 00000000 006e4000 ffffffc0 f9d2c000 ffffffc3
[ 8.031395] fd20: ff588500 ffffffc3 00106ad8 ffffffc0 fec449d0 ffffffc0 00000072 00000000
[ 8.039530] fd40: 0000006e 00000000 005e7140 ffffffc0 0000003f 00000000 0000feff 00000000
[ 8.047664] fd60: 0000fff1 00000000 0000001b 00000000 f9d2fde0 ffffffc3 0075a648 ffffffc0
[ 8.055799] fd80: 0075a3c8 ffffffc0 fc03d028 ffffffbf f9d2fec4 ffffffc3 000000f1 ffffff80
[ 8.063933] fda0: f9d2fe80 ffffffc3 94b29108 0000007f 006fa5b0 ffffffc0 007641a0 ffffffc0
[ 8.072068] fdc0: 60000000 00000000 00000015 00000000 00000010 00000000 0000138c 00000000
[ 8.080203] fde0: 00000001 ffff81a4 00000001 00000000 00000000 00000000 00000000 00000000
[ 8.088337] fe00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 8.096471] fe20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 8.104605] fe40: fb748da0 0000007f 0008421c ffffffc0 00000000 00000000 00000000 00000000
[ 8.112740] fe60: ffffffff ffffffff 00000009 00000000 0007d000 ffffff80 0000e3b8 00000000
[ 8.120874] fe80: 0008acb8 ffffff80 00083c8e ffffff80 00085428 ffffff80 00005478 00000000
[ 8.129009] fea0: 00005c40 00000000 fc03a178 ffffffbf 00000005 00000000 0000001a 0000001b
[ 8.137143] fec0: 00000012 0000000d 0000000c 00000000 00000009 00000000 94b29108 0000007f
[ 8.145278] fee0: 00000000 00000000 00000009 00000000 00000000 00000000 00000041 00000000
[ 8.153412] ff00: 00000001 00000000 00000001 00000000 00000111 00000000 6dff7364 644d3965
[ 8.161547] ff20: 00000000 00000000 0000000a 00000000 00000004 00000000 00000004 00000000
[ 8.169681] ff40: 67782f65 2d656e65 94cfa588 0000007f 94b3b290 0000007f 94c78ec0 0000007f
[ 8.177816] ff60: fb748b00 0000007f 74bd9070 00000055 00000000 00000000 94b29108 0000007f
[ 8.185950] ff80: 00020000 00000000 fb7493c8 0000007f 74bd9200 00000055 74be13e0 00000055
[ 8.194084] ffa0: 00000000 00000000 00000000 00000000 00020000 00000000 fb748da0 0000007f
[ 8.202219] ffc0: 94b22d44 0000007f fb748da0 0000007f 94c78ee4 0000007f 60000000 00000000
[ 8.210353] ffe0: 00000009 00000000 00000111 00000000 00000000 00000000 00000000 00000000
[ 8.218487] Call trace:
[ 8.220920] [<ffffffc0002e5318>] ioread32+0x58/0x68
[ 8.225773] [<ffffffbffc035d14>] xgene_ring_mgr_init+0x24/0x58 [xgene_enet]
[ 8.232699] [<ffffffbffc035d68>] xgene_enet_reset+0x20/0x17c [xgene_enet]
[ 8.239452] [<ffffffbffc03810c>] xgene_enet_probe+0x2c4/0x784 [xgene_enet]
[ 8.246292] [<ffffffc000343d20>] platform_drv_probe+0x28/0x60
[ 8.252008] [<ffffffc000341acc>] driver_probe_device+0xa4/0x3ac
[ 8.257896] [<ffffffc000341ed8>] __driver_attach+0xa8/0xb0
[ 8.263352] [<ffffffc00033f9f4>] bus_for_each_dev+0x68/0xac
[ 8.268895] [<ffffffc0003414f4>] driver_attach+0x2c/0x38
[ 8.274177] [<ffffffc0003410b0>] bus_add_driver+0x16c/0x248
[ 8.279720] [<ffffffc000342768>] driver_register+0x6c/0x138
[ 8.285262] [<ffffffc000343ce8>] __platform_driver_register+0x74/0x84
[ 8.291670] [<ffffffbffc03d018>] $x+0x18/0x24 [xgene_enet]
[ 8.297127] [<ffffffc00008149c>] do_one_initcall+0xcc/0x1bc
[ 8.302671] [<ffffffc000109f2c>] load_module+0x1a20/0x220c
[ 8.308127] [<ffffffc00010a8d4>] SyS_finit_module+0x94/0xc0
[ 8.313670] Code: 97ffffa5 12800000 a8c17bfd d65f03c0 (b9400000)
[ 8.319746] ---[ end trace f59ed15aa4f2049f ]---
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/1] csiostor:fix sparse warnings
From: Praveen Madhavan @ 2015-01-09 15:55 UTC (permalink / raw)
To: netdev, linux-scsi; +Cc: davem, JBottomley, hch, hariprasad, praveenm
This patch fixes sparse warning reported by kbuild.
Apply this on net-next since it depends on previous commit.
drivers/scsi/csiostor/csio_hw.c:259:17: sparse: cast to restricted __le32
drivers/scsi/csiostor/csio_hw.c:536:31: sparse: incorrect type in assignment
(different base types)
drivers/scsi/csiostor/csio_hw.c:536:31: expected unsigned int [unsigned]
[usertype] <noident>
drivers/scsi/csiostor/csio_hw.c:536:31: got restricted __be32 [usertype]
<noident>
>> drivers/scsi/csiostor/csio_hw.c:2012:5: sparse: symbol 'csio_hw_prep_fw' was
not declared. Should it be static?
Signed-off-by: Praveen Madhavan <praveenm@chelsio.com>
---
drivers/scsi/csiostor/csio_hw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/csiostor/csio_hw.c b/drivers/scsi/csiostor/csio_hw.c
index b70c15f..5c31fa6 100644
--- a/drivers/scsi/csiostor/csio_hw.c
+++ b/drivers/scsi/csiostor/csio_hw.c
@@ -256,7 +256,7 @@ csio_hw_seeprom_read(struct csio_hw *hw, uint32_t addr, uint32_t *data)
}
pci_read_config_dword(hw->pdev, base + PCI_VPD_DATA, data);
- *data = le32_to_cpu(*data);
+ *data = le32_to_cpu(*(__le32 *)data);
return 0;
}
@@ -533,7 +533,7 @@ csio_hw_read_flash(struct csio_hw *hw, uint32_t addr, uint32_t nwords,
if (ret)
return ret;
if (byte_oriented)
- *data = htonl(*data);
+ *data = (__force __u32) htonl(*data);
}
return 0;
}
@@ -2009,7 +2009,7 @@ static struct fw_info *find_fw_info(int chip)
return NULL;
}
-int csio_hw_prep_fw(struct csio_hw *hw, struct fw_info *fw_info,
+static int csio_hw_prep_fw(struct csio_hw *hw, struct fw_info *fw_info,
const u8 *fw_data, unsigned int fw_size,
struct fw_hdr *card_fw, enum csio_dev_state state,
int *reset)
--
2.0.2
^ permalink raw reply related
* Re: [PATCH net] ipv6: Prevent ipv6_find_hdr() from returning ENOENT for valid non-first fragments
From: Hannes Frederic Sowa @ 2015-01-09 15:50 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Rahul Sharma, netdev, linux-kernel, netfilter-devel
In-Reply-To: <20150109114506.GA4857@salvia>
On Fr, 2015-01-09 at 12:45 +0100, Pablo Neira Ayuso wrote:
> Hi Hannes,
>
> On Fri, Jan 09, 2015 at 12:34:15PM +0100, Hannes Frederic Sowa wrote:
> > On Fri, Jan 9, 2015, at 08:18, Rahul Sharma wrote:
> > > Hi Pablo,
> > >
> > > On Fri, Jan 9, 2015 at 5:35 AM, Pablo Neira Ayuso <pablo@netfilter.org>
> > > wrote:
> > > > On Thu, Jan 08, 2015 at 11:39:16PM +0100, Hannes Frederic Sowa wrote:
> > > >> Hi Pablo,
> > > >>
> > > >> On Thu, Jan 8, 2015, at 21:53, Pablo Neira Ayuso wrote:
> > > >> > I'm afraid we cannot just get rid of that !ipv6_ext_hdr() check. The
> > > >> > ipv6_find_hdr() function is designed to return the transport protocol.
> > > >> > After the proposed change, it will return extension header numbers.
> > > >> > This will break existing ip6tables rulesets since the `-p' option
> > > >> > relies on this function to match the transport protocol.
> > > >> >
> > > >> > Note that the AH header is skipped (see code a bit below this
> > > >> > problematic fragmentation handling) so the follow up header after the
> > > >> > AH header is returned as the transport header.
> > > >> >
> > > >> > We can probably return the AH protocol number for non-1st fragments.
> > > >> > However, that would be something new to ip6tables since nobody has
> > > >> > ever seen packet matching `-p ah' rules. Thus, we restore control to
> > > >> > the user to allow this, but we would accept all kind of fragmented AH
> > > >> > traffic through the firewall since we cannot know what transport
> > > >> > protocol contains from non-1st fragments (unless I'm missing anything,
> > > >> > I need to have a closer look at this again tomorrow with fresher
> > > >> > mind).
> > > >>
> > > >> The code in question is guarded by (_frag_off != 0), so we are
> > > >> definitely processing a non-1st fragment currently. The -p match would
> > > >> happen at the time when the packet is reassembled and thus ipv6_find_hdr
> > > >> will find the real transport (final) header at this point (I hope I
> > > >> followed the code correctly here).
> > > >
> > > > Then, Rahul should get things working by modprobing nf_defrag_ipv6.
> > >
> > > I already had nf_defrag_ipv6 installed when the issue occured. But I
> > > see ip6table_raw_hook returning NF_DROP for the second fragment.
> >
> > That's what I expected. I think the change only affects hooks before
> > reassembly.
>
> reassembly happens at NF_IP6_PRI_CONNTRACK_DEFRAG (-400), so that
> happens before NF_IP6_PRI_RAW (-300) in IPv6 which is where the raw
> table is placed.
I tried to reproduce it, but couldn't get non-1st fragments getting
dropped during traversal of the raw table. They get dropped earlier at
during reassembly or pass.
I agree with Pablo, I also would like to see more data.
Thanks,
Hannes
^ permalink raw reply
* Re: NULL pointer dereference at skb_queue_tail()
From: Eric Dumazet @ 2015-01-09 15:45 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: cwang, netdev
In-Reply-To: <201501092220.DIB43754.FFMQOSJLOOHVtF@I-love.SAKURA.ne.jp>
On Fri, 2015-01-09 at 22:20 +0900, Tetsuo Handa wrote:
> Would you tell me which versions to test?
Could you do a bisection ?
I do not see obvious bugs in af_unix.c, so it might be a corruption from
another part of the code, reusing a freed skb.
^ permalink raw reply
* Re: [PATCH] net: unisys: adding unisys virtnic driver
From: Jes Sorensen @ 2015-01-09 15:44 UTC (permalink / raw)
To: Erik Arfvidson
Cc: benjamin.romer, netdev, dzickus, davem, Bruce.Vessey,
sparmaintainer, prarit, Neil Horman
In-Reply-To: <1418842340-29894-1-git-send-email-earfvids@redhat.com>
Erik Arfvidson <earfvids@redhat.com> writes:
> The purpose of this patch is to add Unisys virtual network driver
> into the network directory and also to start a discussion about
> the requirements needed.
>
> Signed-off-by: Erik Arfvidson <earfvids@redhat.com>
Erik,
I was discussing this with colleagues and I want to give you some
general comments on this. My comments are not specific to virtnic.c
itself.
Looking over the logs of drivers/staging/unisys, I noticed a fair amount
of cleanups has been applied, but not a lot of fixes addressing what I
would consider the real issues.
The first thing you should work on is to get rid of
drivers/staging/unisys/uislib - it looks to provide a lot of wrappers
and utility functions which already exist. You need to address things
like:
- Custom atomic primitives (uisqueue.c)
- List handlers (use list.h) and all the utility functions we provide
- Functions for launching killing kernel threads (uisthread)
- There is most of a bus implementation in there - is this really
needed, ie. are the devices sitting on a PCI bus, or is this some
special bus type?
- Use proper data types - your code should contain no 'long long' ever!
If you need data types of a specific size, use u8/u16/u32/u64, and
please get rid of broken Windows stuff such as BOOL and #pragma.
- /proc handlers - you should most likely be using /sys
(configs/debugfs) and don't wrap things in libraries, do it near the
code using it.
Basically I recommend you start working your way through uislib, and
once you have eliminated 90% of it, you should be a lot closer to code
that can go into mainline.
I know my colleague Neil has some issues on this specific driver, which
I have less insight into, so I think he'll post some comments on that
too.
I hope this is helpful!
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH net-next v2 1/8] r8169:change rtl8168dp jumbo frame patch
From: Sergei Shtylyov @ 2015-01-09 15:41 UTC (permalink / raw)
To: Chunhao Lin, netdev; +Cc: nic_swsd, linux-kernel
In-Reply-To: <1420817166-9868-2-git-send-email-hau@realtek.com>
Hello.
On 1/9/2015 6:25 PM, Chunhao Lin wrote:
> RTL8168DP jumbo frame patch is the same as RTL8168C. So, for RTL8168DP,
> change to use RTL8168C jumbo frame patch. Also reomve uncessary function
s/reomve uncessary/remove unnecessary/.
> "r8168dp_hw_jumbo_enable" and "r8168dp_hw_jumbo_disable".
>
> Signed-off-by: Chunhao Lin <hau@realtek.com>
WBR, Sergei
^ permalink raw reply
* [PATCH net-next v2 6/8] r8169:update pcie ephy parameters to decrease the resume time from L0s to L0
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
For RTL8168EVL, RTL8168F, RTL8411, and RTL8105E, their pcie ephy will have bit
error check reset after receive FTS and cause pcie ephy enter recovery mode.
This will cause pcie ephy resume from L0s to L0 too slow.
This patch adjust the pcie ephy parameter to decrease the resume time from L0s
to L0.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index ade7144..483fa40 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5778,7 +5778,9 @@ static void rtl_hw_start_8168e_2(struct rtl8169_private *tp)
struct pci_dev *pdev = tp->pci_dev;
static const struct ephy_info e_info_8168e_2[] = {
{ 0x09, 0x0000, 0x0080 },
- { 0x19, 0x0000, 0x0224 }
+ { 0x19, 0x0000, 0x0224 },
+ { 0x00, 0x0000, 0x0008 },
+ { 0x0c, 0x3df0, 0x0200 }
};
rtl_csi_access_enable_1(tp);
@@ -5850,7 +5852,9 @@ static void rtl_hw_start_8168f_1(struct rtl8169_private *tp)
{ 0x06, 0x00c0, 0x0020 },
{ 0x08, 0x0001, 0x0002 },
{ 0x09, 0x0000, 0x0080 },
- { 0x19, 0x0000, 0x0224 }
+ { 0x19, 0x0000, 0x0224 },
+ { 0x00, 0x0000, 0x0008 },
+ { 0x0c, 0x3df0, 0x0200 }
};
rtl_hw_start_8168f(tp);
@@ -5865,17 +5869,19 @@ static void rtl_hw_start_8168f_1(struct rtl8169_private *tp)
static void rtl_hw_start_8411(struct rtl8169_private *tp)
{
- static const struct ephy_info e_info_8168f_1[] = {
+ static const struct ephy_info e_info_8411[] = {
{ 0x06, 0x00c0, 0x0020 },
{ 0x0f, 0xffff, 0x5200 },
{ 0x1e, 0x0000, 0x4000 },
- { 0x19, 0x0000, 0x0224 }
+ { 0x19, 0x0000, 0x0224 },
+ { 0x00, 0x0000, 0x0008 },
+ { 0x0c, 0x3df0, 0x0200 }
};
rtl_hw_start_8168f(tp);
rtl_pcie_state_l2l3_enable(tp, false);
- rtl_ephy_init(tp, e_info_8168f_1, ARRAY_SIZE(e_info_8168f_1));
+ rtl_ephy_init(tp, e_info_8411, ARRAY_SIZE(e_info_8411));
rtl_w0w1_eri(tp, 0x0d4, ERIAR_MASK_0011, 0x0c00, 0x0000, ERIAR_EXGMAC);
}
@@ -6397,7 +6403,8 @@ static void rtl_hw_start_8105e_1(struct rtl8169_private *tp)
{ 0x03, 0, 0x0001 },
{ 0x19, 0, 0x0100 },
{ 0x19, 0, 0x0004 },
- { 0x0a, 0, 0x0020 }
+ { 0x0a, 0, 0x0020 },
+ { 0x05, 0, 0x2000 }
};
/* Force LAN exit from ASPM if Rx/Tx are not idle */
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 4/8] r8169:rtl8168dp rev.c pcie ephy setting is the same as rtl8168dp rev.b
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
Thease two chips should use the same pcie ephy parameters. So only need
function rtl_hw_start_8168d_4. Function rtl_hw_start_8168dp is uncessary.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 20 +-------------------
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 540a6b8..928e35a 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5711,21 +5711,6 @@ static void rtl_hw_start_8168d(struct rtl8169_private *tp)
RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) & ~R8168_CPCMD_QUIRK_MASK);
}
-static void rtl_hw_start_8168dp(struct rtl8169_private *tp)
-{
- void __iomem *ioaddr = tp->mmio_addr;
- struct pci_dev *pdev = tp->pci_dev;
-
- rtl_csi_access_enable_1(tp);
-
- if (tp->dev->mtu <= ETH_DATA_LEN)
- rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
-
- RTL_W8(MaxTxPacketSize, TxPacketMax);
-
- rtl_disable_clock_request(pdev);
-}
-
static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -6271,11 +6256,8 @@ static void rtl_hw_start_8168(struct net_device *dev)
break;
case RTL_GIGA_MAC_VER_28:
- rtl_hw_start_8168d_4(tp);
- break;
-
case RTL_GIGA_MAC_VER_31:
- rtl_hw_start_8168dp(tp);
+ rtl_hw_start_8168d_4(tp);
break;
case RTL_GIGA_MAC_VER_32:
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 8/8] r8169:update rtl8168f rev.b pcie ephy parameter
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
RTL8168F rev.B does not have to set following two ephy parameters.
{ 0x06, 0x00c0, 0x0020 }
{ 0x08, 0x0001, 0x0002 }
Add function rtl_hw_start_8168f_2 to set RTL8168F rev.B ephy parameters,
instead of using function rtl_hw_start_8168f_1.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index aa12833..0c870f5 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5867,6 +5867,26 @@ static void rtl_hw_start_8168f_1(struct rtl8169_private *tp)
RTL_W8(EEE_LED, RTL_R8(EEE_LED) & ~0x07);
}
+static void rtl_hw_start_8168f_2(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ static const struct ephy_info e_info_8168f_2[] = {
+ { 0x09, 0x0000, 0x0080 },
+ { 0x19, 0x0000, 0x0224 },
+ { 0x00, 0x0000, 0x0008 },
+ { 0x0c, 0x3df0, 0x0200 }
+ };
+
+ rtl_hw_start_8168f(tp);
+
+ rtl_ephy_init(tp, e_info_8168f_2, ARRAY_SIZE(e_info_8168f_2));
+
+ rtl_w0w1_eri(tp, 0x0d4, ERIAR_MASK_0011, 0x0c00, 0xff00, ERIAR_EXGMAC);
+
+ /* Adjust EEE LED frequency */
+ RTL_W8(EEE_LED, RTL_R8(EEE_LED) & ~0x07);
+}
+
static void rtl_hw_start_8411(struct rtl8169_private *tp)
{
static const struct ephy_info e_info_8411[] = {
@@ -6276,9 +6296,11 @@ static void rtl_hw_start_8168(struct net_device *dev)
break;
case RTL_GIGA_MAC_VER_35:
- case RTL_GIGA_MAC_VER_36:
rtl_hw_start_8168f_1(tp);
break;
+ case RTL_GIGA_MAC_VER_36:
+ rtl_hw_start_8168f_2(tp);
+ break;
case RTL_GIGA_MAC_VER_38:
rtl_hw_start_8411(tp);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 7/8] r8169:update rtl8402 pcie ephy parameter
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
Remove following unnecessary ephy parameter.
{ 0x1e, 0, 0x4000 }
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 483fa40..aa12833 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6431,8 +6431,7 @@ static void rtl_hw_start_8402(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
static const struct ephy_info e_info_8402[] = {
- { 0x19, 0xffff, 0xff64 },
- { 0x1e, 0, 0x4000 }
+ { 0x19, 0xffff, 0xff64 }
};
rtl_csi_access_enable_2(tp);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 5/8] r8169:update rtl8168dp pcie ephy parameters to improve power consumption
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
The following parameter will disable more pcie ephy block (like pcie ephy
read/write clock.....etc ) to save more power when in aspm+clkreq mode.
{ 0x10, 0x0004, 0x0000 }
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 928e35a..ade7144 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5718,7 +5718,8 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
static const struct ephy_info e_info_8168d_4[] = {
{ 0x0b, 0x0000, 0x0048 },
{ 0x19, 0x0020, 0x0050 },
- { 0x0c, 0x0100, 0x0020 }
+ { 0x0c, 0x0100, 0x0020 },
+ { 0x10, 0x0004, 0x0000 }
};
rtl_csi_access_enable_1(tp);
--
1.9.1
^ permalink raw reply related
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