* [PATCH] ip: correctly report 802.15.4 link type
From: Jan Engelhardt @ 2010-07-25 20:28 UTC (permalink / raw)
To: stephen.hemminger; +Cc: netdev
In-Reply-To: <1280089683-12020-1-git-send-email-jengelh@medozas.de>
Up until now, the "hardwpan" devices were displayed as link/[804].
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
lib/ll_types.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/ll_types.c b/lib/ll_types.c
index 846cdb0..1cc46b6 100644
--- a/lib/ll_types.c
+++ b/lib/ll_types.c
@@ -125,6 +125,9 @@ __PF(IEEE80211_PRISM,ieee802.11/prism)
#ifdef ARPHRD_IEEE80211_RADIOTAP
__PF(IEEE80211_RADIOTAP,ieee802.11/radiotap)
#endif
+#ifdef ARPHRD_IEEE802154
+__PF(IEEE802154, ieee802.15.4)
+#endif
#ifdef ARPHRD_NONE
__PF(NONE, none)
#endif
--
1.7.1
^ permalink raw reply related
* iproute2: 802.15.4 reporting
From: Jan Engelhardt @ 2010-07-25 20:28 UTC (permalink / raw)
To: stephen.hemminger; +Cc: netdev
Hi,
I am resending this patch as it has not been included yet.
Last time you mentioned something about wanting to do this different,
but this is already your standard array of int-string mappings, not
much to improve there I'd say.
Jan
^ permalink raw reply
* Re: [PATCH] 3c59x: Add ethtool WOL support
From: Andrew O. Shadoura @ 2010-07-25 19:03 UTC (permalink / raw)
To: Netdev mailing list; +Cc: Linux kernel mailing list
In-Reply-To: <201007250524.18911.andrew@beldisplaytech.com>
[-- Attachment #1: Type: Text/Plain, Size: 293 bytes --]
Hello.
On Sunday 25 July 2010 05:24:17 Andrew O. Shadoura wrote:
> I've actually tested this patch on a machine with a network
> card that's idenfied by lsusb as "3c905C-TX/TX-M", and it seems
> to work.
Oops, of course I meant "it's identified by lspci as ...".
--
WBR, Andrew
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] netfilter: xtables: inclusion of xt_SYSRQ
From: John Haxby @ 2010-07-25 18:13 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Patrick McHardy, Netfilter Developer Mailing List,
Linux Netdev List
In-Reply-To: <alpine.LSU.2.01.1007251848520.14790@obet.zrqbmnf.qr>
On 25 Jul 2010, at 17:49, Jan Engelhardt wrote:
>
> On Wednesday 2010-04-28 17:03, Jan Engelhardt wrote:
>> On Wednesday 2010-04-28 16:54, John Haxby wrote:
>>>
>>> use-case I see -- the one I see is where the sys admins used to have a "crash
>>> trolley" which was a console and PS/2 keyboard which they could plug into a
>>> machine to get some information, but as many rack machines no longer have
>>> anything PS/2 and USB hot plug is unlikely to work on a sick machine
>>
>
> I still think we should merge this. A hold-up like this would have never
> happened with staging drivers!
>
Me too. I've been caught up with other things, but Patrick's suggestion of a separate module only half worked out.
Using encapsulation sockets, to get the sysrq handled in BH context works well except that there are no encapsulation sockets for IPv6. That, for me at least was a bit of a show stopper.
In exploring this, though, I did correct one weakness in the protocol. An opportunistic hacker could take a sysrq packet and replay it to other hosts in the LAN in the hope that they have the same password (this is a realistic weakness rather than a theoretical one). To counter this I simply added the target IP address to the hash.
Would you like me to submit that to xt_SYSRQ anyway? (In a couple of weeks I'm afraid, I'm out for a while.)
jch
^ permalink raw reply
* Re: [PATCH 1/2] netfilter: xtables: inclusion of xt_SYSRQ
From: Jan Engelhardt @ 2010-07-25 16:49 UTC (permalink / raw)
To: John Haxby
Cc: Patrick McHardy, Netfilter Developer Mailing List,
Linux Netdev List
In-Reply-To: <alpine.LSU.2.01.1004281701220.9518@obet.zrqbmnf.qr>
On Wednesday 2010-04-28 17:03, Jan Engelhardt wrote:
>On Wednesday 2010-04-28 16:54, John Haxby wrote:
>>
>> use-case I see -- the one I see is where the sys admins used to have a "crash
>> trolley" which was a console and PS/2 keyboard which they could plug into a
>> machine to get some information, but as many rack machines no longer have
>> anything PS/2 and USB hot plug is unlikely to work on a sick machine
>
I still think we should merge this. A hold-up like this would have never
happened with staging drivers!
^ permalink raw reply
* Re: [patch -next v2] mv643xx_eth: potential null dereference
From: Lennert Buytenhek @ 2010-07-25 15:54 UTC (permalink / raw)
To: walter harms
Cc: Dan Carpenter, Joe Perches, David S. Miller, Jiri Pirko,
Denis Kirjanov, Saeed Bishara, netdev, kernel-janitors
In-Reply-To: <4C4C4E75.4080603@bfs.de>
On Sun, Jul 25, 2010 at 04:47:17PM +0200, walter harms wrote:
> >> IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit
> >> have usefull values than adding a check but this is up to the maintainer.
> >
> > I don't see the point of that at all. We check against zero to see
> > whether the caller bothered to fill in the field at all, but if the
> > caller wants to pass in bogus values, that's up to the caller.
>
> at first i have to admit i looked only at the patch.
> for me the situation looks this way:
>
> You check the values for 0 (and uses default) or take what ever in pd is.
> The current code is setup like:
>
> 1. check if pd is set
> 2. check if pd->value is non zero and use it
>
> the whole "check X" can be avoided if you could create a pd with all values
> set to default and just take what comes from the user.
Why would you want to avoid "check X"?
> my objection agains this kind of code is that it is not obvious
> what some one is trying to archive
> (pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
>
> the pd check means: do i have a configuration ?
Yep.
> the pd->t_clk != 0 means: should i use then or default ?
Yep.
> This is mixing two very different questions.
And?
You're arguing against the use of 'if (a && b)' in general?
> therefore my idea in the last posting to have a default init if (!pd)
> and then use the else to make clear that additional checks for
> pd->value are expected.
Again, I don't see the point of this, and I think we're just splitting
hairs here and wasting everyone's time.
> this this is the init code readability and simplicity should be king.
'if (foo != NULL && foo->value <op> <value>)' is a fairly common C
construct, in my opinion, and I don't see how expanding it into a
multi-line nested if construct will make it either more readable or
simpler.
> hope that helps,
Not really.
thanks,
Lennert
^ permalink raw reply
* RE: Splice status
From: Ofer Heifetz @ 2010-07-25 14:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Changli Gao, Jens Axboe, netdev@vger.kernel.org
In-Reply-To: <1279030308.2634.349.camel@edumazet-laptop>
Hi Eric,
Still trying to get better performance with splice, I noticed that when using splice there are twice the file size memcpy (placed a counter in memcpy), I verified it via samba file transfer and splice-fromnet/out.
I also used the splice-fromnet/out and using ftrace I did notice that data is copied twice using these routines: skb_splice_bits, pipe_to_file.
I thought that the main goal of splice is to refrain from one copy when moving data from network to file descriptor.
If there are the same number of memcpy and context switches and in samba copy additional vfs overhead it makes sense that splice deteriates the samba overall write performance.
-Ofer
-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
Sent: Tuesday, July 13, 2010 5:12 PM
To: Ofer Heifetz
Cc: Changli Gao; Jens Axboe; netdev@vger.kernel.org
Subject: RE: Splice status
Le mardi 13 juillet 2010 à 14:41 +0300, Ofer Heifetz a écrit :
> Hi,
>
> I wanted to let you know that I have been testing Samba splice on Marvell 6282 SoC on 2.6.35_rc3 and noticed that it gave worst performance than not using it and also noticed that on re-writing file the iowait is high.
>
> iometer using 2G file (file is created before test)
>
> Splice write cpu% iow%
> -----------------------
> No 58 98 0
> Yes 14 100 48
>
> iozone using 2G file (file created during test)
>
> Splice write cpu% iow% re-write cpu% iow%
> -------------------------------------------
> No 35 85 4 58.2 70 0
> Yes 33 85 4 15.7 100 58
>
> Any clue why splice introduces a high iowait?
> I noticed samba uses up to 16K per splice syscall, changing the samba to try more did not help, so I guess it is a kernel limitation.
>
splice(socket -> pipe) provides partial buffers (depending on the MTU)
With typical MTU=1500 and tcp timestamps, each network frame contains
1448 bytes of payload, partially filling one page (of 4096 bytes)
When doing the splice(pipe -> file), kernel has to coalesce partial
data, but amount of written data per syscall() is small (about 20
Kbytes)
Without splice(), the write() syscall provides more data, and vfs
overhead is smaller as buffer size is a power of two.
Samba uses a 128 KBytes TRANSFER_BUF_SIZE in its default_sys_recvfile()
implementation, it easily outperforms splice() implementation.
You could try extending pipe size (fcntl(fd, F_SETPIPE_SZ, 256)), maybe
it will be a bit better. (and ask 256*4096 bytes to splice())
I tried this and got about 256Kbytes per splice() call...
# perf report
# Events: 13K
#
# Overhead Command Shared Object Symbol
# ........ .............. ................. ......
#
8.69% splice-fromnet [kernel.kallsyms] [k] memcpy
3.82% splice-fromnet [kernel.kallsyms] [k] kunmap_atomic
3.51% splice-fromnet [kernel.kallsyms] [k] __block_prepare_write
2.79% splice-fromnet [kernel.kallsyms] [k] __skb_splice_bits
2.58% splice-fromnet [kernel.kallsyms] [k] ext3_mark_iloc_dirty
2.45% splice-fromnet [kernel.kallsyms] [k] do_get_write_access
2.04% splice-fromnet [kernel.kallsyms] [k] __find_get_block
1.89% splice-fromnet [kernel.kallsyms] [k] _raw_spin_lock
1.83% splice-fromnet [kernel.kallsyms] [k] journal_add_journal_head
1.46% splice-fromnet [bnx2x] [k] bnx2x_rx_int
1.46% splice-fromnet [kernel.kallsyms] [k] kfree
1.42% splice-fromnet [kernel.kallsyms] [k] journal_put_journal_head
1.29% splice-fromnet [kernel.kallsyms] [k] __ext3_get_inode_loc
1.26% splice-fromnet [kernel.kallsyms] [k] journal_dirty_metadata
1.25% splice-fromnet [kernel.kallsyms] [k] page_address
1.20% splice-fromnet [kernel.kallsyms] [k] journal_cancel_revoke
1.15% splice-fromnet [kernel.kallsyms] [k] tcp_read_sock
1.09% splice-fromnet [kernel.kallsyms] [k] unlock_buffer
1.09% splice-fromnet [kernel.kallsyms] [k] pipe_to_file
1.05% splice-fromnet [kernel.kallsyms] [k] radix_tree_lookup_element
1.04% splice-fromnet [kernel.kallsyms] [k] kmap_atomic_prot
1.04% splice-fromnet [kernel.kallsyms] [k] kmem_cache_free
1.03% splice-fromnet [kernel.kallsyms] [k] kmem_cache_alloc
1.01% splice-fromnet [bnx2x] [k] bnx2x_poll
^ permalink raw reply
* Re: [patch -next v2] mv643xx_eth: potential null dereference
From: walter harms @ 2010-07-25 14:47 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: Dan Carpenter, Joe Perches, David S. Miller, Jiri Pirko,
Denis Kirjanov, Saeed Bishara, netdev, kernel-janitors
In-Reply-To: <20100724190036.GA21121@mail.wantstofly.org>
Lennert Buytenhek schrieb:
> On Sat, Jul 24, 2010 at 10:59:07AM +0200, walter harms wrote:
>
>> IMHO it would be better to make sure that pd->t_clk,pd->tx_csum_limit
>> have usefull values than adding a check but this is up to the maintainer.
>
> I don't see the point of that at all. We check against zero to see
> whether the caller bothered to fill in the field at all, but if the
> caller wants to pass in bogus values, that's up to the caller.
>
at first i have to admit i looked only at the patch.
for me the situation looks this way:
You check the values for 0 (and uses default) or take what ever in pd is.
The current code is setup like:
1. check if pd is set
2. check if pd->value is non zero and use it
the whole "check X" can be avoided if you could create a pd with all values
set to default and just take what comes from the user.
my objection agains this kind of code is that it is not obvious
what some one is trying to archive
(pd != NULL && pd->t_clk != 0) ? pd->t_clk : 133000000;
the pd check means: do i have a configuration ?
the pd->t_clk != 0 means: should i use then or default ?
This is mixing two very different questions. therefore my idea in the last
posting to have a default init if (!pd) and then use the else to make clear
that additional checks for pd->value are expected.
this this is the init code readability and simplicity should be king.
hope that helps,
re,
wh
^ permalink raw reply
* [PATCH] nf_conntrack_extend: introduce __nf_ct_ext_exist()
From: Changli Gao @ 2010-07-25 14:38 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, netfilter-devel, netdev, Changli Gao
some users of nf_ct_ext_exist() know ct->ext isn't NULL. For these users, the
check for ct->ext isn't necessary, the function __nf_ct_ext_exist() can be
used instead.
the type of the return value of nf_ct_ext_exist() is changed to bool.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
include/net/netfilter/nf_conntrack_extend.h | 9 +++++++--
net/netfilter/nf_conntrack_extend.c | 22 ++++++++++++----------
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack_extend.h b/include/net/netfilter/nf_conntrack_extend.h
index 32d15bd..0772d29 100644
--- a/include/net/netfilter/nf_conntrack_extend.h
+++ b/include/net/netfilter/nf_conntrack_extend.h
@@ -28,9 +28,14 @@ struct nf_ct_ext {
char data[0];
};
-static inline int nf_ct_ext_exist(const struct nf_conn *ct, u8 id)
+static inline bool __nf_ct_ext_exist(const struct nf_ct_ext *ext, u8 id)
{
- return (ct->ext && ct->ext->offset[id]);
+ return !!ext->offset[id];
+}
+
+static inline bool nf_ct_ext_exist(const struct nf_conn *ct, u8 id)
+{
+ return (ct->ext && __nf_ct_ext_exist(ct->ext, id));
}
static inline void *__nf_ct_ext_find(const struct nf_conn *ct, u8 id)
diff --git a/net/netfilter/nf_conntrack_extend.c b/net/netfilter/nf_conntrack_extend.c
index fdc8fb4..7dcf7a4 100644
--- a/net/netfilter/nf_conntrack_extend.c
+++ b/net/netfilter/nf_conntrack_extend.c
@@ -23,9 +23,10 @@ void __nf_ct_ext_destroy(struct nf_conn *ct)
{
unsigned int i;
struct nf_ct_ext_type *t;
+ struct nf_ct_ext *ext = ct->ext;
for (i = 0; i < NF_CT_EXT_NUM; i++) {
- if (!nf_ct_ext_exist(ct, i))
+ if (!__nf_ct_ext_exist(ext, i))
continue;
rcu_read_lock();
@@ -73,44 +74,45 @@ static void __nf_ct_ext_free_rcu(struct rcu_head *head)
void *__nf_ct_ext_add(struct nf_conn *ct, enum nf_ct_ext_id id, gfp_t gfp)
{
- struct nf_ct_ext *new;
+ struct nf_ct_ext *old, *new;
int i, newlen, newoff;
struct nf_ct_ext_type *t;
/* Conntrack must not be confirmed to avoid races on reallocation. */
NF_CT_ASSERT(!nf_ct_is_confirmed(ct));
- if (!ct->ext)
+ old = ct->ext;
+ if (!old)
return nf_ct_ext_create(&ct->ext, id, gfp);
- if (nf_ct_ext_exist(ct, id))
+ if (__nf_ct_ext_exist(old, id))
return NULL;
rcu_read_lock();
t = rcu_dereference(nf_ct_ext_types[id]);
BUG_ON(t == NULL);
- newoff = ALIGN(ct->ext->len, t->align);
+ newoff = ALIGN(old->len, t->align);
newlen = newoff + t->len;
rcu_read_unlock();
- new = __krealloc(ct->ext, newlen, gfp);
+ new = __krealloc(old, newlen, gfp);
if (!new)
return NULL;
- if (new != ct->ext) {
+ if (new != old) {
for (i = 0; i < NF_CT_EXT_NUM; i++) {
- if (!nf_ct_ext_exist(ct, i))
+ if (!__nf_ct_ext_exist(old, i))
continue;
rcu_read_lock();
t = rcu_dereference(nf_ct_ext_types[i]);
if (t && t->move)
t->move((void *)new + new->offset[i],
- (void *)ct->ext + ct->ext->offset[i]);
+ (void *)old + old->offset[i]);
rcu_read_unlock();
}
- call_rcu(&ct->ext->rcu, __nf_ct_ext_free_rcu);
+ call_rcu(&old->rcu, __nf_ct_ext_free_rcu);
ct->ext = new;
}
^ permalink raw reply related
* Re: Question about way that NICs deliver packets to the kernel
From: Junchang Wang @ 2010-07-25 14:18 UTC (permalink / raw)
To: Rick Jones, netdev; +Cc: Ben Hutchings, romieu
In-Reply-To: <4C45D9FA.5090108@hp.com>
Hi list,
> Clearly something is out of joint - let's go off-list (or on to
> netperf-talk@netperf.org) and hash that out to see what may be happening.
> It will probably involve variations on grabbing the top-of-trunk, adding
> the debug option etc.
>
The discrepancy between netperf and top has been worked out.
It seems top produce buggy data when I try to send output to a file.
For example, "top -b > output" gives out my previous buggy data in its
first iteration.
Actually, the report of top should be:
top - 21:37:15 up 21 min, 6 users, load average: 0.43, 0.28, 0.19
Tasks: 152 total, 2 running, 149 sleeping, 0 stopped, 1 zombie
Cpu(s): 0.2%us, 5.4%sy, 0.0%ni, 50.9%id, 0.0%wa, 0.0%hi, 43.5%si, 0.0%
Mem: 2074064k total, 690192k used, 1383872k free, 39372k buffers
Swap: 2096476k total, 0k used, 2096476k free, 435056k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3916 root 20 0 2228 584 296 R 86.3 0.0 0:09.72 netserver
I think 50.9% system idle makes sense because this is a dual-core system
and netserver is consuming 86.3% of a core. On average, the CPU usage
of the whole system reported by top can be regarded as from 46.2% to
50.1%.
netperf's report of 48% is right and testifies that "there is no huge
discrepancy
between the overall CPU utilization reported by top and the CPU utilization
reported by netperf."
Thanks Rick.
--
--Junchang
^ permalink raw reply
* Re: [PATCH 0/2] ks8842: Support for passing flags via platform data and 100 Mbps support
From: Richard Röjfors @ 2010-07-25 12:13 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <1280003108.28285.279.camel@debian>
On 07/24/2010 10:25 PM, Richard Röjfors wrote:
> To follow are two patches
> * Introduce a flags field in the platform data.
> * removes flow control and advertise 100Mbps
Forget these two patches, I missed the patch from David Choi.
My patches won't apply after his.
--Richard
^ permalink raw reply
* Re: [PATCH] CAN: Add Flexcan CAN controller driver
From: Marc Kleine-Budde @ 2010-07-25 12:01 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: wg, socketcan-core, netdev, davem
In-Reply-To: <4C4C1EDE.7020400@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]
Oliver Hartkopp wrote:
> first of all thanks for your contribution of the flexcan driver!
You're welcome!
> But i have a question regarding the Kconfig change that has been finally
> committed to net-next-2.6.
> It looks like the pulled code has some extra HAVE_CAN_FLEXCAN config option -
> which may be something of your debugging environment - which was not part of
> the original posted patch, where CAN_FLEXCAN depended on (ARCH_MX25 || ARCH_MX35).
Indeed this was not in the patch that Wolfgang Acked.
However, after Wolfgang's Ack I discussed the arm patches with the imx
people. I switched to dynamically registered devies, which is a more
modern way of registering them. And this led to the
"IMX_HAVE_PLATFORM_FLEXCAN" symbol (see below) and then we thought a
platform independent "HAVE_CAN_FLEXCAN" is even better.
So this was intentional (and in the latest patch I posed with the final
pull request.)
> Please see the two posted sections below ...
> The depency of (ARCH_MX25 || ARCH_MX35) makes more sense to me ;-)
The idea behind the "HAVE_CAN_FLEXCAN" is that all architectures select
this symbol if they have a flexcan core (which is supported by this
driver). On the imx platform we make this even in finer granularity.
BTW: If we on ARM finally have OF tree support we can change this easily
without needing to go over the net-next-2.6 tree.
Have a look at the corresponding ARM commits:
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=commit;h=d7aec06a0decceabde9d9be6957229485568964b
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=commit;h=b5a326c8c0a01692e710fc6086ddf84128b7a7d3
Here in detail+
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=blob;f=arch/arm/plat-mxc/devices/Kconfig;h=9ab784b776f9192a33feaff37ff21be99b0a3691;hb=d7aec06a0decceabde9d9be6957229485568964b
We define a symbol without a prompt "IMX_HAVE_PLATFORM_FLEXCAN" for the
imx arm platform. This symbol selects "HAVE_CAN_FLEXCAN".
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=blob;f=arch/arm/plat-mxc/devices/platform-flexcan.c;h=5e97a01f14f3eb106750f00d8a0fffb66f2c9563;hb=d7aec06a0decceabde9d9be6957229485568964b
A selected "IMX_HAVE_PLATFORM_FLEXCAN" symbol activates some glue code
that's used to create the individual flexcan devices.
It's up to the individual board code to select the
"IMX_HAVE_PLATFORM_FLEXCAN" symbol. This patch adds the flexcan support
on the pcm043:
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=blobdiff;f=arch/arm/mach-mx3/Kconfig;h=03563eb997c0f761ea7d7e14d155facfce880e03;hp=e063657e1bf4c3f3d56a67e70bc3f17b333cfb55;hb=b5a326c8c0a01692e710fc6086ddf84128b7a7d3;hpb=d7aec06a0decceabde9d9be6957229485568964b
I hope that answers you question,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* Re: [PATCH] CAN: Add Flexcan CAN controller driver
From: Oliver Hartkopp @ 2010-07-25 11:24 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: wg, socketcan-core, netdev, davem
In-Reply-To: <1279816844-12138-1-git-send-email-mkl@pengutronix.de>
Hello Marc,
first of all thanks for your contribution of the flexcan driver!
But i have a question regarding the Kconfig change that has been finally
committed to net-next-2.6.
It looks like the pulled code has some extra HAVE_CAN_FLEXCAN config option -
which may be something of your debugging environment - which was not part of
the original posted patch, where CAN_FLEXCAN depended on (ARCH_MX25 || ARCH_MX35).
Please see the two posted sections below ...
The depency of (ARCH_MX25 || ARCH_MX35) makes more sense to me ;-)
Regards,
Oliver
On 22.07.2010 18:40, Marc Kleine-Budde wrote:
> Hello,
>
> sorry for the confusion about the last minute problem with the driver,
> it was false alarm. Someone had troubles a driver derived from fsl's
> original one.
>
> David, please feel free to merge the driver now. :)
>
> Cheers, Marc
> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> index 2c5227c..9d9e453 100644
> --- a/drivers/net/can/Kconfig
> +++ b/drivers/net/can/Kconfig
> @@ -73,6 +73,15 @@ config CAN_JANZ_ICAN3
> This driver can also be built as a module. If so, the module will be
> called janz-ican3.ko.
>
> +config HAVE_CAN_FLEXCAN
> + bool
> +
> +config CAN_FLEXCAN
> + tristate "Support for Freescale FLEXCAN based chips"
> + depends on CAN_DEV && HAVE_CAN_FLEXCAN
> + ---help---
> + Say Y here if you want to support for Freescale FlexCAN.
> +
> source "drivers/net/can/mscan/Kconfig"
>
> source "drivers/net/can/sja1000/Kconfig"
On 21.07.2010 23:04, Marc Kleine-Budde wrote:
> diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> index 2c5227c..25924dd 100644
> --- a/drivers/net/can/Kconfig
> +++ b/drivers/net/can/Kconfig
> @@ -73,6 +73,12 @@ config CAN_JANZ_ICAN3
> This driver can also be built as a module. If so, the module will be
> called janz-ican3.ko.
>
> +config CAN_FLEXCAN
> + tristate "Support for Freescale FLEXCAN based chips"
> + depends on CAN_DEV && (ARCH_MX25 || ARCH_MX35)
> + ---help---
> + Say Y here if you want to support for Freescale FlexCAN.
> +
> source "drivers/net/can/mscan/Kconfig"
>
> source "drivers/net/can/sja1000/Kconfig"
^ permalink raw reply
* Re: [PATCH UPDATED 1/3] vhost: replace vhost_workqueue with per-vhost kthread
From: Michael S. Tsirkin @ 2010-07-25 10:04 UTC (permalink / raw)
To: Tejun Heo
Cc: Oleg Nesterov, Sridhar Samudrala, netdev, lkml,
kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev, Jiri Kosina,
Thomas Gleixner, Ingo Molnar, Andi Kleen
In-Reply-To: <4C4BEAA2.6040301@kernel.org>
On Sun, Jul 25, 2010 at 09:41:22AM +0200, Tejun Heo wrote:
> Hello,
>
> On 07/24/2010 09:14 PM, Michael S. Tsirkin wrote:
> >> I've created kthread_worker in wq#for-next tree and already converted
> >> ivtv to use it. Once this lands in mainline, I think converting vhost
> >> to use it would be better choice. kthread worker code uses basically
> >> the same logic used in the vhost_workqueue code but is better
> >> organized and documented. So, I think it would be better to stick
> >> with the original implementation, as otherwise we're likely to just
> >> decrease test coverage without much gain.
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/tj/wq.git;a=commitdiff;h=b56c0d8937e665a27d90517ee7a746d0aa05af46;hp=53c5f5ba42c194cb13dd3083ed425f2c5b1ec439
> >
> > Sure, if we keep using workqueue. But I'd like to investigate this
> > direction a bit more because there's discussion to switching from kthread to
> > regular threads altogether.
>
> Hmmm? It doesn't have much to do with workqueue. kthread_worker is a
> simple wrapper around kthread. It now assumes kthread but changing it
> to be useable with any thread shouldn't be too hard. Wouldn't that be
> better?
Yes, of course, when common code becomes available we should
switch to that.
> >> I don't think doing this before executing the function is correct,
> >
> > Well, before I execute the function work is NULL, so this is skipped.
> > Correct?
> >
> >> so
> >> you'll have to release the lock, execute the function, regrab the lock
> >> and then do the flush processing.
> >>
> >> Thanks.
> >
> > It's done in the loop, so I thought we can reuse the locking
> > done for the sake of processing the next work item.
> > Makes sense?
>
> Yeap, right. I think it would make much more sense to use common code
> when it becomes available but if you think the posted change is
> necessary till then, please feel free to go ahead.
>
> Thanks.
>
> --
> tejun
^ permalink raw reply
* Re: [PATCH net-next-2.6] pktgen: Optionally leak kernel memory
From: Eric Dumazet @ 2010-07-25 8:27 UTC (permalink / raw)
To: David Miller; +Cc: greearb, netdev
In-Reply-To: <20100724.213519.260107516.davem@davemloft.net>
Le samedi 24 juillet 2010 à 21:35 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sat, 24 Jul 2010 16:13:15 +0200
>
> > I am not sure David will accept the patch !
>
> I don't think I can apply this, sorry :-)
Absolutely.
It might be possible for pktgen to use a pool of prebuilt pages to avoid
the cost of clearing pages. This wont work for skb without frags, unless
we change skb_release_data() (it calls kfree(skb->head), I dont think we
can trap this one...)
One better idea would be to take an extra reference on skb before giving
it to transmit, and maintain a list of skbs to recycle once their
refcount hits 1 (our reference). We could avoid most of the skb
setup/freeing costs (no more memory allocations/freeing)
I'll take a look after my vacations, unless someone motivated enough
beats me of course :)
Thanks !
^ permalink raw reply
* Re: [PATCH UPDATED 1/3] vhost: replace vhost_workqueue with per-vhost kthread
From: Tejun Heo @ 2010-07-25 7:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Oleg Nesterov, Sridhar Samudrala, netdev, lkml,
kvm@vger.kernel.org, Andrew Morton, Dmitri Vorobiev, Jiri Kosina,
Thomas Gleixner, Ingo Molnar, Andi Kleen
In-Reply-To: <20100724191447.GA4972@redhat.com>
Hello,
On 07/24/2010 09:14 PM, Michael S. Tsirkin wrote:
>> I've created kthread_worker in wq#for-next tree and already converted
>> ivtv to use it. Once this lands in mainline, I think converting vhost
>> to use it would be better choice. kthread worker code uses basically
>> the same logic used in the vhost_workqueue code but is better
>> organized and documented. So, I think it would be better to stick
>> with the original implementation, as otherwise we're likely to just
>> decrease test coverage without much gain.
>>
>> http://git.kernel.org/?p=linux/kernel/git/tj/wq.git;a=commitdiff;h=b56c0d8937e665a27d90517ee7a746d0aa05af46;hp=53c5f5ba42c194cb13dd3083ed425f2c5b1ec439
>
> Sure, if we keep using workqueue. But I'd like to investigate this
> direction a bit more because there's discussion to switching from kthread to
> regular threads altogether.
Hmmm? It doesn't have much to do with workqueue. kthread_worker is a
simple wrapper around kthread. It now assumes kthread but changing it
to be useable with any thread shouldn't be too hard. Wouldn't that be
better?
>> I don't think doing this before executing the function is correct,
>
> Well, before I execute the function work is NULL, so this is skipped.
> Correct?
>
>> so
>> you'll have to release the lock, execute the function, regrab the lock
>> and then do the flush processing.
>>
>> Thanks.
>
> It's done in the loop, so I thought we can reuse the locking
> done for the sake of processing the next work item.
> Makes sense?
Yeap, right. I think it would make much more sense to use common code
when it becomes available but if you think the posted change is
necessary till then, please feel free to go ahead.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH] Driver-core: Always create class directories for classses that support namespaces.
From: Eric W. Biederman @ 2010-07-25 5:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Berg, Kay Sievers, Andrew Morton, Greg KH,
Rafael J. Wysocki, Maciej W. Rozycki, netdev,
<linux-kernel@vger.kernel.org> Marcel Holtmann,
linux-bluetooth, Greg KH
In-Reply-To: <20100722185449.GB528@suse.de>
This fixes the regression in 2.6.35-rcX where bluetooth network devices would
fail to be deleted from sysfs, causing their destruction and recreation to
fail. In addition this fixes the mac80211_hwsim driver where it would leave
around sysfs files when the driver was removed. This problem is discussed at
https://bugzilla.kernel.org/show_bug.cgi?id=16257
The reason for the regression is that the network namespace support added to
sysfs expects and requires that network devices be put in directories that can
contain only network devices. Today get_device_parent almost provides that
guarantee for all class devices, except for a specific exception when the
parent of a class devices is a class device. It would be nice to simply
remove that arguably incorrect special case, but apparently the input devices
depend on it being there. So I have only removed it for class devices with
network namespace support. Which today are the network devices.
It has been suggested that a better fix would be to change the parent device
from a class device to a bus device, which in the case of the bluetooth driver
would change /sys/class/bluetooth to /sys/bus/bluetoth, I can not see how we
would avoid significant userspace breakage if we were to make that change.
Adding an extra directory in the path to the device will also be userspace
visible but it is much less likely to break things. Everything is still
accessible from /sys/class (for example), and it fixes two bugs. Adding an
extra directory fixes a 3 year old regression introduced with the new sysfs
layout that makes if impossible to rename bnep0 network devices to names that
conflict with hci device attributes like hci_revsion. Adding an additional
directory remove the new failure modes introduced by the network namespace
code.
If it weren't for the regession in the renaming of network devices I would
figure out how to just make the sysfs code deal with this configuration of
devices.
In summary this patch fixes regressions by changing:
"/sys/class/bluetooth/hci0/bnep0" to "/sys/class/bluetooth/hci0/net/bnep0".
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
p.s. Linus my apologies for sending this directly but I have gotten an
incredible amount of flak trying to fix this problem, and I would like
not to leave an accidental regression whose cause is well known in
2.6.35 if I can help it.
drivers/base/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 9630fbd..9b9d3bd 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -673,7 +673,7 @@ static struct kobject *get_device_parent(struct device *dev,
*/
if (parent == NULL)
parent_kobj = virtual_device_parent(dev);
- else if (parent->class)
+ else if (parent->class && !dev->class->ns_type)
return &parent->kobj;
else
parent_kobj = &parent->kobj;
--
1.6.5.2.143.g8cc62
^ permalink raw reply related
* Re: [PATCH net-next-2.6] pktgen: Optionally leak kernel memory
From: David Miller @ 2010-07-25 4:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: greearb, netdev
In-Reply-To: <1279980795.2451.157.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 24 Jul 2010 16:13:15 +0200
> I am not sure David will accept the patch !
I don't think I can apply this, sorry :-)
^ permalink raw reply
* [PATCHv2 NEXT 1/2] qlcnic: fix loopback test
From: Amit Kumar Salecha @ 2010-07-25 4:32 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
In-Reply-To: <1280032338-7002-1-git-send-email-amit.salecha@qlogic.com>
o Loopback not supported for virtual function.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 2 --
drivers/net/qlcnic/qlcnic_ethtool.c | 10 ++++++++--
drivers/net/qlcnic/qlcnic_main.c | 18 ------------------
3 files changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index fad8e9a..9703893 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -1301,8 +1301,6 @@ struct qlcnic_nic_template {
int (*get_mac_addr) (struct qlcnic_adapter *, u8*);
int (*config_bridged_mode) (struct qlcnic_adapter *, u32);
int (*config_led) (struct qlcnic_adapter *, u32, u32);
- int (*set_ilb_mode) (struct qlcnic_adapter *);
- void (*clear_ilb_mode) (struct qlcnic_adapter *);
int (*start_firmware) (struct qlcnic_adapter *);
};
diff --git a/drivers/net/qlcnic/qlcnic_ethtool.c b/drivers/net/qlcnic/qlcnic_ethtool.c
index 7d6558e..9328d59 100644
--- a/drivers/net/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/qlcnic/qlcnic_ethtool.c
@@ -678,6 +678,12 @@ static int qlcnic_loopback_test(struct net_device *netdev)
int max_sds_rings = adapter->max_sds_rings;
int ret;
+ if (adapter->op_mode == QLCNIC_NON_PRIV_FUNC) {
+ dev_warn(&adapter->pdev->dev, "Loopback test not supported"
+ "for non privilege function\n");
+ return 0;
+ }
+
if (test_and_set_bit(__QLCNIC_RESETTING, &adapter->state))
return -EIO;
@@ -685,13 +691,13 @@ static int qlcnic_loopback_test(struct net_device *netdev)
if (ret)
goto clear_it;
- ret = adapter->nic_ops->set_ilb_mode(adapter);
+ ret = qlcnic_set_ilb_mode(adapter);
if (ret)
goto done;
ret = qlcnic_do_ilb_test(adapter);
- adapter->nic_ops->clear_ilb_mode(adapter);
+ qlcnic_clear_ilb_mode(adapter);
done:
qlcnic_diag_free_res(netdev, max_sds_rings);
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index f1f7acf..f147958 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -107,8 +107,6 @@ static void qlcnic_config_indev_addr(struct net_device *dev, unsigned long);
static int qlcnic_start_firmware(struct qlcnic_adapter *);
static void qlcnic_dev_set_npar_ready(struct qlcnic_adapter *);
-static void qlcnicvf_clear_ilb_mode(struct qlcnic_adapter *);
-static int qlcnicvf_set_ilb_mode(struct qlcnic_adapter *);
static int qlcnicvf_config_led(struct qlcnic_adapter *, u32, u32);
static int qlcnicvf_config_bridged_mode(struct qlcnic_adapter *, u32);
static int qlcnicvf_start_firmware(struct qlcnic_adapter *);
@@ -381,8 +379,6 @@ static struct qlcnic_nic_template qlcnic_ops = {
.get_mac_addr = qlcnic_get_mac_address,
.config_bridged_mode = qlcnic_config_bridged_mode,
.config_led = qlcnic_config_led,
- .set_ilb_mode = qlcnic_set_ilb_mode,
- .clear_ilb_mode = qlcnic_clear_ilb_mode,
.start_firmware = qlcnic_start_firmware
};
@@ -390,8 +386,6 @@ static struct qlcnic_nic_template qlcnic_vf_ops = {
.get_mac_addr = qlcnic_get_mac_address,
.config_bridged_mode = qlcnicvf_config_bridged_mode,
.config_led = qlcnicvf_config_led,
- .set_ilb_mode = qlcnicvf_set_ilb_mode,
- .clear_ilb_mode = qlcnicvf_clear_ilb_mode,
.start_firmware = qlcnicvf_start_firmware
};
@@ -2841,18 +2835,6 @@ qlcnicvf_config_led(struct qlcnic_adapter *adapter, u32 state, u32 rate)
return -EOPNOTSUPP;
}
-static int
-qlcnicvf_set_ilb_mode(struct qlcnic_adapter *adapter)
-{
- return -EOPNOTSUPP;
-}
-
-static void
-qlcnicvf_clear_ilb_mode(struct qlcnic_adapter *adapter)
-{
- return;
-}
-
static ssize_t
qlcnic_store_bridged_mode(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
--
1.6.0.2
^ permalink raw reply related
* [PATCHv2 NEXT 2/2] qlcnic: fix diag resource allocation
From: Amit Kumar Salecha @ 2010-07-25 4:32 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Sony Chacko
In-Reply-To: <1280032338-7002-1-git-send-email-amit.salecha@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
netif_device_attach missing from error path in qlcnic_diag_alloc_res
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic_main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index f147958..b9615bd 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -1176,6 +1176,7 @@ int qlcnic_diag_alloc_res(struct net_device *netdev, int test)
ret = qlcnic_fw_create_ctx(adapter);
if (ret) {
qlcnic_detach(adapter);
+ netif_device_attach(netdev);
return ret;
}
--
1.6.0.2
^ permalink raw reply related
* [PATCHv2 0/2]qlcnic: diagnostic fixes
From: Amit Kumar Salecha @ 2010-07-25 4:32 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
Hi
Series v2 of 2 patches to fix diagnostic test.
Apply them on net-next.
-Amit
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: pskb_expand_head() optimization
From: David Miller @ 2010-07-25 4:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: andrea, netdev
In-Reply-To: <1279861748.2482.13.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 23 Jul 2010 07:09:08 +0200
> [PATCH net-next-2.6] net: pskb_expand_head() optimization
>
> Move frags[] at the end of struct skb_shared_info, and make
> pskb_expand_head() copy only the used part of it instead of whole array.
>
> This should avoid kmemcheck warnings and speedup pskb_expand_head() as
> well, avoiding a lot of cache misses.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Maybe it's just that people aren't running kmemcheck when a
pskb_expand_head() triggers, who knows.
Anyways, since we skip the ->frag[] array in skb alloc, etc.,
your patch is of course fine.
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] net sched: fix race in mirred device removal
From: David Miller @ 2010-07-25 4:04 UTC (permalink / raw)
To: shemminger; +Cc: hadi, netdev
In-Reply-To: <20100722214504.42e0e7de@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 22 Jul 2010 21:45:04 -0700
> This fixes hang when target device of mirred packet classifier
> action is removed.
>
> If a mirror or redirection action is configured to cause packets
> to go to another device, the classifier holds a ref count, but was assuming
> the adminstrator cleaned up all redirections before removing. The fix
> is to add a notifier and cleanup during unregister.
>
> The new list is implicitly protected by RTNL mutex because
> it is held during filter add/delete as well as notifier.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: remove sysctl jiffies conversion on gc_elasticity and min_adv_ms
From: David Miller @ 2010-07-25 4:03 UTC (permalink / raw)
To: mzhang; +Cc: netdev
In-Reply-To: <4C48BA82.6020904@mvista.com>
From: Min Zhang <mzhang@mvista.com>
Date: Thu, 22 Jul 2010 14:39:14 -0700
> sysctl output ipv6 gc_elasticity and min_adv_mss as values divided by
> HZ. However, they are not in unit of jiffies, since ip6_rt_min_advmss
> refers to packet size and ip6_rt_fc_elasticity is used as scaler as in
> expire>>ip6_rt_gc_elasticity, so replace the jiffies conversion
> handler will regular handler for them.
>
> This has impact on scripts that are currently working assuming the
> divide by HZ, will yield different results with this patch in place.
>
> Signed-off-by: Min Zhang <mzhang@mvista.com>
Your email client corrupted your patch, turning tab characters into
spaces. This makes your patch unusable.
Please resubmit this patch properly so that I can use it.
Thanks.
^ permalink raw reply
* Re: [patch 2.6.35] WiMAX pull request
From: David Miller @ 2010-07-25 3:52 UTC (permalink / raw)
To: inaky; +Cc: netdev, wimax, inaky.perez-gonzalez
In-Reply-To: <cover.1279843906.git.inaky.perez-gonzalez@intel.com>
From: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Date: Thu, 22 Jul 2010 17:15:13 -0700
> The following changes since commit a385a53e659b35ebee604889e21c40e5c336941f:
> Inaky Perez-Gonzalez (1):
> wimax/i2400m: fix missing endian correction read in fw loader
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax.git wimax-2.6.35.y
>
> Patches follow for reviewing convenience.
>
> Alexey Shvetsov (1):
> wimax/i2400m: Add PID & VID for Intel WiMAX 6250
Pulled, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox