* RE: [RFC PATCH 0/8]: uninline & uninline
From: Hua Zhong @ 2008-02-23 19:58 UTC (permalink / raw)
To: 'Andrew Morton', 'Andi Kleen'
Cc: 'Ilpo Järvinen', netdev, linux-kernel,
'David Miller', 'Arnaldo Carvalho de Melo'
In-Reply-To: <20080223105517.4d706511.akpm@linux-foundation.org>
> > Is there any reason they couldn't just be merged to mainline?
> >
> > I think it's a useful facility.
>
> ummm, now why did we made that decision... I think we decided that
> it's the sort of thing which one person can run once per few months
> and that will deliver its full value. I can maintain it in -mm and
> we're happy - no need to add it to mainline. No strong feelings
> either way really.
Apparently nobody has been doing it for a while. :-) Last time I did it it
was around the submission time and I actually patched it into mainline
kernel to do so. Not particularly hard to do, but sitting in mm-only does
make it a bit harder, and there are the vdso problem you just mentioned that
one has to fix for himself if it exists in mainline.
> It does have the downside that the kernel explodes if someone adds
> unlikely or likely to the vdso code and I need to occasionally hunt
> down new additions and revert them in that patch. That makes it a
> bit of a maintenance burden.
Is it possible to catch this automatically, like, by re-defining
likely/unlikely to the raw form in specific file(s)?
Hua
^ permalink raw reply
* Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
From: Sebastian Siewior @ 2008-02-23 20:06 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Sebastian Siewior, Masakazu Mokuno, jgarzik, netdev
In-Reply-To: <200802232050.35157.IvDoorn@gmail.com>
* Ivo van Doorn | 2008-02-23 20:50:34 [+0100]:
>Additionally, what part of the driver actually uses mac80211?
>I just browsed to the code, and it seems to work completely without
>using mac80211. Instead it seems to work directly by registering a
>net_device structure...
CC drivers/net/ps3_gelic_wireless.o
/home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c: In function 'gelic_wl_setup_netdev_ops':
/home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c:2660: error: 'struct net_device' has no member named 'wireless_data'
/home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c:2661: error: 'struct net_device' has no member named 'wireless_handlers'
make[3]: *** [drivers/net/ps3_gelic_wireless.o] Error 1
make[2]: *** [drivers/net] Error 2
make[1]: *** [drivers] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [sub-make] Error 2
I add this to the patch desctiption and post a depends on patach
>Ivo
Sebastian
^ permalink raw reply
* Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
From: Sebastian Siewior @ 2008-02-23 20:09 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Masakazu Mokuno, jgarzik, netdev
In-Reply-To: <20080223200637.GA7135@Chamillionaire.breakpoint.cc>
* Sebastian Siewior | 2008-02-23 21:06:37 [+0100]:
>I add this to the patch desctiption and post a depends on patach
ARGH, this was CONFIG_WIRELESS_EXT and not MAC80211. You would like to
see a select or depend statement on that one?
>>Ivo
>
Sebastian
^ permalink raw reply
* Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
From: Ivo van Doorn @ 2008-02-23 20:09 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: Sebastian Siewior, Masakazu Mokuno, jgarzik, netdev
In-Reply-To: <20080223200637.GA7135@Chamillionaire.breakpoint.cc>
On Saturday 23 February 2008, Sebastian Siewior wrote:
> * Ivo van Doorn | 2008-02-23 20:50:34 [+0100]:
>
> >Additionally, what part of the driver actually uses mac80211?
> >I just browsed to the code, and it seems to work completely without
> >using mac80211. Instead it seems to work directly by registering a
> >net_device structure...
> CC drivers/net/ps3_gelic_wireless.o
> /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c: In function 'gelic_wl_setup_netdev_ops':
> /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c:2660: error: 'struct net_device' has no member named 'wireless_data'
> /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c:2661: error: 'struct net_device' has no member named 'wireless_handlers'
> make[3]: *** [drivers/net/ps3_gelic_wireless.o] Error 1
> make[2]: *** [drivers/net] Error 2
> make[1]: *** [drivers] Error 2
> make[1]: *** Waiting for unfinished jobs....
> make: *** [sub-make] Error 2
>
>
> I add this to the patch desctiption and post a depends on patach
Looking at include/linux/netdevice.h:
#ifdef CONFIG_WIRELESS_EXT
/* List of functions to handle Wireless Extensions (instead of ioctl).
* See <net/iw_handler.h> for details. Jean II */
const struct iw_handler_def * wireless_handlers;
/* Instance data managed by the core of Wireless Extensions. */
struct iw_public_data * wireless_data;
#endif
There is no dependency on mac80211 but on WIRELESS_EXT.
That is a config option most other drivers select, so you best change your patch to
select WIRELESS_EXT
instead of MAC80211.
Ivo
^ permalink raw reply
* Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
From: Sebastian Siewior @ 2008-02-23 20:15 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Masakazu Mokuno, jgarzik, netdev
In-Reply-To: <200802232044.59887.IvDoorn@gmail.com>
* Ivo van Doorn | 2008-02-23 20:44:59 [+0100]:
>Is there any particular reason why this driver is in drivers/net instead
>of drivers/net/wireless (along with all other wireless drivers?
My understanding is/was that the wireless device and the eth device are
exposed by the hypervisor to the system and they share ressources.
Sebastian
^ permalink raw reply
* Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
From: Ivo van Doorn @ 2008-02-23 20:19 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: Masakazu Mokuno, jgarzik, netdev
In-Reply-To: <20080223200910.GB7135@Chamillionaire.breakpoint.cc>
On Saturday 23 February 2008, Sebastian Siewior wrote:
> * Sebastian Siewior | 2008-02-23 21:06:37 [+0100]:
>
> >I add this to the patch desctiption and post a depends on patach
> ARGH, this was CONFIG_WIRELESS_EXT and not MAC80211. You would like to
> see a select or depend statement on that one?
Other drivers do a select on WIRELESS_EXT, so selecting it would be fine.
Ivo
^ permalink raw reply
* Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
From: Ivo van Doorn @ 2008-02-23 20:19 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: Masakazu Mokuno, jgarzik, netdev
In-Reply-To: <20080223201535.GC7135@Chamillionaire.breakpoint.cc>
On Saturday 23 February 2008, Sebastian Siewior wrote:
> * Ivo van Doorn | 2008-02-23 20:44:59 [+0100]:
>
> >Is there any particular reason why this driver is in drivers/net instead
> >of drivers/net/wireless (along with all other wireless drivers?
>
> My understanding is/was that the wireless device and the eth device are
> exposed by the hypervisor to the system and they share ressources.
Ah ok, makes sense. :)
Thanks.
Ivo
^ permalink raw reply
* [PATCH] [NET] [PS3] gelic wireless driver needs WIRELESS_EXT support
From: Sebastian Siewior @ 2008-02-23 20:25 UTC (permalink / raw)
To: Masakazu Mokuno; +Cc: jgarzik, netdev
| CC drivers/net/ps3_gelic_wireless.o
| /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c: In function 'gelic_wl_setup_netdev_ops':
| /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c:2660: error: 'struct net_device' has no member named 'wireless_data'
| /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c:2661: error: 'struct net_device' has no member named 'wireless_handlers'
| make[3]: *** [drivers/net/ps3_gelic_wireless.o] Error 1
| make[2]: *** [drivers/net] Error 2
| make[1]: *** [drivers] Error 2
| make[1]: *** Waiting for unfinished jobs....
| make: *** [sub-make] Error 2
Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc>
---
drivers/net/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f337800..e0a06e9 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2363,6 +2363,7 @@ config GELIC_NET
config GELIC_WIRELESS
bool "PS3 Wireless support"
depends on GELIC_NET
+ select WIRELESS_EXT
help
This option adds the support for the wireless feature of PS3.
If you have the wireless-less model of PS3 or have no plan to
--
1.5.3.8
^ permalink raw reply related
* Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
From: Jeff Garzik @ 2008-02-23 20:26 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: Masakazu Mokuno, netdev, linux-wireless
In-Reply-To: <20080223193517.GA6704@Chamillionaire.breakpoint.cc>
Sebastian Siewior wrote:
> so select it.
> Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc>
> ---
> drivers/net/Kconfig | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index f337800..a116056 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2363,6 +2363,7 @@ config GELIC_NET
> config GELIC_WIRELESS
> bool "PS3 Wireless support"
> depends on GELIC_NET
> + select MAC80211
Given that this is straying clearly into wireless territory, I think the
linux-wireless folks and John Linville (wireless maintainer) are
appropriate patch targets.
Jeff
^ permalink raw reply
* Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
From: Sebastian Siewior @ 2008-02-23 20:43 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Sebastian Siewior, Masakazu Mokuno, netdev, linux-wireless
In-Reply-To: <47C0815F.7020100@pobox.com>
* Jeff Garzik | 2008-02-23 15:26:07 [-0500]:
> Given that this is straying clearly into wireless territory, I think the
> linux-wireless folks and John Linville (wireless maintainer) are
> appropriate patch targets.
Okey, I'm going to forward the pach.
> Jeff
Sebastian
^ permalink raw reply
* Re: [RFC PATCH 0/8]: uninline & uninline
From: Andi Kleen @ 2008-02-23 21:02 UTC (permalink / raw)
To: Hua Zhong
Cc: 'Andrew Morton', 'Andi Kleen',
'Ilpo Järvinen', netdev, linux-kernel,
'David Miller', 'Arnaldo Carvalho de Melo'
In-Reply-To: <00ac01c87656$777c02a0$667407e0$@com>
> Is it possible to catch this automatically, like, by re-defining
> likely/unlikely to the raw form in specific file(s)?
Sure it would be possible to define a IN_VDSO symbol in all vdso
related files and then do that. Might be useful for other things
too. vdso has some very specific requirements.
-Andi
^ permalink raw reply
* [BUG][AX25] spinlock lockup
From: Jann Traschewski @ 2008-02-24 3:10 UTC (permalink / raw)
To: netdev, 'Jarek Poplawski'; +Cc: 'Ralf Baechle'
Hello,
I got a "spinlock lockup" using the latest Kernel 2.6.24.2 with recent
patches from Jarek Poplawski applied.
ppp_deflate nf_nat zlib_deflateBUG: unable to handle kernel NULL pointer
dereference zlib_inflate nf_conntrack_ipv4 bsd_comp slhc ppp_async xt_state
tun ppp_genericprinting eip: c02338c2 nf_conntrack bitrev ipt_REJECT*pde =
00000000 iptable_filter crc32
iptable_mangle mkiss xt_MARK at virtual address 00000004
ax25 ipv6Oops: 0002 [#1] SMP ipip crc16
tunnel4Modules linked in: iptable_nat ide_cd cdrom aic7xxx
scsi_transport_spi parport_serial parport_pc parport i2c_piix4 netconsole
genrtc
Pid: 3032, comm: linuxnet Not tainted (2.6.24.2-dg8ngn-p02 #1)
EIP: 0060:[<c02338c2>] EFLAGS: 00010092 CPU: 0
EIP is at skb_append+0x1b/0x30
EAX: 00000292 EBX: c9318980 ECX: c0466a80 EDX: 00000000
ESI: c9e085c0 EDI: f40846ac EBP: f40846b8 ESP: f72cbd04
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process linuxnet (pid: 3032, ti=f72ca000 task=f7d08030 task.ti=f72ca000)
Stack: c9318980 c9e085c0 f4084600 00000000 f8a0e2a3 f4084600 00000005
00000010 BUG: spinlock lockup on CPU#1, bcm/12213, f40846b8
Pid: 12213, comm: bcm Tainted: G D 2.6.24.2-dg8ngn-p02 #1
[<c01cb96f>] _raw_spin_lock+0xbb/0xdc
[<c0299fdc>] _spin_lock_irqsave+0x39/0x41
[<c02339bf>] skb_dequeue+0xf/0x3f
[<c02339bf>] skb_dequeue+0xf/0x3f
[<f8a0c998>] ax25_kick+0x14f/0x18c [ax25]
[<f8a10a26>] ax25_sendmsg+0x35f/0x49a [ax25]
[<c01473d1>] file_read_actor+0x7d/0xd5
[<c0147c35>] do_generic_mapping_read+0x1d5/0x3b2
[<c0147354>] file_read_actor+0x0/0xd5
[<c022e404>] sock_aio_write+0xbf/0xcb
[<c01494ba>] generic_file_aio_read+0x161/0x19c
[<c01627bb>] do_sync_write+0xc7/0x10a
[<c0130ea9>] autoremove_wake_function+0x0/0x35
[<c0162f48>] vfs_write+0x9e/0x10c
[<c01634b0>] sys_write+0x41/0x67
[<c0103ea2>] syscall_call+0x7/0xb
=======================
--
Jann Traschewski, Drosselstr.1, D-90513 Zirndorf, Germany
Tel.: +49-911-696971, Mobile: +49-170-1045937, EMail: jann@gmx.de
Ham: DG8NGN / DB0VOX, http://www.qsl.net/db0fhn, ICQ UIN: 4130182
^ permalink raw reply
* Re: [PATCH 1/3][BNX2]: More 5706S link down workaround.
From: David Miller @ 2008-02-24 3:48 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1203709778.13495.177.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 22 Feb 2008 11:49:38 -0800
> [BNX2]: More 5706S link down workaround.
>
> The previous patches to workaround the 5706S on an HP blade were not
> sufficient. The link state still does not change properly in some
> cases. This patch adds polling to make it completely reliable.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/3][BNX2]: Disable parallel detect on an HP blade.
From: David Miller @ 2008-02-24 3:49 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1203709811.13495.178.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 22 Feb 2008 11:50:11 -0800
> [BNX2]: Disable parallel detect on an HP blade.
>
> Because of some board issues, we need to disable parallel detect on
> an HP blade. Without this patch, the link state can become stuck
> when it goes into parallel detect mode.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 3/3][BNX2]: Update version to 1.7.4.
From: David Miller @ 2008-02-24 3:50 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1203709832.13495.179.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 22 Feb 2008 11:50:32 -0800
> [BNX2]: Update version to 1.7.4.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Also applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH] tg3: ethtool phys_id default (rev2)
From: David Miller @ 2008-02-24 3:52 UTC (permalink / raw)
To: mchan; +Cc: shemminger, jgarzik, netdev
In-Reply-To: <1203707802.13495.169.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 22 Feb 2008 11:16:42 -0800
> On Fri, 2008-02-22 at 10:24 -0800, Stephen Hemminger wrote:
> > When asked to blink LEDs the tg3 driver behaves when using:
> > ethtool -p ethX
> > The default value for data is zero, and other drivers interpret this
> > as blink forever (or at least a really long time). The tg3 driver
> > interprets this as blink once. All drivers should have the same
> > behaviour.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Acked-by: Michael Chan <mchan@broadcom.com>
Applied.
> We should do this across the board for bnx2, bnx2x, and niu as well.
Agreed.
^ permalink raw reply
* Re: [RTNL]: Validate hardware and broadcast address attribute for RTM_NEWLINK
From: David Miller @ 2008-02-24 3:55 UTC (permalink / raw)
To: kaber; +Cc: tgraf, netdev
In-Reply-To: <47BECF26.6030805@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Fri, 22 Feb 2008 14:33:26 +0100
> Thomas Graf wrote:
> > The reason I did it this way is to keep validate_linkmsg() generic
> > and make it possible to put validation code which must also apply
> > to new links (dev==NULL) into that function.
>
> OK, thanks for the explanation.
Patch applied, thanks.
^ permalink raw reply
* Re: [PATCH][NEIGH]: Fix race between neighbor lookup and table's hash_rnd update.
From: David Miller @ 2008-02-24 3:57 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <47BE97BF.6020600@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Fri, 22 Feb 2008 12:37:03 +0300
> The neigh_hash_grow() may update the tbl->hash_rnd value, which
> is used in all tbl->hash callbacks to calculate the hashval.
>
> Two lookup routines may race with this, since they call the
> ->hash callback without the tbl->lock held. Since the hash_rnd
> is changed with this lock write-locked moving the calls to ->hash
> under this lock read-locked closes this gap.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, thanks.
^ permalink raw reply
* Re: sungem triggers NAPI warning
From: David Miller @ 2008-02-24 3:58 UTC (permalink / raw)
To: benh; +Cc: johannes, netdev
In-Reply-To: <1203634227.10422.200.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 22 Feb 2008 09:50:27 +1100
> I still think the change is obviously correct, so I'll give a second
> close look at the code and produce a patch.
Patch coming soon? :)
^ permalink raw reply
* Re: [PATCH] Fix multicast on VLAN interfaces
From: David Miller @ 2008-02-24 4:00 UTC (permalink / raw)
To: kernel; +Cc: netdev, kaber
In-Reply-To: <20080221220542.GA19693@linuxace.com>
From: Phil Oester <kernel@linuxace.com>
Date: Thu, 21 Feb 2008 14:05:42 -0800
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 908f07c..999af2e 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2905,6 +2905,7 @@ int __dev_addr_add(struct dev_addr_list **list, int *count,
> return -ENOMEM;
> memcpy(da->da_addr, addr, alen);
> da->da_addrlen = alen;
> + da->da_synced = 0;
> da->da_users = 1;
> da->da_gusers = glbl ? 1 : 0;
> da->next = *list;
"da" is kzalloc()'d, how can da->da_synced not be zero?
^ permalink raw reply
* Re: kernel BUG at net/core/skbuff.c:95!
From: David Miller @ 2008-02-24 4:01 UTC (permalink / raw)
To: jwestfall; +Cc: netdev, acme
In-Reply-To: <20080221191352.GV84358@surrealistic.net>
From: Jim Westfall <jwestfall@surrealistic.net>
Date: Thu, 21 Feb 2008 11:13:52 -0800
> >
> > 2) Second, skb_realloc_headroom() is called on 'skb' with
> > a second argument of 'dsize'.
>
> This suggestion escapes me. The skb_put() call in the above
> code would increase skb->tail. Wont skb_realloc_headroom() create
> additional space between skb->head and skb->data when we really want it
> between skb->tail and skb->end?
My bad, you need to increase the tailroom not the headroom.
^ permalink raw reply
* Re: New sparse warning in net/mac80211/debugfs_sta.c
From: David Miller @ 2008-02-24 4:02 UTC (permalink / raw)
To: kaber; +Cc: joe, johannes, harvey.harrison, netdev
In-Reply-To: <47BDBC23.5080007@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Thu, 21 Feb 2008 19:00:03 +0100
> And adds back the overhead of two completely unnecessary
> function calls to the VLAN fastpath. How about just
> stopping this idiocy and reverting the appropriate patches
> to bring back MAC_FMT and use it where appropriate?
Agreed, I'll do that.
^ permalink raw reply
* Re: [PATCH] IPv6 Add more initializations of the new nl_info.nl_net field
From: David Miller @ 2008-02-24 4:02 UTC (permalink / raw)
To: benjamin.thery; +Cc: netdev
In-Reply-To: <20080221165219.657302066@theryb.frec.bull.fr>
From: benjamin.thery@bull.net
Date: Thu, 21 Feb 2008 17:51:50 +0100
> Add more missing initializations of the new nl_info.nl_net field in
> IPv6 stack.
> This field will be used when network namespaces are fully supported.
>
> Signed-off-by: Benjamin Thery <benjamin.thery@bull.net>
Initializations to "zero" are not necessary nor usually
done in these kinds of cases.
^ permalink raw reply
* [PATCH RESEND] libertas: Remove unused exports
From: Roland Dreier @ 2008-02-24 4:10 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, Dan Williams
In-Reply-To: <adaprv1vkl7.fsf@cisco.com>
Any chance of getting this applied? It seems the build is still
broken on ia64 at least due to the export of static functions.
---
The libertas driver exports a number of symbols with no in-tree
users; remove these unused exports. lbs_reset_device() is completely
unused, with no callers at all, so remove the function completely.
A couple of these unused exported symbols are static, which causes the
following build error on ia64 with gcc 4.2.3:
drivers/net/wireless/libertas/main.c:1375: error: __ksymtab_lbs_remove_mesh causes a section type conflict
drivers/net/wireless/libertas/main.c:1354: error: __ksymtab_lbs_add_mesh causes a section type conflict
This patch fixes this problem. I don't have hardware, so this is not
run-tested, but I tested the build with
CONFIG_LIBERTAS=y
CONFIG_LIBERTAS_USB=m
CONFIG_LIBERTAS_CS=m
CONFIG_LIBERTAS_SDIO=m
and there were no problems with undefined symbols.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
diff --git a/drivers/net/wireless/libertas/cmd.c b/drivers/net/wireless/libertas/cmd.c
index eab0203..b3c1acb 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -1040,7 +1040,6 @@ int lbs_mesh_access(struct lbs_private *priv, uint16_t cmd_action,
lbs_deb_leave(LBS_DEB_CMD);
return ret;
}
-EXPORT_SYMBOL_GPL(lbs_mesh_access);
int lbs_mesh_config(struct lbs_private *priv, uint16_t enable, uint16_t chan)
{
@@ -1576,7 +1575,6 @@ done:
lbs_deb_leave_args(LBS_DEB_HOST, "ret %d", ret);
return ret;
}
-EXPORT_SYMBOL_GPL(lbs_prepare_and_send_command);
/**
* @brief This function allocates the command buffer and link
diff --git a/drivers/net/wireless/libertas/decl.h b/drivers/net/wireless/libertas/decl.h
index aaacd9b..4e22341 100644
--- a/drivers/net/wireless/libertas/decl.h
+++ b/drivers/net/wireless/libertas/decl.h
@@ -69,7 +69,6 @@ struct lbs_private *lbs_add_card(void *card, struct device *dmdev);
int lbs_remove_card(struct lbs_private *priv);
int lbs_start_card(struct lbs_private *priv);
int lbs_stop_card(struct lbs_private *priv);
-int lbs_reset_device(struct lbs_private *priv);
void lbs_host_to_card_done(struct lbs_private *priv);
int lbs_update_channel(struct lbs_private *priv);
diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
index 84fb49c..1eaf6af 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -1351,8 +1350,6 @@ done:
lbs_deb_leave_args(LBS_DEB_MESH, "ret %d", ret);
return ret;
}
-EXPORT_SYMBOL_GPL(lbs_add_mesh);
-
static void lbs_remove_mesh(struct lbs_private *priv)
{
@@ -1372,7 +1369,6 @@ static void lbs_remove_mesh(struct lbs_private *priv)
free_netdev(mesh_dev);
lbs_deb_leave(LBS_DEB_MESH);
}
-EXPORT_SYMBOL_GPL(lbs_remove_mesh);
/**
* @brief This function finds the CFP in
@@ -1458,20 +1454,6 @@ void lbs_interrupt(struct lbs_private *priv)
}
EXPORT_SYMBOL_GPL(lbs_interrupt);
-int lbs_reset_device(struct lbs_private *priv)
-{
- int ret;
-
- lbs_deb_enter(LBS_DEB_MAIN);
- ret = lbs_prepare_and_send_command(priv, CMD_802_11_RESET,
- CMD_ACT_HALT, 0, 0, NULL);
- msleep_interruptible(10);
-
- lbs_deb_leave_args(LBS_DEB_MAIN, "ret %d", ret);
- return ret;
-}
-EXPORT_SYMBOL_GPL(lbs_reset_device);
-
static int __init lbs_init_module(void)
{
lbs_deb_enter(LBS_DEB_MAIN);
^ permalink raw reply related
* Re: [PATCH] Don't limit the number of tunnels with generic name explicitly.
From: David Miller @ 2008-02-24 4:20 UTC (permalink / raw)
To: xemul; +Cc: kaber, netdev, devel
In-Reply-To: <47BD70B8.3030507@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Thu, 21 Feb 2008 15:38:16 +0300
> Changelog:
>
> Use the added dev_alloc_name() call to create tunnel device name,
> rather than iterate in a hand-made loop with an artificial limit.
>
> Thanks Patrick for noticing this.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied, but I had to rework this in two places that didn't
apply cleanly.
The ip_gre.c and ipip.c changes remove a "failed" label but
that can't be done in the current tree as there are other
existing references.
^ 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