* RE: [PATCH 0/7] bna: Update driver version to 3.0.23.0
From: Jing Huang @ 2012-04-04 23:46 UTC (permalink / raw)
To: David Miller, shemminger@vyatta.com
Cc: netdev@vger.kernel.org, Adapter Linux Open SRC Team
In-Reply-To: <20120404.181718.345441045492163774.davem@davemloft.net>
>> When are you going to integrate multi-queue support which is already
>> available in your out of tree driver?
>
>I hope your Brocade folks aren't playing the "try to make the out-of-tree
>driver more desirable than the in-tree one" game. I would find that really
>irritating.
Hi Stephen & David
We submitted our mutli-TX queue implementation last year but it was not accepted. The concern was mainly on our iSCSI over DCB implementation because we had used select_queue() to map iSCSI pkts to a queue derived from DCB configuration by inspecting the well known TCP port number. The community feedback was to use ndo_setup_tc to setup up priority to queue mapping and use dcb_setapp() routines to program the iscsi TLV and provide priority info to user space applications.
We are working on the implementation for our next driver release and will plan to submit the upstream patch after it has gone through QA validation later this year.
However, if you are ok with the existing implementation, we would like to resubmit the current implementation to enable feature parity with out of box driver.
Thanks
Jing
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Stephen Hemminger @ 2012-04-04 23:55 UTC (permalink / raw)
To: Arvid Brodin; +Cc: David S. Miller, netdev, Bruno Ferreira, Arvid Brodin
In-Reply-To: <4F7CD4BC.4000006@enea.com>
On Thu, 5 Apr 2012 01:09:48 +0200
Arvid Brodin <arvid.brodin@enea.com> wrote:
> Stephen Hemminger wrote:
> > On Tue, 27 Mar 2012 15:20:45 +0200
> > Arvid Brodin <arvid.brodin@enea.com> wrote:
> >
> >> +config NONSTANDARD_HSR
> >> + bool "HSR: Use efficient tag (breaks HSR standard, read help!)"
> >> + depends on HSR
> >> + ---help---
> >> + The HSR standard specifies a 6-byte HSR tag to be inserted into the
> >> + transmitted network frames. This breaks the 32-bit alignment that the
> >> + Linux network stack relies on, and would cause kernel panics on
> >> + certain architectures. To avoid this, the whole frame payload is
> >> + memmoved 2 bytes on reception on these architectures - which is very
> >> + inefficient!
> >
> > This option won't fly. Don't do it.
> > If you need to copy/realign packets on some architecture the stack
> > should be changed to handle it.
>
> Ok. The problems are in net/ipv4/icmp.c. The below patch seems to do
> the trick for me - does it look OK (and if so, should I resend it as
> a normal patch instead of a reply or is this enough)?
>
> Note that I've only triggered this problem in icmp_echo(), but I
> noticed that icmp_timestamp() does the same thing, so I made the change
> there too.
>
>
> [PATCH] net/ipv4/icmp: Fix kernel panic due to unaligned access with HSR on AVR32
>
> icmp_echo() and icmp_timestamp() requires the icmphdr struct to be
> 32-bit aligned. This causes a kernel panic on AVR32 when HSR is used,
> since the HSR protocol inserts a 6-byte "HSR tag" into Ethernet frame
> headers, thus changing the alignment.
>
> HSR = IEC 62439-3 High-availability Seamless Redundancy.
>
> Signed-off-by: Arvid Brodin <arvid.brodin@xdin.com>
> ---
> net/ipv4/icmp.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
> index 2cb2bf8..fdd8097 100644
> --- a/net/ipv4/icmp.c
> +++ b/net/ipv4/icmp.c
> @@ -818,7 +818,8 @@ static void icmp_echo(struct sk_buff *skb)
> if (!net->ipv4.sysctl_icmp_echo_ignore_all) {
> struct icmp_bxm icmp_param;
>
> - icmp_param.data.icmph = *icmp_hdr(skb);
> + memcpy(&icmp_param.data.icmph, icmp_hdr(skb),
> + sizeof(icmp_param.data.icmph));
> icmp_param.data.icmph.type = ICMP_ECHOREPLY;
> icmp_param.skb = skb;
> icmp_param.offset = 0;
> @@ -854,7 +855,8 @@ static void icmp_timestamp(struct sk_buff *skb)
> icmp_param.data.times[2] = icmp_param.data.times[1];
> if (skb_copy_bits(skb, 0, &icmp_param.data.times[0], 4))
> BUG();
> - icmp_param.data.icmph = *icmp_hdr(skb);
> + memcpy(&icmp_param.data.icmph, icmp_hdr(skb),
> + sizeof(icmp_param.data.icmph));
> icmp_param.data.icmph.type = ICMP_TIMESTAMPREPLY;
> icmp_param.data.icmph.code = 0;
> icmp_param.skb = skb;
That isn't so bad, doing a memcpy versus a structure copy.
^ permalink raw reply
* [patch net-next 1/2] team: add binary option type
From: Jiri Pirko @ 2012-04-04 22:16 UTC (permalink / raw)
To: netdev
Cc: davem, eric.dumazet, bhutchings, shemminger, raise.sail,
nuno.martins, matt
For transfering generic binary data (e.g. BPF code), introduce new
binary option type.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/team/team.c | 30 ++++++++++++++++++++++++++----
include/linux/if_team.h | 8 ++++++++
2 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 0db6e66..ea96f82 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1145,10 +1145,7 @@ team_nl_option_policy[TEAM_ATTR_OPTION_MAX + 1] = {
},
[TEAM_ATTR_OPTION_CHANGED] = { .type = NLA_FLAG },
[TEAM_ATTR_OPTION_TYPE] = { .type = NLA_U8 },
- [TEAM_ATTR_OPTION_DATA] = {
- .type = NLA_BINARY,
- .len = TEAM_STRING_MAX_LEN,
- },
+ [TEAM_ATTR_OPTION_DATA] = { .type = NLA_BINARY },
};
static int team_nl_cmd_noop(struct sk_buff *skb, struct genl_info *info)
@@ -1257,6 +1254,7 @@ static int team_nl_fill_options_get(struct sk_buff *skb,
list_for_each_entry(option, &team->option_list, list) {
struct nlattr *option_item;
long arg;
+ struct team_option_binary tbinary;
/* Include only changed options if fill all mode is not on */
if (!fillall && !option->changed)
@@ -1290,6 +1288,15 @@ static int team_nl_fill_options_get(struct sk_buff *skb,
(char *) arg))
goto nla_put_failure;
break;
+ case TEAM_OPTION_TYPE_BINARY:
+ if (nla_put_u8(skb, TEAM_ATTR_OPTION_TYPE, NLA_BINARY))
+ goto nla_put_failure;
+ arg = (long) &tbinary;
+ team_option_get(team, option, &arg);
+ if (nla_put(skb, TEAM_ATTR_OPTION_DATA,
+ tbinary.data_len, tbinary.data))
+ goto nla_put_failure;
+ break;
default:
BUG();
}
@@ -1374,6 +1381,9 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
case NLA_STRING:
opt_type = TEAM_OPTION_TYPE_STRING;
break;
+ case NLA_BINARY:
+ opt_type = TEAM_OPTION_TYPE_BINARY;
+ break;
default:
goto team_put;
}
@@ -1382,19 +1392,31 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
list_for_each_entry(option, &team->option_list, list) {
long arg;
struct nlattr *opt_data_attr;
+ struct team_option_binary tbinary;
+ int data_len;
if (option->type != opt_type ||
strcmp(option->name, opt_name))
continue;
opt_found = true;
opt_data_attr = mode_attrs[TEAM_ATTR_OPTION_DATA];
+ data_len = nla_len(opt_data_attr);
switch (opt_type) {
case TEAM_OPTION_TYPE_U32:
arg = nla_get_u32(opt_data_attr);
break;
case TEAM_OPTION_TYPE_STRING:
+ if (data_len > TEAM_STRING_MAX_LEN) {
+ err = -EINVAL;
+ goto team_put;
+ }
arg = (long) nla_data(opt_data_attr);
break;
+ case TEAM_OPTION_TYPE_BINARY:
+ tbinary.data_len = data_len;
+ tbinary.data = nla_data(opt_data_attr);
+ arg = (long) &tbinary;
+ break;
default:
BUG();
}
diff --git a/include/linux/if_team.h b/include/linux/if_team.h
index 58404b0..41163ac 100644
--- a/include/linux/if_team.h
+++ b/include/linux/if_team.h
@@ -68,6 +68,7 @@ struct team_mode_ops {
enum team_option_type {
TEAM_OPTION_TYPE_U32,
TEAM_OPTION_TYPE_STRING,
+ TEAM_OPTION_TYPE_BINARY,
};
struct team_option {
@@ -82,6 +83,13 @@ struct team_option {
bool removed;
};
+struct team_option_binary {
+ u32 data_len;
+ void *data;
+};
+
+#define team_optarg_tbinary(arg) (*((struct team_option_binary **) arg))
+
struct team_mode {
struct list_head list;
const char *kind;
--
1.7.9.1
^ permalink raw reply related
* Re: [PATCH 0/7] bna: Update driver version to 3.0.23.0 (resubmit)
From: David Miller @ 2012-04-05 0:15 UTC (permalink / raw)
To: huangj; +Cc: netdev, AdapterLinuxOpenSrcExtTeam
In-Reply-To: <E5313AF6F2BFD14293E5FD0F94750F86B3A74DEE55@HQ1-EXCH01.corp.brocade.com>
From: Jing Huang <huangj@Brocade.COM>
Date: Wed, 4 Apr 2012 16:07:22 -0700
> The ioc init semaphore register is only used by driver. Firmware
> will never touch this register. It will only be set to 1 when there
> is a driver instance holding it. So in practice, the infinite look
> will happen only if a driver instance grab the semaphore but forgot
> to release it. We add this logic to serialize register access for
> potential case of concurrent PCI function probe, which seems pretty
> rare in Linux.
Thanks for the clarification.
> I agree that this code looks ugly and wrong in theory. We will consider remove it or
> implement some timeout logic for it.
Ok, great.
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: David Miller @ 2012-04-05 0:17 UTC (permalink / raw)
To: arvid.brodin; +Cc: shemminger, netdev, balferreira, arvid.brodin
In-Reply-To: <4F7CD4BC.4000006@enea.com>
From: Arvid Brodin <arvid.brodin@enea.com>
Date: Thu, 5 Apr 2012 01:09:48 +0200
> - icmp_param.data.icmph = *icmp_hdr(skb);
> + memcpy(&icmp_param.data.icmph, icmp_hdr(skb),
> + sizeof(icmp_param.data.icmph));
GCC can and will optimize this into an inline assignment, and thus
have the same unaligned access problems, because it determines
alignment based upon the types involved.
^ permalink raw reply
* Re: [PATCH 3/3] netdma: adding alignment check for NETDMA ops
From: David Miller @ 2012-04-05 0:18 UTC (permalink / raw)
To: dave.jiang; +Cc: dan.j.williams, linux-kernel, netdev
In-Reply-To: <20120404231046.20605.13918.stgit@djiang5-linux.ch.intel.com>
From: Dave Jiang <dave.jiang@intel.com>
Date: Wed, 04 Apr 2012 16:10:46 -0700
> This is the fallout from adding memcpy alignment workaround for certain
> IOATDMA hardware. NetDMA will only use DMA engine that can handle byte align
> ops.
>
> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: David Miller @ 2012-04-05 0:21 UTC (permalink / raw)
To: shemminger; +Cc: arvid.brodin, netdev, balferreira, arvid.brodin
In-Reply-To: <20120404165559.5223ab95@s6510.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 4 Apr 2012 16:55:59 -0700
> That isn't so bad, doing a memcpy versus a structure copy.
GCC is going to inline the memcpy and thus we'll still do the
unaligned accesses. This change therefore won't fix the problem.
^ permalink raw reply
* Re: [PATCH net-next V6 7/8] net/dcb: Add an optional max rate attribute
From: John Fastabend @ 2012-04-05 0:23 UTC (permalink / raw)
To: Amir Vadai, Or Gerlitz
Cc: David S. Miller, netdev, Roland Dreier, Yevgeny Petrilin,
Oren Duer, Amir Vadai
In-Reply-To: <1333537084-9186-8-git-send-email-amirv@mellanox.com>
On 4/4/2012 3:58 AM, Amir Vadai wrote:
> Although not specified in 8021Qaz spec, it could be useful to enable drivers
> whose HW supports setting a rate limit for an ETS TC. This patch adds this
> optional attribute to DCB netlink. To use it, drivers should implement and
> register the callbacks ieee_setmaxrate and ieee_getmaxrate. The units are 64
> bits long and specified in Kbps to enable usage over both slow and very fast
> networks.
>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
> ---
Or, Amir,
Two more comments inline really just minor nit picks but if your going
to roll new patch mind as well. I'll ack a patch with these changes.
> include/linux/dcbnl.h | 5 +++++
> include/net/dcbnl.h | 2 ++
> net/dcb/dcbnl.c | 21 +++++++++++++++++++++
> 3 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
> index 65a2562..ec8e372 100644
> --- a/include/linux/dcbnl.h
> +++ b/include/linux/dcbnl.h
> @@ -67,6 +67,10 @@ struct ieee_ets {
> __u8 reco_prio_tc[IEEE_8021QAZ_MAX_TCS];
> };
>
annotate ieee_maxrate so implementers use it correctly per previous note.
> +struct ieee_maxrate {
> + __u64 tc_maxrate[IEEE_8021QAZ_MAX_TCS];
> +};
> +
> /* This structure contains the IEEE 802.1Qaz PFC managed object
> *
> * @pfc_cap: Indicates the number of traffic classes on the local device
> @@ -321,6 +325,7 @@ enum ieee_attrs {
> DCB_ATTR_IEEE_PEER_ETS,
> DCB_ATTR_IEEE_PEER_PFC,
> DCB_ATTR_IEEE_PEER_APP,
> + DCB_ATTR_IEEE_MAXRATE,
> __DCB_ATTR_IEEE_MAX
> };
> #define DCB_ATTR_IEEE_MAX (__DCB_ATTR_IEEE_MAX - 1)
> diff --git a/include/net/dcbnl.h b/include/net/dcbnl.h
> index f55c980..fc5d5dc 100644
> --- a/include/net/dcbnl.h
> +++ b/include/net/dcbnl.h
> @@ -48,6 +48,8 @@ struct dcbnl_rtnl_ops {
> /* IEEE 802.1Qaz std */
> int (*ieee_getets) (struct net_device *, struct ieee_ets *);
> int (*ieee_setets) (struct net_device *, struct ieee_ets *);
> + int (*ieee_getmaxrate) (struct net_device *, struct ieee_maxrate *);
> + int (*ieee_setmaxrate) (struct net_device *, struct ieee_maxrate *);
> int (*ieee_getpfc) (struct net_device *, struct ieee_pfc *);
> int (*ieee_setpfc) (struct net_device *, struct ieee_pfc *);
> int (*ieee_getapp) (struct net_device *, struct dcb_app *);
> diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
> index 36f37af..d3df048 100644
> --- a/net/dcb/dcbnl.c
> +++ b/net/dcb/dcbnl.c
> @@ -178,6 +178,8 @@ static const struct nla_policy dcbnl_ieee_policy[DCB_ATTR_IEEE_MAX + 1] = {
> [DCB_ATTR_IEEE_ETS] = {.len = sizeof(struct ieee_ets)},
> [DCB_ATTR_IEEE_PFC] = {.len = sizeof(struct ieee_pfc)},
> [DCB_ATTR_IEEE_APP_TABLE] = {.type = NLA_NESTED},
> + [DCB_ATTR_IEEE_MAXRATE] = {.len = sizeof(struct ieee_maxrate)},
> +
spurious newline remove it
> };
>
> static const struct nla_policy dcbnl_ieee_app[DCB_ATTR_IEEE_APP_MAX + 1] = {
> @@ -1246,6 +1248,17 @@ static int dcbnl_ieee_fill(struct sk_buff *skb, struct net_device *netdev)
> goto nla_put_failure;
> }
>
> + if (ops->ieee_getmaxrate) {
> + struct ieee_maxrate maxrate;
> + err = ops->ieee_getmaxrate(netdev, &maxrate);
> + if (!err) {
> + err = nla_put(skb, DCB_ATTR_IEEE_MAXRATE,
> + sizeof(maxrate), &maxrate);
align sizeof with skb
Thanks,
John
^ permalink raw reply
* Re: [PATCH V1 1/1] NET: add a bpf jit for Alpha
From: Jan Seiffert @ 2012-04-05 0:24 UTC (permalink / raw)
To: Richard Henderson
Cc: netdev, linux-kernel, Matt Evans, Eric Dumazet, David S. Miller,
linux-arch, linux-alpha
In-Reply-To: <4F7C5A65.7090504@redhat.com>
Richard Henderson schrieb:
Thanks for the review Mr.Henderson. I'm so grateful you taken some of your
valuable time for this.
> On 04/02/2012 03:51 PM, Jan Seiffert wrote:
[snip]
> You will never need NEGLI or SEXTLI, as both results can be had with LDA.
>
Removed
>> +static void load_complex_constant(u32 *image, struct codegen_context *ctx,
>> + unsigned int i, int K, int r)
>> +
>> +{
>> + if (K == 0) {
>> + ALPHA_CLR(r);
>> + return;
>> + }
>> + if (optimize_size == 0 || constant_needs(K) < 2 ||
>> + i > (0x7fff/sizeof(struct sock_filter))) {
>> + add_constant(image, ctx, K, r_zero, r);
>> + } else {
>> + /* load the constant from the filter program */
>> + ALPHA_LDL(r_sf, (i * sizeof(struct sock_filter)) +
>> + offsetof(struct sock_filter, k), r);
>
> Worst case for constant loading is 3. That's the same as the delay for
> loading from memory. Unless you're very concerned about translated size
> of the filter,
I'm unsure. The problem goes like this:
Since constant loading can take so much instructions, the code tends to
get big. This is bad for jump ranges, the icache and pinned kernel mem.
I would not mind about it (it's a RISC, it is meant to be that way), if
the constants weren't right there. We get the original filter program
(which contains the constants) passed as second parameter, on a silver
platter (i was even thinking about moving the second parameter 32k
forward to get the full imm16 range, on the other hand if struct
sock_filter is 8 byte on Alpha, then +32k is good enough for
MAX_BPF_INSN == 4096).
Essentially this is two questions, one for the Alpha µ-arch gurus and
one for the kernel (net-)devs.
µ-Arch Gurus: How bad are mem accesses in contrast to icache for example.
Kernel devs: how important is memory consumption/how much "faster"
the jitted code has to be?
> I'd drop this condition and make your compiler run faster.
>
>
>> + if (optimize_size == 0 || constant_needs(K) < 2 ||
>> + i > (0x7fff/sizeof(struct sock_filter))) {
>> + add_constant(image, ctx, K, r_A, r_t);
>> + ALPHA_SEXTL(r_t, r_t);
>
> OTOH, this test should be simply is_imm8 and use ADDLI,
> else is_imm8(-K) use SUBLI, else load_constant ADDL.
>
add_constant takes care of that, only the entry condition is so
complicated because of the optimize_size case.
[snip - ugly and optimization]
>
> Really?
yes, i was typing as fast as i was thinking: "hmmm, a constant can
look like this or like that or like this...". The optimizations where an
"afterthought", i first broke the operations out into a helper and simply
made it work. Because i knew there are some shenanigans you can do with
zapnot i revisited it at the end. I will now grab a brown paper bag.
> This ought to be as simple as
>
> mask = 0;
> for (j = 0; j < 4; j++) {
> int b = (K >> i*8) & 0xff;
> if (b == 0xff)
> mask |= 1 << i;
> else if (b != 0)
> mask = -1;
> }
> if (mask != -1) {
> ALPHA_ZAPNOTI(r_A, mask, r_t);
> return;
> }
>
Works like a charm, only had to change i for j. Thanks!
[snip - or 0xffffffff]
>
> Really? Think about what you're doing here. LDA(r_A, -1)
>
changed
[snip]
>> + if (off == 0)
>> + ALPHA_ZEXTW(r, r);
>> + else
>> + ALPHA_EXTWLI(r, off, r);
>
> No point in the off==0 special case.
>
I was thinking maybe the zapnot^wzextw is faster, because it does not
have to do the shift and it should be the common case.
But if extw is good enough, thus removed.
>> +static void emit_call(u32 *image, struct codegen_context *ctx,
>> + void *func, int r)
>> +{
>> + ptrdiff_t disp = (char *)func - (char *)&image[ctx->idx + 1];
>> + if (disp >= -2147483648 && disp <= 2147483647) {
>> + if (is_imm_jdisp(disp)) {
>> + ALPHA_BSR(r, disp);
>> + return;
>> + }
>
> Is this known to be calling another BPF function, and not back into C?
> Otherwise you've got an error in PV handling for the calling convention.
>
It is known to either call special bpf helper or __divlu (the kernel
version). The special helper are responsible for setting pv right when
they have to call to C again (which is deemed as the exceptional case).
That was my idea, so i don't have to set pv again after every call,
which would bloat up every filter program.
But i don't know if the helper do the "pv and call and gp"-dance right :(
[snip - div 0 test]
>
> Re-order these to clear r_ret before the cjmp and you don't need
> the branch-around branch.
>
Can't do.
When building the program we are searching for a ret 0 case.
As long as no case is found (or is never found), we have to build one.
Besides, i know it's dirty, r_ret and r_A share the same register.
I was squeezing on the register usage so i may use the register as
storage for the 16 bpf mem[] slots like powerpc, i mean Alpha has
31 like powerpc. But in the end i was to stupid to achieve this.
At least this hack saves a mov at the end.
>> + case BPF_S_ALU_LSH_X: /* A <<= X; */
>> + ctx->seen |= SEEN_XREG;
>> + ALPHA_SLL(r_A, r_X, r_A);
>> + ALPHA_ZEXTL(r_A, r_A);
>
> So... are you attempting to have canonical zero-extended values,
> or canonical sign-extended values? Because at the moment you have
> a mix of both.
>
I know, and i don't know what i want.
> Either drop the canonicalization and consider high-32 bits as
> garbage (and then explicitly extend whereever necessary) or pick
> one and stick with it. Of course, the sign-extending of addl etc
> will force you to choose sign-extend not zero-extend as canonical.
>
The problem is the bpf cpu is inherently unsigned. It does all loads
zero extended, only has logical shifts, does all compares unsigned.
Which sounds like i have to zero extend like crazy. (i took the
Powerpc code as example, it does most things unsigned and on 32 Bit,
but has similar "add is sign extending" things, so i thought it can't
be that bad, otherwise it would have the same Bugs).
I was hoping to let the sign run it's course/sign extend and only
cut at the right point, and i figured that was a point to cut, i should
prop. sign extend.
But if that is not feasible, i could also sprinkle everything with zero
extends.
>> + case BPF_S_ALU_RSH_X: /* A >>= X; */
>> + ctx->seen |= SEEN_XREG;
>> + ALPHA_SRL(r_A, r_X, r_A);
>> + ALPHA_ZEXTL(r_A, r_A);
>> + break;
>
> Like here. You must zero-extend first to avoid shifting in
> garbage. Afterward you can reason that the value is already
> zero-extended.
>
Oh, thanks!
Yes, the shift operations are only logical shifts, so it has to be properly
zero extended.
[snip - bpf_flush_icache]
>
> imb() is all that is needed.
>
Thanks! I guess i will stick to the flush_icache_range, which is defined to
an imb()/smp_imb(), so should do the right thing(TM).
[snip - comment about pases]
>
> I should think you could do this in exactly one pass, given that there's
> absolutely no need for ultra-long branches.
The first pass is called with image == NULL, so all calls have a very long
displacement + we have to make other worst case/wrong assumptions because
addrs is not properly filled and the exit points are unknown.
The second pass with image == NULL will settle some jumps, because addrs is
now mostly properly populated _and_ the exit points are set.
This is done to get a real good estimate when allocating mem, so not to much
is allocated (saw a thread on lkml where Eric was talking with Ingo about
module_realloc, so the memusage is of concern, it is pinned kernel memory
for the user space).
The other passes are only to make things really slick with image != NULL,
and stop if there is no change.
If i knew some kind of base address where module_alloc will allocate, i
could feed that in early...
> If you're going to scan the
> body for SEEN_MEM etc, you might as well look for your A and X initialization
> at the same time and clean up that hack in the prologue.
>
I was working on a patch for that, but it was more complicated, esp. it may
cost some RAM and/or CPU time just to remove one/two instructions, so i left
it out for the moment till i revisit it.
>> +++ b/arch/alpha/net/bpf_jit_helper.S
>
> It would be helpful to use '$' prefixes here for local variables.
>
???
Sorry, i don't understand what you mean. What variables? Or do you mean
register? It uses the same register as the compiler. So to not confuse
things i made the names from the compiler usable in asm. You can change one
define and the compiler and the helper will use another reg.
>
> r~
>
Greetings
Jan
--
Anyone can build a fast processor. The trick is to build a fast system.
(Seymour Cray)
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch net-next 1/2] team: add binary option type
From: David Miller @ 2012-04-05 0:31 UTC (permalink / raw)
To: jpirko
Cc: netdev, eric.dumazet, bhutchings, shemminger, raise.sail,
nuno.martins, matt
In-Reply-To: <1333577787-878-1-git-send-email-jpirko@redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Thu, 5 Apr 2012 00:16:26 +0200
> For transfering generic binary data (e.g. BPF code), introduce new
> binary option type.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied.
^ permalink raw reply
* Re: [patch net-next 2/2] team: add loadbalance mode
From: David Miller @ 2012-04-05 0:31 UTC (permalink / raw)
To: jpirko
Cc: netdev, eric.dumazet, bhutchings, shemminger, raise.sail,
nuno.martins, matt
In-Reply-To: <1333577787-878-2-git-send-email-jpirko@redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Thu, 5 Apr 2012 00:16:27 +0200
> This patch introduces new team mode. It's TX port is selected by
> user-set BPF hash function.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH net-next] vxge: Convert macro to inline function
From: David Miller @ 2012-04-05 0:33 UTC (permalink / raw)
To: joe; +Cc: jdmason, netdev, linux-kernel
In-Reply-To: <1333579075.23520.19.camel@joe2Laptop>
From: Joe Perches <joe@perches.com>
Date: Wed, 04 Apr 2012 15:37:55 -0700
> On Tue, 2012-04-03 at 18:18 -0400, David Miller wrote:
>> From: Joe Perches <joe@perches.com>
>> Date: Tue, 03 Apr 2012 15:14:31 -0700
>> > Convert the macro to inline function to check the arguments.
>> > Signed-off-by: Joe Perches <joe@perches.com>
>> > ---
>> >> Longer term I'd much rather see this turned into an inline
>> >> function with proper type checking etc.
>> > Something like this?
>> Yep.
>
> I did sign the patch.
> I was intending that you could apply it.
Ok, I see now, applied. Thanks Joe.
^ permalink raw reply
* Re: [PATCH] mlx4: allocate just enough pages instead of always 4 pages
From: David Miller @ 2012-04-05 0:34 UTC (permalink / raw)
To: cascardo; +Cc: netdev, roland, ogerlitz, yevgenyp, alexg, klebers
In-Reply-To: <1333568440-14494-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Date: Wed, 4 Apr 2012 16:40:40 -0300
> The driver uses a 2-order allocation, which is too much on architectures
> like ppc64, which has a 64KiB page. This particular allocation is used
> for large packet fragments that may have a size of 512, 1024, 4096 or
> fill the whole allocation. So, a minimum size of 16384 is good enough
> and will be the same size that is used in architectures of 4KiB sized
> pages.
>
> This will avoid allocation failures that we see when the system is under
> stress, but still has plenty of memory, like the one below.
>
> This will also allow us to set the interface MTU to higher values like
> 9000, which was not possible on ppc64 without this patch.
...
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
> Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
> Tested-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH net-next V6 7/8] net/dcb: Add an optional max rate attribute
From: Dave Taht @ 2012-04-05 0:39 UTC (permalink / raw)
To: John Fastabend
Cc: Amir Vadai, Or Gerlitz, David S. Miller, netdev, Roland Dreier,
Yevgeny Petrilin, Oren Duer, Amir Vadai
In-Reply-To: <4F7CE61E.7060406@intel.com>
(I try not to pay too much attention to the DCB stuff as it gives me nightmares)
It would comfort me to know if or which of:
Is 802.1au being implemented?
802.3bd?
There was some other standard involving active queue management at
this layer that I can't remember the alphabet soup for that must be
dead in the water at this point..
http://www.ieee802.org/1/files/public/docs2009/au-yasuda-10G-QCN-Implementation-1109.pdf
On Wed, Apr 4, 2012 at 5:23 PM, John Fastabend
<john.r.fastabend@intel.com> wrote:
> On 4/4/2012 3:58 AM, Amir Vadai wrote:
>> Although not specified in 8021Qaz spec, it could be useful to enable drivers
>> whose HW supports setting a rate limit for an ETS TC. This patch adds this
>> optional attribute to DCB netlink. To use it, drivers should implement and
>> register the callbacks ieee_setmaxrate and ieee_getmaxrate. The units are 64
>> bits long and specified in Kbps to enable usage over both slow and very fast
>> networks.
>>
>> Signed-off-by: Amir Vadai <amirv@mellanox.com>
>> ---
>
> Or, Amir,
>
> Two more comments inline really just minor nit picks but if your going
> to roll new patch mind as well. I'll ack a patch with these changes.
>
>> include/linux/dcbnl.h | 5 +++++
>> include/net/dcbnl.h | 2 ++
>> net/dcb/dcbnl.c | 21 +++++++++++++++++++++
>> 3 files changed, 28 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
>> index 65a2562..ec8e372 100644
>> --- a/include/linux/dcbnl.h
>> +++ b/include/linux/dcbnl.h
>> @@ -67,6 +67,10 @@ struct ieee_ets {
>> __u8 reco_prio_tc[IEEE_8021QAZ_MAX_TCS];
>> };
>>
>
> annotate ieee_maxrate so implementers use it correctly per previous note.
>
>> +struct ieee_maxrate {
>> + __u64 tc_maxrate[IEEE_8021QAZ_MAX_TCS];
>> +};
>> +
>> /* This structure contains the IEEE 802.1Qaz PFC managed object
>> *
>> * @pfc_cap: Indicates the number of traffic classes on the local device
>> @@ -321,6 +325,7 @@ enum ieee_attrs {
>> DCB_ATTR_IEEE_PEER_ETS,
>> DCB_ATTR_IEEE_PEER_PFC,
>> DCB_ATTR_IEEE_PEER_APP,
>> + DCB_ATTR_IEEE_MAXRATE,
>> __DCB_ATTR_IEEE_MAX
>> };
>> #define DCB_ATTR_IEEE_MAX (__DCB_ATTR_IEEE_MAX - 1)
>> diff --git a/include/net/dcbnl.h b/include/net/dcbnl.h
>> index f55c980..fc5d5dc 100644
>> --- a/include/net/dcbnl.h
>> +++ b/include/net/dcbnl.h
>> @@ -48,6 +48,8 @@ struct dcbnl_rtnl_ops {
>> /* IEEE 802.1Qaz std */
>> int (*ieee_getets) (struct net_device *, struct ieee_ets *);
>> int (*ieee_setets) (struct net_device *, struct ieee_ets *);
>> + int (*ieee_getmaxrate) (struct net_device *, struct ieee_maxrate *);
>> + int (*ieee_setmaxrate) (struct net_device *, struct ieee_maxrate *);
>> int (*ieee_getpfc) (struct net_device *, struct ieee_pfc *);
>> int (*ieee_setpfc) (struct net_device *, struct ieee_pfc *);
>> int (*ieee_getapp) (struct net_device *, struct dcb_app *);
>> diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
>> index 36f37af..d3df048 100644
>> --- a/net/dcb/dcbnl.c
>> +++ b/net/dcb/dcbnl.c
>> @@ -178,6 +178,8 @@ static const struct nla_policy dcbnl_ieee_policy[DCB_ATTR_IEEE_MAX + 1] = {
>> [DCB_ATTR_IEEE_ETS] = {.len = sizeof(struct ieee_ets)},
>> [DCB_ATTR_IEEE_PFC] = {.len = sizeof(struct ieee_pfc)},
>> [DCB_ATTR_IEEE_APP_TABLE] = {.type = NLA_NESTED},
>> + [DCB_ATTR_IEEE_MAXRATE] = {.len = sizeof(struct ieee_maxrate)},
>> +
>
> spurious newline remove it
>
>> };
>>
>> static const struct nla_policy dcbnl_ieee_app[DCB_ATTR_IEEE_APP_MAX + 1] = {
>> @@ -1246,6 +1248,17 @@ static int dcbnl_ieee_fill(struct sk_buff *skb, struct net_device *netdev)
>> goto nla_put_failure;
>> }
>>
>> + if (ops->ieee_getmaxrate) {
>> + struct ieee_maxrate maxrate;
>> + err = ops->ieee_getmaxrate(netdev, &maxrate);
>> + if (!err) {
>> + err = nla_put(skb, DCB_ATTR_IEEE_MAXRATE,
>> + sizeof(maxrate), &maxrate);
>
> align sizeof with skb
>
> Thanks,
> John
> --
> 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
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
^ permalink raw reply
* Re: bridge: Do not send queries on multicast group leaves
From: Herbert Xu @ 2012-04-05 0:58 UTC (permalink / raw)
To: Dave Taht; +Cc: David S. Miller, netdev
In-Reply-To: <CAA93jw658iHuuYWSz7QrV3ZHOvn1gL7DxAtFfQ0gos6jZjTKiw@mail.gmail.com>
On Wed, Apr 04, 2012 at 08:52:52AM -0700, Dave Taht wrote:
>
> 1) Has anyone seen linux working as a multicast router of late? because I
> sure haven't.
Linux works as a multicast router. The functionality is in
user-space and has nothing to do with this whatsoever.
> 2) Does this bridge code change break existing applications of IGMP over a
> lonely bridge?
No.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v8 0/2] Ethernet drivers for WIZnet chips
From: David Miller @ 2012-04-05 1:15 UTC (permalink / raw)
To: msink; +Cc: netdev, linux-kernel, broonie, msink
In-Reply-To: <1333540660-30551-1-git-send-email-msink@trikom.ru>
From: Mike Sinkovsky <msink@trikom.ru>
Date: Wed, 4 Apr 2012 17:57:38 +0600
> From: Mike Sinkovsky <msink@permonline.ru>
>
> Based on original driver from chip manufacturer, but nearly full rewite.
> Tested and used in production with Blackfin BF531 embedded processor.
>
> Signed-off-by: Mike Sinkovsky <msink@permonline.ru>
I don't see the appropriate changes in your patches to make
sure that drivers/net/ethernet/{Kconfig,Makefile} consider
and traverse down into the wiznet/ subdirectory.
Furthermore, once that is fixed these drivers generate warnings
when built:
drivers/net/ethernet/wiznet/w5300.c:708:8: warning: initialization from incompatible pointer type [enabled by default]
drivers/net/ethernet/wiznet/w5300.c:708:8: warning: (near initialization for ‘w5300_pm_ops.suspend’) [enabled by default]
drivers/net/ethernet/wiznet/w5300.c:708:8: warning: initialization from incompatible pointer type [enabled by default]
drivers/net/ethernet/wiznet/w5300.c:708:8: warning: (near initialization for ‘w5300_pm_ops.resume’) [enabled by default]
drivers/net/ethernet/wiznet/w5300.c:708:8: warning: initialization from incompatible pointer type [enabled by default]
drivers/net/ethernet/wiznet/w5300.c:708:8: warning: (near initialization for ‘w5300_pm_ops.freeze’) [enabled by default]
drivers/net/ethernet/wiznet/w5300.c:708:8: warning: initialization from incompatible pointer type [enabled by default]
drivers/net/ethernet/wiznet/w5300.c:708:8: warning: (near initialization for ‘w5300_pm_ops.thaw’) [enabled by default]
drivers/net/ethernet/wiznet/w5300.c:708:8: warning: initialization from incompatible pointer type [enabled by default]
drivers/net/ethernet/wiznet/w5300.c:708:8: warning: (near initialization for ‘w5300_pm_ops.poweroff’) [enabled by default]
drivers/net/ethernet/wiznet/w5300.c:708:8: warning: initialization from incompatible pointer type [enabled by default]
drivers/net/ethernet/wiznet/w5300.c:708:8: warning: (near initialization for ‘w5300_pm_ops.restore’) [enabled by default]
It seems that the arguments and return types for these operations have
changed since you worked on these patches, but this should be easy
to fix up.
Please cure these two issues and I'll happily put these new drivers
into net-next, and meanwhile you can continue to work with Eric
Dumazet to correct the TX flow control and locking issues.
Thanks.
^ permalink raw reply
* Re: bridge: Do not send queries on multicast group leaves
From: David Miller @ 2012-04-05 1:17 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20120404110119.GA11576@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.hengli.com.au>
Date: Wed, 4 Apr 2012 19:01:20 +0800
> bridge: Do not send queries on multicast group leaves
>
> As it stands the bridge IGMP snooping system will respond to
> group leave messages with queries for remaining membership.
> This is both unnecessary and undesirable. First of all any
> multicast routers present should be doing this rather than us.
> What's more the queries that we send may end up upsetting other
> multicast snooping swithces in the system that are buggy.
>
> In fact, we can simply remove the code that send these queries
> because the existing membership expiry mechanism doesn't rely
> on them anyway.
>
> So this patch simply removes all code associated with group
> queries in response to group leave messages.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied and queued up for -stable, thanks Herbert.
^ permalink raw reply
* Re: [RFC] net:phy:phylib: phy shares the same interrupt with mac
From: Jason Lin @ 2012-04-05 1:30 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <4F7AB9AC.8000708@openwrt.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=GB2312, Size: 5470 bytes --]
But, I need to enable PHY's interrupt by setting PHY's registers.
And after producing a interrupt, there needs a workqueue
to ack the PHY's interrupt.
The phy_start_interrupts() can enable PHY's interrupt.
If I do the following:
1) set phydev->irq = PHY_IGNORE_INTERRUPT;
2) invoke phy_connect();
3) phy_conenct() -> phy_connect_direct() ->
if (phydev->irq > 0)
phy_start_interrupts(phydev);
4) PHY_IGNORE_INTERRUPT = -2, it will not enable PHY's interrupt.
5) phy_start_interrupts() will connect to a callback function
config_intr() of each PHY library.
For example, drivers/net/phy/marvell.c, marvell_config_intr()
Need to set register 0x12 to 0x6400 to enable corresponding interrupts.
Any comments are appreciated.
Thanks.
ÔÚ 2012Äê4ÔÂ3ÈÕÏÂÎç4:49£¬Florian Fainelli <florian@openwrt.org> Œ‘µÀ£º
> Hi,
>
> Le 04/03/12 04:11, Jason Lin a ¨¦crit :
>
>> 1) Add a new definition PHY_MAC if phy shares the same
>> interrupt with mac.
>> 2) Add do_phy_workqueue(), that mac can invoke this function
>> in its ISR when link status changed or other conditions.
>>
>> Does this seems reasonable?
>
>
> No, I think this is well handled by the PHY_IGNORE_INTERRUPT case
> (documented in Documentation/networking/phy.txt) by doing the following:
>
> - distinguish between MAC and PHY interrupts in your MAC interrupt handler
> (most likely you have separate bits for PHY interrupts)
> - once you see a PHY interrupt, call the appropriate PHY state machine
> callbacks to update the PHY state machine
>
>>
>>
>> ---------------------------
>> drivers/net/phy/phy.c | 27 +++++++++++++++++++++++++++
>> drivers/net/phy/phy_device.c | 4 ++--
>> include/linux/phy.h | 3 +++
>> 3 files changed, 32 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
>> index 7670aac..c8009e9 100644
>> --- a/drivers/net/phy/phy.c
>> +++ b/drivers/net/phy/phy.c
>> @@ -527,6 +527,28 @@ static irqreturn_t phy_interrupt(int irq, void
>> *phy_dat)
>> return IRQ_HANDLED;
>> }
>>
>> +/*
>> + * do_phy_workqueue - PHY interrupt handler used by MAC
>> + * @irq: interrupt line
>> + * @phydev: phy_device pointer
>> + *
>> + * Description: When a PHY use the same interrupt with MAC,
>> + * the handler is invoked by MAC, and schedules a work task
>> + * to clear the PHY's interrupt.
>> + * This handler is invoked only in MAC's ISR.
>> + */
>> +irqreturn_t do_phy_workqueue(int irq, struct phy_device *phydev) {
>> +
>> + BUG_ON(!in_interrupt());
>> +
>> + if (PHY_HALTED == phydev->state)
>> + return IRQ_NONE;
>> +
>> + schedule_work(&phydev->phy_queue);
>> + return IRQ_HANDLED;
>> +}
>> +EXPORT_SYMBOL(do_phy_workqueue);
>> +
>> /**
>> * phy_enable_interrupts - Enable the interrupts from the PHY side
>> * @phydev: target phy_device struct
>> @@ -589,6 +611,11 @@ int phy_start_interrupts(struct phy_device *phydev)
>>
>> INIT_WORK(&phydev->phy_queue, phy_change);
>>
>> + if (phydev->irq == PHY_MAC) {
>> + err = phy_enable_interrupts(phydev);
>> + return err;
>> + }
>> +
>> atomic_set(&phydev->irq_disable, 0);
>> if (request_irq(phydev->irq, phy_interrupt,
>> IRQF_SHARED,
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index 993c52c..1857097 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -345,7 +345,7 @@ int phy_connect_direct(struct net_device *dev,
>> struct phy_device *phydev,
>>
>> phy_prepare_link(phydev, handler);
>> phy_start_machine(phydev, NULL);
>> - if (phydev->irq> 0)
>> + if ((phydev->irq> 0) || (phydev->irq == PHY_MAC))
>> phy_start_interrupts(phydev);
>>
>> return 0;
>> @@ -399,7 +399,7 @@ EXPORT_SYMBOL(phy_connect);
>> */
>> void phy_disconnect(struct phy_device *phydev)
>> {
>> - if (phydev->irq> 0)
>> + if ((phydev->irq> 0) || (phydev->irq == PHY_MAC))
>> phy_stop_interrupts(phydev);
>>
>> phy_stop_machine(phydev);
>> diff --git a/include/linux/phy.h b/include/linux/phy.h
>> index 7da5fa8..155822c 100644
>> --- a/include/linux/phy.h
>> +++ b/include/linux/phy.h
>> @@ -44,9 +44,11 @@
>> * Set phydev->irq to PHY_POLL if interrupts are not supported,
>> * or not desired for this PHY. Set to PHY_IGNORE_INTERRUPT if
>> * the attached driver handles the interrupt
>> + * Set to PHY_MAC if using the same interrupt with MAC
>> */
>> #define PHY_POLL -1
>> #define PHY_IGNORE_INTERRUPT -2
>> +#define PHY_MAC -3
>>
>> #define PHY_HAS_INTERRUPT 0x00000001
>> #define PHY_HAS_MAGICANEG 0x00000002
>> @@ -510,6 +512,7 @@ int phy_ethtool_sset(struct phy_device *phydev,
>> struct ethtool_cmd *cmd);
>> int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd);
>> int phy_mii_ioctl(struct phy_device *phydev,
>> struct ifreq *ifr, int cmd);
>> +irqreturn_t do_phy_workqueue(int irq, struct phy_device *phydev);
>> int phy_start_interrupts(struct phy_device *phydev);
>> void phy_print_status(struct phy_device *phydev);
>> void phy_device_free(struct phy_device *phydev);
>> --
>> 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
* Despite of traffic control on host netdevice, is it worth to impose a limit control on qemu emulated net device?
From: Liu ping fan @ 2012-04-05 2:30 UTC (permalink / raw)
To: qemu-devel, netdev
Cc: Eric Dumazet, David S. Miller, Stefan Hajnoczi, Anthony Liguori,
linux-kernel
Hi,
As we know, in order to control the guest OS's TX rate limit, we can
apply rate limit on ingress Qdisc of host's tap device.
But I think skb will be dropped on host's tap ingress Qdisc, which
means that for those protocol lacking of congestion control such as
UDP, it will cost a lot of meaningless time to produce dropped packet
.
What about introducing rate limit on qemu's emulated net device? I
think guest's UDP transaction will be blocked at wait_for_wmem.
Thanks and regards,
pingfan
^ permalink raw reply
* Re: 3.3.0, 3.4-rc1 reproducible tun Oops
From: Eric Dumazet @ 2012-04-05 2:41 UTC (permalink / raw)
To: Simon Kirby; +Cc: netdev
In-Reply-To: <20120404220525.GD21505@hostway.ca>
On Wed, 2012-04-04 at 15:05 -0700, Simon Kirby wrote:
> I use an SSH VPN occasionally from home, and since upgrading the
> remote
> kernel to 3.3.0, the it now seems to Oops when I ^C the tunnel with
> sockets still active. If I start the tunnel, log in to a box through
> it
> and run "vmstat 1", ^C the tunnel SSH process, and start it up again,
> I
> get an Oops like this:
>
> BUG: unable to handle kernel NULL pointer dereference at
> 00000000000000ff
> IP: [<ffffffff810ed5fa>] __kmalloc_track_caller+0xaa/0x1b0
> PGD 12d2bc067 PUD 0
> Oops: 0000 [#1] SMP
> CPU 1
> Modules linked in: nf_conntrack_netlink nfnetlink iptable_mangle
> ipt_MASQUERADE xt_state xt_conntrack iptable_nat nf_nat
> nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack hwmon_vid ppp_async
> ppp_generic slhc crc_ccitt tun nvidia(PO) uvcvideo videobuf2_vmalloc
> videobuf2_memops videobuf2_core e100
>
> Pid: 16156, comm: sshd Tainted: P O 3.3.0 #32 System
> manufacturer System Product Name/A8N-VM CSM
Hmm, is it happening if you remove the nvidia module ?
If yes, please try to add slub_debug=FZPU
CONFIG_SLUB_DEBUG=y
CONFIG_SLUB=y
# CONFIG_SLUB_DEBUG_ON is not set
^ permalink raw reply
* [PATCH v2] ipv6: fix array index in ip6_mc_add_src()
From: roy.qing.li @ 2012-04-05 2:47 UTC (permalink / raw)
To: netdev
From: RongQing.Li <roy.qing.li@gmail.com>
Convert array index from the loop bound to the loop index.
And remove the void type conversion to ip6_mc_del1_src() return
code, seem it is unnecessary, since ip6_mc_del1_src() does not
use __must_check similar attribute, no compiler will report the
warning when it is removed.
v2: enrich the commit header
Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>
---
net/ipv6/mcast.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 16c33e3..c6378de 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -2044,7 +2044,7 @@ static int ip6_mc_add_src(struct inet6_dev *idev, const struct in6_addr *pmca,
if (!delta)
pmc->mca_sfcount[sfmode]--;
for (j=0; j<i; j++)
- (void) ip6_mc_del1_src(pmc, sfmode, &psfsrc[i]);
+ ip6_mc_del1_src(pmc, sfmode, &psfsrc[j]);
} else if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) {
struct ip6_sf_list *psf;
--
1.7.1
^ permalink raw reply related
* linux-next: build failure after merge of the final tree (net-next tree related)
From: Stephen Rothwell @ 2012-04-05 3:25 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Deepak SIKRI, Shiraz Hashim,
Vikas Manocha, Giuseppe Cavallaro
[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c: In function 'stmmac_probe_config_dt':
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:53:7: error: 'struct plat_stmmacenet_data' has no member named 'pbl'
Caused by commit 8327eb65e795 ("stmmac: re-work the internal GMAC DMA
platf parameters"). Clearly I am missing something, because I can't see
how that patch is correct since nothing ever assigns to the new dma_cfg
pointer but it is dereferenced.
I have added this patch to make it build today, but it is obviously not
correct.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 5 Apr 2012 13:19:21 +1000
Subject: [PATCH] stmmac: hack to make it build
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 116529a..1e4d12d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -50,7 +50,7 @@ static int __devinit stmmac_probe_config_dt(struct platform_device *pdev,
* once needed on other platforms.
*/
if (of_device_is_compatible(np, "st,spear600-gmac")) {
- plat->pbl = 8;
+/* plat->pbl = 8; */
plat->has_gmac = 1;
plat->pmt = 1;
}
--
1.7.10.rc3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [PATCH v2] ipv6: fix array index in ip6_mc_add_src()
From: David Miller @ 2012-04-05 4:01 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1333594024-24347-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Thu, 5 Apr 2012 10:47:04 +0800
> From: RongQing.Li <roy.qing.li@gmail.com>
>
> Convert array index from the loop bound to the loop index.
>
> And remove the void type conversion to ip6_mc_del1_src() return
> code, seem it is unnecessary, since ip6_mc_del1_src() does not
> use __must_check similar attribute, no compiler will report the
> warning when it is removed.
>
> v2: enrich the commit header
>
> Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: David Miller @ 2012-04-05 3:59 UTC (permalink / raw)
To: sfr
Cc: netdev, linux-next, linux-kernel, deepak.sikri, shiraz.hashim,
vikas.manocha, peppe.cavallaro
In-Reply-To: <20120405132515.e61465875407a452c1a6f78e@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 5 Apr 2012 13:25:15 +1000
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c: In function 'stmmac_probe_config_dt':
> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:53:7: error: 'struct plat_stmmacenet_data' has no member named 'pbl'
>
> Caused by commit 8327eb65e795 ("stmmac: re-work the internal GMAC DMA
> platf parameters"). Clearly I am missing something, because I can't see
> how that patch is correct since nothing ever assigns to the new dma_cfg
> pointer but it is dereferenced.
>
> I have added this patch to make it build today, but it is obviously not
> correct.
Sorry Stephen.
Giuseppe don't submit patches to me that don't even compile.
Please submit a proper fix to me for this _now_.
^ permalink raw reply
* [PATCH net-next] net: sh_eth: add support R8A7740
From: Shimoda, Yoshihiro @ 2012-04-05 4:37 UTC (permalink / raw)
To: netdev; +Cc: SH-Linux
The R8A7740 has a Gigabit Ethernet MAC. This patch supports it.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/net/ethernet/renesas/Kconfig | 7 +-
drivers/net/ethernet/renesas/sh_eth.c | 114 ++++++++++++++++++++++++++++++++-
drivers/net/ethernet/renesas/sh_eth.h | 5 +-
3 files changed, 120 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/renesas/Kconfig b/drivers/net/ethernet/renesas/Kconfig
index 3fb2355..46df3a0 100644
--- a/drivers/net/ethernet/renesas/Kconfig
+++ b/drivers/net/ethernet/renesas/Kconfig
@@ -4,11 +4,11 @@
config SH_ETH
tristate "Renesas SuperH Ethernet support"
- depends on SUPERH && \
+ depends on (SUPERH || ARCH_SHMOBILE) && \
(CPU_SUBTYPE_SH7710 || CPU_SUBTYPE_SH7712 || \
CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7619 || \
CPU_SUBTYPE_SH7724 || CPU_SUBTYPE_SH7734 || \
- CPU_SUBTYPE_SH7757)
+ CPU_SUBTYPE_SH7757 || ARCH_R8A7740)
select CRC32
select NET_CORE
select MII
@@ -17,4 +17,5 @@ config SH_ETH
---help---
Renesas SuperH Ethernet device driver.
This driver supporting CPUs are:
- - SH7619, SH7710, SH7712, SH7724, SH7734, SH7763 and SH7757.
+ - SH7619, SH7710, SH7712, SH7724, SH7734, SH7763, SH7757,
+ and R8A7740.
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index d63e09b..be3c221 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -386,6 +386,114 @@ static void sh_eth_reset_hw_crc(struct net_device *ndev)
sh_eth_write(ndev, 0x0, CSMR);
}
+#elif defined(CONFIG_ARCH_R8A7740)
+#define SH_ETH_HAS_TSU 1
+static void sh_eth_chip_reset(struct net_device *ndev)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ unsigned long mii;
+
+ /* reset device */
+ sh_eth_tsu_write(mdp, ARSTR_ARSTR, ARSTR);
+ mdelay(1);
+
+ switch (mdp->phy_interface) {
+ case PHY_INTERFACE_MODE_GMII:
+ mii = 2;
+ break;
+ case PHY_INTERFACE_MODE_MII:
+ mii = 1;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ default:
+ mii = 0;
+ break;
+ }
+ sh_eth_write(ndev, mii, RMII_MII);
+}
+
+static void sh_eth_reset(struct net_device *ndev)
+{
+ int cnt = 100;
+
+ sh_eth_write(ndev, EDSR_ENALL, EDSR);
+ sh_eth_write(ndev, sh_eth_read(ndev, EDMR) | EDMR_SRST_GETHER, EDMR);
+ while (cnt > 0) {
+ if (!(sh_eth_read(ndev, EDMR) & 0x3))
+ break;
+ mdelay(1);
+ cnt--;
+ }
+ if (cnt == 0)
+ printk(KERN_ERR "Device reset fail\n");
+
+ /* Table Init */
+ sh_eth_write(ndev, 0x0, TDLAR);
+ sh_eth_write(ndev, 0x0, TDFAR);
+ sh_eth_write(ndev, 0x0, TDFXR);
+ sh_eth_write(ndev, 0x0, TDFFR);
+ sh_eth_write(ndev, 0x0, RDLAR);
+ sh_eth_write(ndev, 0x0, RDFAR);
+ sh_eth_write(ndev, 0x0, RDFXR);
+ sh_eth_write(ndev, 0x0, RDFFR);
+}
+
+static void sh_eth_set_duplex(struct net_device *ndev)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+
+ if (mdp->duplex) /* Full */
+ sh_eth_write(ndev, sh_eth_read(ndev, ECMR) | ECMR_DM, ECMR);
+ else /* Half */
+ sh_eth_write(ndev, sh_eth_read(ndev, ECMR) & ~ECMR_DM, ECMR);
+}
+
+static void sh_eth_set_rate(struct net_device *ndev)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+
+ switch (mdp->speed) {
+ case 10: /* 10BASE */
+ sh_eth_write(ndev, GECMR_10, GECMR);
+ break;
+ case 100:/* 100BASE */
+ sh_eth_write(ndev, GECMR_100, GECMR);
+ break;
+ case 1000: /* 1000BASE */
+ sh_eth_write(ndev, GECMR_1000, GECMR);
+ break;
+ default:
+ break;
+ }
+}
+
+/* R8A7740 */
+static struct sh_eth_cpu_data sh_eth_my_cpu_data = {
+ .chip_reset = sh_eth_chip_reset,
+ .set_duplex = sh_eth_set_duplex,
+ .set_rate = sh_eth_set_rate,
+
+ .ecsr_value = ECSR_ICD | ECSR_MPD,
+ .ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
+ .eesipr_value = DMAC_M_RFRMER | DMAC_M_ECI | 0x003fffff,
+
+ .tx_check = EESR_TC1 | EESR_FTC,
+ .eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT | \
+ EESR_RDE | EESR_RFRMER | EESR_TFE | EESR_TDE | \
+ EESR_ECI,
+ .tx_error_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_TDE | \
+ EESR_TFE,
+
+ .apr = 1,
+ .mpr = 1,
+ .tpauser = 1,
+ .bculr = 1,
+ .hw_swap = 1,
+ .no_trimd = 1,
+ .no_ade = 1,
+ .tsu = 1,
+};
+
#elif defined(CONFIG_CPU_SUBTYPE_SH7619)
#define SH_ETH_RESET_DEFAULT 1
static struct sh_eth_cpu_data sh_eth_my_cpu_data = {
@@ -443,7 +551,7 @@ static void sh_eth_reset(struct net_device *ndev)
}
#endif
-#if defined(CONFIG_CPU_SH4)
+#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
static void sh_eth_set_receive_align(struct sk_buff *skb)
{
int reserve;
@@ -919,6 +1027,10 @@ static int sh_eth_rx(struct net_device *ndev)
desc_status = edmac_to_cpu(mdp, rxdesc->status);
pkt_len = rxdesc->frame_length;
+#if defined(CONFIG_ARCH_R8A7740)
+ desc_status >>= 16;
+#endif
+
if (--boguscnt < 0)
break;
diff --git a/drivers/net/ethernet/renesas/sh_eth.h b/drivers/net/ethernet/renesas/sh_eth.h
index 0fa14af..57b8e1f 100644
--- a/drivers/net/ethernet/renesas/sh_eth.h
+++ b/drivers/net/ethernet/renesas/sh_eth.h
@@ -372,7 +372,7 @@ static const u16 sh_eth_offset_fast_sh3_sh2[SH_ETH_MAX_REGISTER_OFFSET] = {
};
/* Driver's parameters */
-#if defined(CONFIG_CPU_SH4)
+#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
#define SH4_SKB_RX_ALIGN 32
#else
#define SH2_SH3_SKB_RX_ALIGN 2
@@ -381,7 +381,8 @@ static const u16 sh_eth_offset_fast_sh3_sh2[SH_ETH_MAX_REGISTER_OFFSET] = {
/*
* Register's bits
*/
-#if defined(CONFIG_CPU_SUBTYPE_SH7734) || defined(CONFIG_CPU_SUBTYPE_SH7763)
+#if defined(CONFIG_CPU_SUBTYPE_SH7734) || defined(CONFIG_CPU_SUBTYPE_SH7763) ||\
+ defined(CONFIG_ARCH_R8A7740)
/* EDSR */
enum EDSR_BIT {
EDSR_ENT = 0x01, EDSR_ENR = 0x02,
--
1.7.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