* Re: [PATCH 2.6.17-rc1] Fix RtNetlink ENCODE security permissions
From: Jean Tourrilhes @ 2006-04-14 18:06 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: linville, netdev, stable
In-Reply-To: <20060414105913.0222a8a6.rdunlap@xenotime.net>
On Fri, Apr 14, 2006 at 10:59:13AM -0700, Randy.Dunlap wrote:
> On Fri, 14 Apr 2006 10:47:26 -0700 Jean Tourrilhes wrote:
>
> > Hi John,
> >
> > I've just realised that the RtNetlink code does not check the
> > permission for SIOCGIWENCODE and SIOCGIWENCODEEXT, which means that
> > any user can read the encryption keys. The fix is trivial and should
> > go in 2.6.17 alonside the two other patch I sent you last week.
> > Fully tested on 2.6.17-rc1.
>
> and for -stable ??
The RtNetlink code (WE-20) was only included in 2.6.17-rc1 and
therefore is not available in 2.6.16.
Jean
^ permalink raw reply
* Fw: Openswan, iptables (fiaif) and 2.6.16 kernel
From: Andrew Morton @ 2006-04-14 17:59 UTC (permalink / raw)
To: netdev; +Cc: Laurent CARON
Begin forwarded message:
Date: Fri, 14 Apr 2006 14:32:39 +0200
From: Laurent CARON <lcaron@apartia.fr>
To: linux-kernel@vger.kernel.org
Subject: Openswan, iptables (fiaif) and 2.6.16 kernel
Hi,
I'm running an openswan gateway for quite a long time now.
I have used 2.4.X and 2.6.X kernels without any problem until i decided
to upgrade to 2.6.16 kernel.
Summary of problem:
Under 2.6.15 everything is fine
Under 2.6.16 my tunnels establish well, but i can't even ping a single
computer located on the other end of the tunnel when the firewall is up.
Disabling the firewall solves the problem (but is not an option for me).
$ cat ip_conntrack | grep 192.168.10
icmp 1 8 src=192.168.0.192 dst=192.168.10.1 type=8 code=0 id=793
packets=4 bytes=116 [UNREPLIED] src=192.168.10.1 dst=XXX.XXX.XXX.XXX
type=0 code=0 id=793 packets=0 bytes=0 mark=0 use=1
192.168.0.0/24 is my lan subnet (natted so that lan computers can access
the internet through the public ip address)
192.168.0.192 is a workstation on my lan
192.168.10.0/24 is the other subnet
XXX.XXX.XXX.XXX is my public ip address
If i disable the nat of 192.168.0.0/24, i can ping the other end.
Re-enabling the nat however disables the ability to ping the other end.
Seems iptables is trying to nat packets the wrong way :$, or that I
missed a major change in 2.6.16.
Do anyone have any clue about this weiredness?
Thanks
Laurent
_______________________________________________
Users@openswan.org
http://lists.openswan.org/mailman/listinfo/users
Building and Integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 2.6.17-rc1] Fix RtNetlink ENCODE security permissions
From: Randy.Dunlap @ 2006-04-14 17:59 UTC (permalink / raw)
To: jt; +Cc: linville, netdev, stable
In-Reply-To: <20060414174726.GA24421@bougret.hpl.hp.com>
On Fri, 14 Apr 2006 10:47:26 -0700 Jean Tourrilhes wrote:
> Hi John,
>
> I've just realised that the RtNetlink code does not check the
> permission for SIOCGIWENCODE and SIOCGIWENCODEEXT, which means that
> any user can read the encryption keys. The fix is trivial and should
> go in 2.6.17 alonside the two other patch I sent you last week.
> Fully tested on 2.6.17-rc1.
and for -stable ??
> Have fun...
>
> Jean
>
> Signed-off-by: Jean Tourrilhes <jt@hpl.hp.com>
>
> -----------------------------------------------------------
>
> diff -u -p linux/net/core/wireless.j1.c linux/net/core/wireless.c
> --- linux/net/core/wireless.j1.c 2006-04-13 18:29:49.000000000 -0700
> +++ linux/net/core/wireless.c 2006-04-13 18:35:59.000000000 -0700
> @@ -1726,6 +1726,14 @@ int wireless_rtnetlink_get(struct net_de
> if(!IW_IS_GET(request->cmd))
> return -EOPNOTSUPP;
>
> + /* If command is `get the encoding parameters', check if
> + * the user has the right to do it */
> + if (request->cmd == SIOCGIWENCODE ||
> + request->cmd == SIOCGIWENCODEEXT) {
> + if (!capable(CAP_NET_ADMIN))
> + return -EPERM;
> + }
> +
> /* Special cases */
> if(request->cmd == SIOCGIWSTATS)
> /* Get Wireless Stats */
>
> -
> 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
>
---
~Randy
^ permalink raw reply
* [PATCH 2.6.17-rc1] Fix RtNetlink ENCODE security permissions
From: Jean Tourrilhes @ 2006-04-14 17:47 UTC (permalink / raw)
To: John W. Linville, netdev
Hi John,
I've just realised that the RtNetlink code does not check the
permission for SIOCGIWENCODE and SIOCGIWENCODEEXT, which means that
any user can read the encryption keys. The fix is trivial and should
go in 2.6.17 alonside the two other patch I sent you last week.
Fully tested on 2.6.17-rc1.
Have fun...
Jean
Signed-off-by: Jean Tourrilhes <jt@hpl.hp.com>
-----------------------------------------------------------
diff -u -p linux/net/core/wireless.j1.c linux/net/core/wireless.c
--- linux/net/core/wireless.j1.c 2006-04-13 18:29:49.000000000 -0700
+++ linux/net/core/wireless.c 2006-04-13 18:35:59.000000000 -0700
@@ -1726,6 +1726,14 @@ int wireless_rtnetlink_get(struct net_de
if(!IW_IS_GET(request->cmd))
return -EOPNOTSUPP;
+ /* If command is `get the encoding parameters', check if
+ * the user has the right to do it */
+ if (request->cmd == SIOCGIWENCODE ||
+ request->cmd == SIOCGIWENCODEEXT) {
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+ }
+
/* Special cases */
if(request->cmd == SIOCGIWSTATS)
/* Get Wireless Stats */
^ permalink raw reply
* Re: [RFC: 2.6 patch] net/irda/irias_object.c: remove unused exports
From: Adrian Bunk @ 2006-04-14 17:23 UTC (permalink / raw)
To: Jean Tourrilhes; +Cc: Samuel.Ortiz, netdev, linux-kernel
In-Reply-To: <20060414164203.GA24146@bougret.hpl.hp.com>
On Fri, Apr 14, 2006 at 09:42:03AM -0700, Jean Tourrilhes wrote:
> Hi,
Hi Jean,
> You now need to send those patches to :
> Samuel.Ortiz@nokia.com
Samuel, please send a patch to update MAINTAINERS.
> Personally, I don't see what this patch buy us...
It makes the kernel image smaller.
> Jean
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [RFC: 2.6 patch] net/irda/irias_object.c: remove unused exports
From: Jean Tourrilhes @ 2006-04-14 16:42 UTC (permalink / raw)
To: Adrian Bunk, Samuel.Ortiz; +Cc: netdev, linux-kernel
In-Reply-To: <20060414114446.GL4162@stusta.de>
Hi,
You now need to send those patches to :
Samuel.Ortiz@nokia.com
Personally, I don't see what this patch buy us...
Jean
On Fri, Apr 14, 2006 at 01:44:46PM +0200, Adrian Bunk wrote:
> This patch removes the following unused EXPORT_SYMBOL's:
> - irias_find_attrib
> - irias_new_string_value
> - irias_new_octseq_value
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> ---
>
> net/irda/irias_object.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> --- linux-2.6.17-rc1-mm2-full/net/irda/irias_object.c.old 2006-04-14 12:37:49.000000000 +0200
> +++ linux-2.6.17-rc1-mm2-full/net/irda/irias_object.c 2006-04-14 12:39:26.000000000 +0200
> @@ -257,7 +257,6 @@
> /* Unsafe (locking), attrib might change */
> return attrib;
> }
> -EXPORT_SYMBOL(irias_find_attrib);
>
> /*
> * Function irias_add_attribute (obj, attrib)
> @@ -484,7 +483,6 @@
>
> return value;
> }
> -EXPORT_SYMBOL(irias_new_string_value);
>
> /*
> * Function irias_new_octseq_value (octets, len)
> @@ -519,7 +517,6 @@
> memcpy(value->t.oct_seq, octseq , len);
> return value;
> }
> -EXPORT_SYMBOL(irias_new_octseq_value);
>
> struct ias_value *irias_new_missing_value(void)
> {
>
^ permalink raw reply
* Re: [PATCH] ipw2100: wraps the debug module param within #ifdefs
From: Stephen Hemminger @ 2006-04-14 16:33 UTC (permalink / raw)
To: Zhu Yi; +Cc: netdev, John W. Linville
In-Reply-To: <1144991911.968.157.camel@debian.sh.intel.com>
On Fri, 14 Apr 2006 13:18:31 +0800
Zhu Yi <yi.zhu@intel.com> wrote:
> On Thu, 2006-04-13 at 10:30 -0700, Stephen Hemminger wrote:
> > Please get rid of the debug config option. Make the debug code, default
> > off and be low enough impact that everyone can ship with it.
>
> This patch is exactly doing so. There won't be the debug module param if
> CONFIG_IPW2200_DEBUG is not defined. Otherwise it could be used to set
> different debug level, which helps a lot for the driver debuging.
>
I meant get rid of CONFIG_IPW2200_DEBUG completely. Having the debug code isn't
bad, and there is no reason not to have it always there.
^ permalink raw reply
* Re: [patch 1/3] softmac: return -EAGAIN from getscan while scanning
From: Herbert Xu @ 2006-04-14 15:58 UTC (permalink / raw)
To: jt; +Cc: shemminger, netdev
In-Reply-To: <20060414000129.GB23116@bougret.hpl.hp.com>
Jean Tourrilhes <jt@hpl.hp.com> wrote:
>
> We have the message interface (through a Wireless Events,
> since WE-14). However, netlink is highly undesirable in embedded space
> for bloat reason.
Why is that? I've seen many embedded applications using netlink
for either routing or IPsec. It doesn't take much code at all
to do netlink.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <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
* via_rhine/qdisc Dead loop on netdevice eth1, fix it urgently!
From: James Bourne @ 2006-04-14 15:51 UTC (permalink / raw)
To: netdev
Had this happen this morning on my gateway box. Any
o via rhine net device (eth1) and 8139too for eth0.
o kernel Linux bama.hardrock.org 2.6.16-1.2069_FC4 #1 Tue Mar 28 12:19:10 EST 2006 i686 athlon i386 GNU/Linux
o FC4 with all current patches, no binary modules in the kernel
o UP
If there's any other info required please email me, I'm not currently on the
list.
Regards
James
--
James Bourne | Email: jbourne@hardrock.org
UNIX Systems Administration | WWW: http://www.hardrock.org
Custom UNIX Programming | Linux: The choice of a GNU generation
----------------------------------------------------------------------
"All you need's an occasional kick in the philosophy." Frank Herbert
Apr 14 08:32:53 bama kernel: nfs: server 172.16.1.14 OK
Apr 14 08:32:53 bama kernel: nfs: server 172.16.1.14 OK
Apr 14 08:32:53 bama kernel: BUG: spinlock trylock failure on UP on CPU#0, df/9753 (Not tainted)
Apr 14 08:32:53 bama kernel: lock: f7cd494c, .magic: dead4ead, .owner: df/9753, .owner_cpu: 0
Apr 14 08:32:53 bama kernel: [<c01de996>] _raw_spin_trylock+0x39/0x3d [<c03123fb>] _spin_trylock+0x5/0xe
Apr 14 08:32:53 bama kernel: [<c02c1e0d>] qdisc_restart+0x37/0x1ec [<c02b440a>] dev_queue_xmit+0x7d/0x2bd
Apr 14 08:32:53 bama kernel: [<c02d4a9b>] ip_output+0x179/0x2be [<c02d42a8>] ip_finish_output+0x0/0x22a
Apr 14 08:32:53 bama kernel: [<c02d4059>] ip_queue_xmit+0x28c/0x4db [<c02d18f0>] dst_output+0x0/0x7
Apr 14 08:32:53 bama kernel: [<c0312433>] _spin_lock_irqsave+0x9/0xd [<c0124173>] lock_timer_base+0x15/0x2f
Apr 14 08:32:53 bama kernel: [<c03124c9>] _write_unlock_bh+0x5/0xa [<c02e852d>] tcp_v4_send_check+0x38/0xcf
Apr 14 08:32:53 bama kernel: [<c02e2d2b>] tcp_transmit_skb+0x3d2/0x700 [<c02def6c>] tcp_ack+0x6a0/0x193d
Apr 14 08:32:53 bama kernel: [<c02e4bdd>] __tcp_push_pending_frames+0x128/0x3a6 [<c02e1c84>] tcp_rcv_established+0x268/0x724
Apr 14 08:32:53 bama kernel: [<c02e8663>] tcp_v4_do_rcv+0x9f/0x2ec [<c02e97fe>] tcp_v4_rcv+0x946/0x94d
Apr 14 08:32:54 bama kernel: [<c02ced8c>] ip_local_deliver_finish+0x0/0x1b8 [<c02cf050>] ip_local_deliver+0x10c/0x248
Apr 14 08:32:54 bama kernel: [<c02ced8c>] ip_local_deliver_finish+0x0/0x1b8 [<c02cf493>] ip_rcv+0x307/0x4d4
Apr 14 08:32:54 bama kernel: [<c02ceaf8>] ip_rcv_finish+0x0/0x294 [<f886da0f>] rtl8139_poll+0x13d/0x4c6 [8139too]
Apr 14 08:32:54 bama kernel: [<c02e59b4>] tcp_write_timer+0x37/0x5fc [<c02b4a52>] netif_receive_skb+0x23b/0x310
Apr 14 08:32:54 bama kernel: [<c02b4b92>] process_backlog+0x6b/0xfb [<c02b3592>] net_rx_action+0x8a/0x17c
Apr 14 08:32:54 bama kernel: [<c01211fb>] __do_softirq+0x3e/0x8a [<c01050e6>] do_softirq+0x3e/0x48
Apr 14 08:32:54 bama kernel: =======================
Apr 14 08:32:54 bama kernel: [<c0105077>] do_IRQ+0x51/0x82 [<c01036e2>] common_interrupt+0x1a/0x20
Apr 14 08:32:54 bama kernel: [<f887592e>] rhine_start_tx+0xff/0x256 [via_rhine] [<c02beb5f>] find_skb+0x2e/0xe2
Apr 14 08:32:54 bama kernel: [<c02becbb>] netpoll_send_skb+0xa8/0x100 [<f8c4c174>] write_msg+0x140/0x181 [netconsole]
Apr 14 08:32:54 bama kernel: [<f8c4c034>] write_msg+0x0/0x181 [netconsole] [<c011c288>] __call_console_drivers+0x38/0x44
Apr 14 08:32:54 bama kernel: [<c011c455>] release_console_sem+0xb8/0x1e1 [<c011cf79>] vprintk+0x2bb/0x372
Apr 14 08:32:54 bama kernel: [<c0312488>] _spin_unlock_irq+0x5/0x7 [<f8cd9666>] __rpc_do_wake_up_task+0x104/0x20d [sunrpc]
Apr 14 08:32:54 bama kernel: [<c0312433>] _spin_lock_irqsave+0x9/0xd [<c011d04f>] printk+0x1f/0xb9
Apr 14 08:32:54 bama kernel: [<c03119d3>] __wait_on_bit+0x54/0x5e [<f8cd9087>] rpc_wait_bit_interruptible+0x0/0x22 [sunrpc]
Apr 14 08:32:54 bama kernel: [<f8cd4a51>] call_decode+0x136/0x569 [sunrpc] [<c0124cbb>] del_timer+0x43/0x4b
Apr 14 08:32:54 bama kernel: [<f8d2bc4e>] nfs3_xdr_fsstatres+0x0/0x100 [nfs] [<f8cd9b40>] __rpc_execute+0x54/0x1c3 [sunrpc]
Apr 14 08:32:54 bama kernel: [<f8cd572b>] rpc_call_sync+0x8c/0xa1 [sunrpc] [<f8d28672>] nfs3_rpc_wrapper+0x42/0x79 [nfs]
Apr 14 08:32:54 bama kernel: [<f8d2a29c>] nfs3_proc_statfs+0x69/0x9d [nfs] [<f8d20224>] nfs_statfs+0x55/0x1bc [nfs]
Apr 14 08:32:54 bama kernel: [<c01d955f>] _atomic_dec_and_lock+0x27/0x38 [<c016f1ef>] dput+0xb6/0x1bd
Apr 14 08:32:54 bama kernel: [<c0166d63>] __follow_mount+0x45/0x6c [<c01d955f>] _atomic_dec_and_lock+0x27/0x38
Apr 14 08:32:54 bama kernel: [<c0172e70>] mntput_no_expire+0x13/0x71 [<c01678ff>] __link_path_walk+0xa25/0xeee
Apr 14 08:32:54 bama kernel: [<c0158251>] vfs_statfs+0x48/0x5d [<c0158276>] vfs_statfs64+0x10/0x21
Apr 14 08:32:54 bama kernel: [<c0158353>] sys_statfs64+0x5f/0x97 [<c0159bd3>] vfs_write+0xfa/0x15a
Apr 14 08:32:54 bama kernel: [<c015a4ca>] sys_write+0x41/0x6a [<c0102d15>] syscall_call+0x7/0xb
Apr 14 08:32:54 bama kernel: Dead loop on netdevice eth1, fix it urgently!
Apr 14 08:32:54 bama last message repeated 3 times
Apr 14 08:32:54 bama kernel: nfs: server 172.16.1.14 OK
^ permalink raw reply
* Re: [RFC] Geographical/regulatory information for ieee80211
From: Jouni Malinen @ 2006-04-14 15:27 UTC (permalink / raw)
To: Larry Finger; +Cc: netdev, jeffl
In-Reply-To: <443EF3E9.7050303@lwfinger.net>
On Thu, Apr 13, 2006 at 07:59:21PM -0500, Larry Finger wrote:
> I am planning on writing a new routine to be added to
> net/ieee80211/ieee80211_geo.c that will populate an ieee80211_geo object
> given a country code. The new routine will eliminate the need for each
> driver to do their own.
> Neglecting any discussion of maximum power, I have been able to arrange the
> countries into the following groups:
The maximum power would be quite useful--I would say required--part of
regulatory domain information.. In other words, I would like to see the
groups created in a way that would take differences in power limits into
account. Without this, the groups will need to be re-created at some
point in the future when IEEE 802.11d and IEEE 802.11h would like to use
the same table.. In addition, flag of specifying indoor/outdoor/both
would be a nice addition.
It would be useful to have a text file with all the information in an
easily parseable format. I would like to be able to add a user space
tool that uses this file to take care of channel/TX power policies. The
needed parameters would then be configured for the kernel side 802.11
whenever needed.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH] net: expose vlan structure to user space
From: David Acker @ 2006-04-14 13:15 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <4436BB69.3010205@roinet.com>
David Acker wrote:
> From Dave Acker <dacker@roinet.com>
>
> The purpose is to allow a user space program to use the vlan_ethhdr
> structure when directly handling 802.1Q packets. This can be done
> by using a raw socket like:
> int s = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
> This socket should see VLAN packets from the base interface unchanged
> (i.e. vlan tag still in packet).
> Currently other user space programs that understand VLANs seem to all
> create their own definitions for this structure.
> This patch does NOT expose the defines related to the sizes of VLAN
> packets and
> their fields; it only exposes the vlan_ethhdr structure. It was determined
> that these sizes are not useful since the packet could be as large the MTU
> of the underlying physical network. Also, you can have nested VLAN headers
> such that the actual data offset is greater than the size of the
> vlan_ethhdr
> structure.
> -Dave Acker
>
Hello folks. Although some conversation appeared on earlier postings of
this patch, I though I would reply here since the post I am replying to
here gets the diff format right (from the top level instead of deep in
the source). Last I heard:
David S. Miller wrote:
> I think this really belongs in a portable header file
> in glibc somewhere.
David, while I can try to work with the glibc folks, I don't understand
how this patch would be different from what if_ether.h exposes to user
space today. Why is one appropriate and the other not? I am not trying
to be a pain; I am just trying to understand the rationale so that I can
explain it to others.
Thanks,
Dave Acker
^ permalink raw reply
* Re: [RFC] Geographical/regulatory information for ieee80211
From: Faidon Liambotis @ 2006-04-14 11:58 UTC (permalink / raw)
To: netdev
In-Reply-To: <Pine.LNX.4.58.0604141339580.6730@p15091797.pureserver.info>
Ulrich Kunitz wrote:
> For the 802.11a frequencies, there are three bands:
>
> Annex 3 Band B 5150-5250 MHz for indoor use (36-48)
> Annex 3 Band C 5250-5350 MHz for indoor use (52-64)
> Annex 3 Band D 5470-5725 MHz for outdoor use (100-140)
>
> However these bands are not available in all European states,
> details can be found in the recommendation. Spain, Portugal,
> Greece and Belgium for instance don't allow Annex 3 Band D.
Actually, Greece allows 5150-5250 and 5250-5350MHz for indoor use and
5470-5725 for indoor and outdoor use.
This is quite new though (3rd April) :-)
As I've mailed Larry in private, EU countries will eventually conform to
this:
http://europa.eu.int/eur-lex/lex/LexUriServ/LexUriServ.do?uri=CELEX:32005D0513:EN:NOT
Regards,
Faidon
^ permalink raw reply
* [RFC: 2.6 patch] net/irda/irias_object.c: remove unused exports
From: Adrian Bunk @ 2006-04-14 11:44 UTC (permalink / raw)
To: Jean Tourrilhes; +Cc: netdev, linux-kernel
This patch removes the following unused EXPORT_SYMBOL's:
- irias_find_attrib
- irias_new_string_value
- irias_new_octseq_value
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
net/irda/irias_object.c | 3 ---
1 file changed, 3 deletions(-)
--- linux-2.6.17-rc1-mm2-full/net/irda/irias_object.c.old 2006-04-14 12:37:49.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/net/irda/irias_object.c 2006-04-14 12:39:26.000000000 +0200
@@ -257,7 +257,6 @@
/* Unsafe (locking), attrib might change */
return attrib;
}
-EXPORT_SYMBOL(irias_find_attrib);
/*
* Function irias_add_attribute (obj, attrib)
@@ -484,7 +483,6 @@
return value;
}
-EXPORT_SYMBOL(irias_new_string_value);
/*
* Function irias_new_octseq_value (octets, len)
@@ -519,7 +517,6 @@
memcpy(value->t.oct_seq, octseq , len);
return value;
}
-EXPORT_SYMBOL(irias_new_octseq_value);
struct ias_value *irias_new_missing_value(void)
{
^ permalink raw reply
* Re: [RFC] Geographical/regulatory information for ieee80211
From: Ulrich Kunitz @ 2006-04-14 11:41 UTC (permalink / raw)
To: Larry Finger; +Cc: netdev, jeffl
In-Reply-To: <443EF3E9.7050303@lwfinger.net>
Larry,
the CISCO list is not correct. For Europe the detailed information
can be found in the recommendation ERC/REC 70-03 of the European
Radiocommunications Office. It is downloadable from this page:
http://www.ero.dk/documentation/docs/doccategory.asp?catid=2&catname=ECC/ERC/ECTRA%20Recommendations
The WLAN frequencies are specified in Annex 3 and the national
restrictions can be found in Appendix 3.
So for 802.11b/g channels 1-13 can be used across Europe. France
has some differing power requirements. Italy require license for
outdoor usage. Luxembourg authorisation for public usage. Romania
requires an individual license.
For the 802.11a frequencies, there are three bands:
Annex 3 Band B 5150-5250 MHz for indoor use (36-48)
Annex 3 Band C 5250-5350 MHz for indoor use (52-64)
Annex 3 Band D 5470-5725 MHz for outdoor use (100-140)
However these bands are not available in all European states,
details can be found in the recommendation. Spain, Portugal,
Greece and Belgium for instance don't allow Annex 3 Band D.
Uli
On Thu, 13 Apr 2006, Larry Finger wrote:
> I am planning on writing a new routine to be added to
> net/ieee80211/ieee80211_geo.c that will populate an ieee80211_geo object given
> a country code. The new routine will eliminate the need for each driver to do
> their own.
>
> Finding the allowable channels, etc. for various countries has not been easy;
> however, Cisco
> (http://www.cisco.com/en/US/products/ps6305/products_configuration_guide_chapter
> 09186a008059c96f.html) has what seems to be the most complete listing of
> country information. Neglecting any discussion of maximum power, I have been
> able to arrange the countries into the following groups:
--
Ulrich Kunitz - kune@deine-taler.de
^ permalink raw reply
* Re: [RFC: 2.6 patch] net/netlink/: possible cleanups
From: Evgeniy Polyakov @ 2006-04-14 10:56 UTC (permalink / raw)
To: Adrian Bunk; +Cc: netdev, linux-kernel
In-Reply-To: <20060414103202.GF4162@stusta.de>
On Fri, Apr 14, 2006 at 12:32:02PM +0200, Adrian Bunk (bunk@stusta.de) wrote:
> On Thu, Apr 13, 2006 at 01:26:03PM -0700, David S. Miller wrote:
> > From: Adrian Bunk <bunk@stusta.de>
> > Date: Thu, 13 Apr 2006 18:27:10 +0200
> >
> > > This patch contains the following possible cleanups plus changes related
> > > to them:
> > > - make the following needlessly global functions static:
> > > - attr.c: __nla_reserve()
> > > - attr.c: __nla_put()
> > > - #if 0 the following unused global functions:
> > > - attr.c: nla_validate()
> > > - attr.c: nla_find()
> > > - attr.c: nla_memcpy()
> > > - attr.c: nla_memcmp()
> > > - attr.c: nla_strcmp()
> > > - attr.c: nla_reserve()
> > > - genetlink.c: genl_unregister_ops()
> > > - remove the following unused EXPORT_SYMBOL's:
> > > - af_netlink.c: netlink_set_nonroot
> > > - attr.c: nla_parse
> > > - attr.c: nla_strlcpy
> > > - attr.c: nla_put
> > >
> > > Signed-off-by: Adrian Bunk <bunk@stusta.de>
...
> Anything else where a removal might be OK?
__nla_* helpers were created for small performance optimisation
if reservation is heavily used.
nla_* helpers were created to be used, but not to be removed or
commented. Some of them are used in generic netlink family.
Others and genl_register/unregister_ops() might be used in recenly
announced accounting patches.
genl_unregister_ops() is supposed to be used in, for example,
generic netlink exit path (which can not be called though).
Although it is always statically built systems, it is still very
convenient way of netlink usage for others (future modular systems).
> cu
> Adrian
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [RFC: 2.6 patch] net/netlink/: possible cleanups
From: Adrian Bunk @ 2006-04-14 10:32 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20060413.132603.94193712.davem@davemloft.net>
On Thu, Apr 13, 2006 at 01:26:03PM -0700, David S. Miller wrote:
> From: Adrian Bunk <bunk@stusta.de>
> Date: Thu, 13 Apr 2006 18:27:10 +0200
>
> > This patch contains the following possible cleanups plus changes related
> > to them:
> > - make the following needlessly global functions static:
> > - attr.c: __nla_reserve()
> > - attr.c: __nla_put()
> > - #if 0 the following unused global functions:
> > - attr.c: nla_validate()
> > - attr.c: nla_find()
> > - attr.c: nla_memcpy()
> > - attr.c: nla_memcmp()
> > - attr.c: nla_strcmp()
> > - attr.c: nla_reserve()
> > - genetlink.c: genl_unregister_ops()
> > - remove the following unused EXPORT_SYMBOL's:
> > - af_netlink.c: netlink_set_nonroot
> > - attr.c: nla_parse
> > - attr.c: nla_strlcpy
> > - attr.c: nla_put
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> Bunk-bot, you have to stop.
>
> These interfaces were added so that new users of netlink could
> write their code more easily.
>
> Unused does not equate to "comment out or delete".
Can you give a more detailed answer which parts of my patch you disagree
with?
Is the export of netlink_set_nonroot that seems to be both present and
unused since at least kernel 2.6.0 covered by your statement?
Anything else where a removal might be OK?
I'll then send a stripped-down patch (if any non-empty subset of my
patch is OK).
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* [PATCH] IrDA: smsc-ircc2, smcinit support for ALi ISA bridges
From: Samuel Ortiz @ 2006-04-14 10:16 UTC (permalink / raw)
To: ext David S. Miller; +Cc: netdev, Jean Tourrilhes, IrDA users
Hi David,
This patch enables support for ALi ISA bridges when we run the smcinit code.
It is needed to properly configure some Toshiba laptops.
Patch from Linus Walleij <triad@df.lth.se>
Signed-off-by: Samuel Ortiz <samuel.ortiz@nokia.com>
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
index bbcfc8e..58f76ce 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -225,6 +225,8 @@ static int __init smsc_superio_lpc(unsig
#ifdef CONFIG_PCI
static int __init preconfigure_smsc_chip(struct smsc_ircc_subsystem_configuration *conf);
static int __init preconfigure_through_82801(struct pci_dev *dev, struct smsc_ircc_subsystem_configuration *conf);
+static void __init preconfigure_ali_port(struct pci_dev *dev,
+ unsigned short port);
static int __init preconfigure_through_ali(struct pci_dev *dev, struct smsc_ircc_subsystem_configuration *conf);
static int __init smsc_ircc_preconfigure_subsystems(unsigned short ircc_cfg,
unsigned short ircc_fir,
@@ -2327,9 +2329,14 @@ static int __init smsc_superio_lpc(unsig
* pre-configuration not properly done by the BIOS (especially laptops)
* This code is based in part on smcinit.c, tosh1800-smcinit.c
* and tosh2450-smcinit.c. The table lists the device entries
- * for ISA bridges with an LPC (Local Peripheral Configurator)
- * that are in turn used to configure the SMSC device with default
- * SIR and FIR I/O ports, DMA and IRQ.
+ * for ISA bridges with an LPC (Low Pin Count) controller which
+ * handles the communication with the SMSC device. After the LPC
+ * controller is initialized through PCI, the SMSC device is initialized
+ * through a dedicated port in the ISA port-mapped I/O area, this latter
+ * area is used to configure the SMSC device with default
+ * SIR and FIR I/O ports, DMA and IRQ. Different vendors have
+ * used different sets of parameters and different control port
+ * addresses making a subsystem device table necessary.
*/
#ifdef CONFIG_PCI
#define PCIID_VENDOR_INTEL 0x8086
@@ -2340,9 +2347,10 @@ static struct smsc_ircc_subsystem_config
.device = 0x24cc,
.subvendor = 0x103c,
.subdevice = 0x088c,
- .sir_io = 0x02f8, /* Quite certain these are the same for nc8000 as for nc6000 */
+ /* Quite certain these are the same for nc8000 as for nc6000 */
+ .sir_io = 0x02f8,
.fir_io = 0x0130,
- .fir_irq = 0x09,
+ .fir_irq = 0x05,
.fir_dma = 0x03,
.cfg_base = 0x004e,
.preconfigure = preconfigure_through_82801,
@@ -2355,60 +2363,79 @@ static struct smsc_ircc_subsystem_config
.subdevice = 0x0890,
.sir_io = 0x02f8,
.fir_io = 0x0130,
- .fir_irq = 0x09,
+ .fir_irq = 0x05,
.fir_dma = 0x03,
.cfg_base = 0x004e,
.preconfigure = preconfigure_through_82801,
.name = "HP nc6000",
},
{
- .vendor = PCIID_VENDOR_INTEL, /* Intel 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge */
+ /* Intel 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge */
+ .vendor = PCIID_VENDOR_INTEL,
.device = 0x24c0,
.subvendor = 0x1179,
- .subdevice = 0xffff, /* 0xffff is "any", Not sure, 0x0001 or 0x0002 */
+ .subdevice = 0xffff, /* 0xffff is "any" */
.sir_io = 0x03f8,
.fir_io = 0x0130,
.fir_irq = 0x07,
.fir_dma = 0x01,
.cfg_base = 0x002e,
.preconfigure = preconfigure_through_82801,
- .name = "Toshiba Satellite 2450",
+ .name = "Toshiba laptop with Intel 82801DB/DBL LPC bridge",
},
{
.vendor = PCIID_VENDOR_INTEL, /* Intel 82801CAM ISA bridge */
- .device = 0x248c, /* Some use 24cc? */
+ .device = 0x248c,
+ .subvendor = 0x1179,
+ .subdevice = 0xffff, /* 0xffff is "any" */
+ .sir_io = 0x03f8,
+ .fir_io = 0x0130,
+ .fir_irq = 0x03,
+ .fir_dma = 0x03,
+ .cfg_base = 0x002e,
+ .preconfigure = preconfigure_through_82801,
+ .name = "Toshiba laptop with Intel 82801CAM ISA bridge",
+ },
+ {
+ /* 82801DBM (ICH4-M) LPC Interface Bridge */
+ .vendor = PCIID_VENDOR_INTEL,
+ .device = 0x24cc,
.subvendor = 0x1179,
- .subdevice = 0xffff, /* 0xffff is "any", Not sure, 0x0001 or 0x0002 */
+ .subdevice = 0xffff, /* 0xffff is "any" */
.sir_io = 0x03f8,
.fir_io = 0x0130,
.fir_irq = 0x03,
.fir_dma = 0x03,
.cfg_base = 0x002e,
.preconfigure = preconfigure_through_82801,
- .name = "Toshiba Satellite 5100/5200, Tecra 9100",
+ .name = "Toshiba laptop with Intel 8281DBM LPC bridge",
},
{
- .vendor = PCIID_VENDOR_ALI, /* ALi M1533/M1535 PCI to ISA Bridge [Aladdin IV/V/V+] */
+ /* ALi M1533/M1535 PCI to ISA Bridge [Aladdin IV/V/V+] */
+ .vendor = PCIID_VENDOR_ALI,
.device = 0x1533,
.subvendor = 0x1179,
- .subdevice = 0xffff, /* 0xffff is "any", Not sure, 0x0001 or 0x0002 */
+ .subdevice = 0xffff, /* 0xffff is "any" */
.sir_io = 0x02e8,
.fir_io = 0x02f8,
.fir_irq = 0x07,
.fir_dma = 0x03,
.cfg_base = 0x002e,
.preconfigure = preconfigure_through_ali,
- .name = "Toshiba Satellite 1800",
+ .name = "Toshiba laptop with ALi ISA bridge",
},
{ } // Terminator
};
/*
- * This sets up the basic SMSC parameters (FIR port, SIR port, FIR DMA, FIR IRQ)
+ * This sets up the basic SMSC parameters
+ * (FIR port, SIR port, FIR DMA, FIR IRQ)
* through the chip configuration port.
*/
-static int __init preconfigure_smsc_chip(struct smsc_ircc_subsystem_configuration *conf)
+static int __init preconfigure_smsc_chip(struct
+ smsc_ircc_subsystem_configuration
+ *conf)
{
unsigned short iobase = conf->cfg_base;
unsigned char tmpbyte;
@@ -2416,7 +2443,9 @@ static int __init preconfigure_smsc_chip
outb(LPC47N227_CFGACCESSKEY, iobase); // enter configuration state
outb(SMSCSIOFLAT_DEVICEID_REG, iobase); // set for device ID
tmpbyte = inb(iobase +1); // Read device ID
- IRDA_DEBUG(0, "Detected Chip id: 0x%02x, setting up registers...\n",tmpbyte);
+ IRDA_DEBUG(0,
+ "Detected Chip id: 0x%02x, setting up registers...\n",
+ tmpbyte);
/* Disable UART1 and set up SIR I/O port */
outb(0x24, iobase); // select CR24 - UART1 base addr
@@ -2426,6 +2455,7 @@ static int __init preconfigure_smsc_chip
tmpbyte = inb(iobase + 1);
if (tmpbyte != (conf->sir_io >> 2) ) {
IRDA_WARNING("ERROR: could not configure SIR ioport.\n");
+ IRDA_WARNING("Try to supply ircc_cfg argument.\n");
return -ENXIO;
}
@@ -2461,7 +2491,8 @@ static int __init preconfigure_smsc_chip
outb(SMSCSIOFLAT_UARTMODE0C_REG, iobase); // CR0C - UART mode
tmpbyte = inb(iobase + 1);
- tmpbyte &= ~SMSCSIOFLAT_UART2MODE_MASK | SMSCSIOFLAT_UART2MODE_VAL_IRDA;
+ tmpbyte &= ~SMSCSIOFLAT_UART2MODE_MASK |
+ SMSCSIOFLAT_UART2MODE_VAL_IRDA;
outb(tmpbyte, iobase + 1); // enable IrDA (HPSIR) mode, high speed
outb(LPC47N227_APMBOOTDRIVE_REG, iobase); // CR07 - Auto Pwr Mgt/boot drive sel
@@ -2486,53 +2517,226 @@ static int __init preconfigure_smsc_chip
return 0;
}
-/* 82801CAM registers */
+/* 82801CAM generic registers */
#define VID 0x00
#define DID 0x02
-#define PIRQA_ROUT 0x60
+#define PIRQ_A_D_ROUT 0x60
+#define SIRQ_CNTL 0x64
+#define PIRQ_E_H_ROUT 0x68
#define PCI_DMA_C 0x90
+/* LPC-specific registers */
#define COM_DEC 0xe0
+#define GEN1_DEC 0xe4
#define LPC_EN 0xe6
#define GEN2_DEC 0xec
/*
- * Sets up the I/O range using the 82801CAM ISA bridge, 82801DBM LPC bridge or
- * Intel 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge. They all work the same way!
+ * Sets up the I/O range using the 82801CAM ISA bridge, 82801DBM LPC bridge
+ * or Intel 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge.
+ * They all work the same way!
*/
static int __init preconfigure_through_82801(struct pci_dev *dev,
- struct smsc_ircc_subsystem_configuration *conf)
+ struct
+ smsc_ircc_subsystem_configuration
+ *conf)
{
unsigned short tmpword;
- int ret;
+ unsigned char tmpbyte;
- IRDA_MESSAGE("Setting up the SMSC device via the 82801 controller.\n");
- pci_write_config_byte(dev, COM_DEC, 0x10);
+ IRDA_MESSAGE("Setting up Intel 82801 controller and SMSC device\n");
+ /*
+ * Select the range for the COMA COM port (SIR)
+ * Register COM_DEC:
+ * Bit 7: reserved
+ * Bit 6-4, COMB decode range
+ * Bit 3: reserved
+ * Bit 2-0, COMA decode range
+ *
+ * Decode ranges:
+ * 000 = 0x3f8-0x3ff (COM1)
+ * 001 = 0x2f8-0x2ff (COM2)
+ * 010 = 0x220-0x227
+ * 011 = 0x228-0x22f
+ * 100 = 0x238-0x23f
+ * 101 = 0x2e8-0x2ef (COM4)
+ * 110 = 0x338-0x33f
+ * 111 = 0x3e8-0x3ef (COM3)
+ */
+ pci_read_config_byte(dev, COM_DEC, &tmpbyte);
+ tmpbyte &= 0xf8; /* mask COMA bits */
+ switch(conf->sir_io) {
+ case 0x3f8:
+ tmpbyte |= 0x00;
+ break;
+ case 0x2f8:
+ tmpbyte |= 0x01;
+ break;
+ case 0x220:
+ tmpbyte |= 0x02;
+ break;
+ case 0x228:
+ tmpbyte |= 0x03;
+ break;
+ case 0x238:
+ tmpbyte |= 0x04;
+ break;
+ case 0x2e8:
+ tmpbyte |= 0x05;
+ break;
+ case 0x338:
+ tmpbyte |= 0x06;
+ break;
+ case 0x3e8:
+ tmpbyte |= 0x07;
+ break;
+ default:
+ tmpbyte |= 0x01; /* COM2 default */
+ }
+ IRDA_DEBUG(1, "COM_DEC (write): 0x%02x\n", tmpbyte);
+ pci_write_config_byte(dev, COM_DEC, tmpbyte);
- /* Enable LPC */
- pci_read_config_word(dev, LPC_EN, &tmpword); /* LPC_EN register */
- tmpword &= 0xfffd; /* mask bit 1 */
- tmpword |= 0x0001; /* set bit 0 : COMA addr range enable */
+ /* Enable Low Pin Count interface */
+ pci_read_config_word(dev, LPC_EN, &tmpword);
+ /* These seem to be set up at all times,
+ * just make sure it is properly set.
+ */
+ switch(conf->cfg_base) {
+ case 0x04e:
+ tmpword |= 0x2000;
+ break;
+ case 0x02e:
+ tmpword |= 0x1000;
+ break;
+ case 0x062:
+ tmpword |= 0x0800;
+ break;
+ case 0x060:
+ tmpword |= 0x0400;
+ break;
+ default:
+ IRDA_WARNING("Uncommon I/O base address: 0x%04x\n",
+ conf->cfg_base);
+ break;
+ }
+ tmpword &= 0xfffd; /* disable LPC COMB */
+ tmpword |= 0x0001; /* set bit 0 : enable LPC COMA addr range (GEN2) */
+ IRDA_DEBUG(1, "LPC_EN (write): 0x%04x\n", tmpword);
pci_write_config_word(dev, LPC_EN, tmpword);
- /* Setup DMA */
- pci_write_config_word(dev, PCI_DMA_C, 0xc0c0); /* LPC I/F DMA on, channel 3 -- rtm (?? PCI DMA ?) */
- pci_write_config_word(dev, GEN2_DEC, 0x131); /* LPC I/F 2nd decode range */
+ /*
+ * Configure LPC DMA channel
+ * PCI_DMA_C bits:
+ * Bit 15-14: DMA channel 7 select
+ * Bit 13-12: DMA channel 6 select
+ * Bit 11-10: DMA channel 5 select
+ * Bit 9-8: Reserved
+ * Bit 7-6: DMA channel 3 select
+ * Bit 5-4: DMA channel 2 select
+ * Bit 3-2: DMA channel 1 select
+ * Bit 1-0: DMA channel 0 select
+ * 00 = Reserved value
+ * 01 = PC/PCI DMA
+ * 10 = Reserved value
+ * 11 = LPC I/F DMA
+ */
+ pci_read_config_word(dev, PCI_DMA_C, &tmpword);
+ switch(conf->fir_dma) {
+ case 0x07:
+ tmpword |= 0xc000;
+ break;
+ case 0x06:
+ tmpword |= 0x3000;
+ break;
+ case 0x05:
+ tmpword |= 0x0c00;
+ break;
+ case 0x03:
+ tmpword |= 0x00c0;
+ break;
+ case 0x02:
+ tmpword |= 0x0030;
+ break;
+ case 0x01:
+ tmpword |= 0x000c;
+ break;
+ case 0x00:
+ tmpword |= 0x0003;
+ break;
+ default:
+ break; /* do not change settings */
+ }
+ IRDA_DEBUG(1, "PCI_DMA_C (write): 0x%04x\n", tmpword);
+ pci_write_config_word(dev, PCI_DMA_C, tmpword);
+
+ /*
+ * GEN2_DEC bits:
+ * Bit 15-4: Generic I/O range
+ * Bit 3-1: reserved (read as 0)
+ * Bit 0: enable GEN2 range on LPC I/F
+ */
+ tmpword = conf->fir_io & 0xfff8;
+ tmpword |= 0x0001;
+ IRDA_DEBUG(1, "GEN2_DEC (write): 0x%04x\n", tmpword);
+ pci_write_config_word(dev, GEN2_DEC, tmpword);
/* Pre-configure chip */
- ret = preconfigure_smsc_chip(conf);
+ return preconfigure_smsc_chip(conf);
+}
- /* Disable LPC */
- pci_read_config_word(dev, LPC_EN, &tmpword); /* LPC_EN register */
- tmpword &= 0xfffc; /* mask bit 1 and bit 0, COMA addr range disable */
- pci_write_config_word(dev, LPC_EN, tmpword);
- return ret;
+/*
+ * Pre-configure a certain port on the ALi 1533 bridge.
+ * This is based on reverse-engineering since ALi does not
+ * provide any data sheet for the 1533 chip.
+ */
+static void __init preconfigure_ali_port(struct pci_dev *dev,
+ unsigned short port)
+{
+ unsigned char reg;
+ /* These bits obviously control the different ports */
+ unsigned char mask;
+ unsigned char tmpbyte;
+
+ switch(port) {
+ case 0x0130:
+ case 0x0178:
+ reg = 0xb0;
+ mask = 0x80;
+ break;
+ case 0x03f8:
+ reg = 0xb4;
+ mask = 0x80;
+ break;
+ case 0x02f8:
+ reg = 0xb4;
+ mask = 0x30;
+ break;
+ case 0x02e8:
+ reg = 0xb4;
+ mask = 0x08;
+ break;
+ default:
+ IRDA_ERROR("Failed to configure unsupported port on ALi 1533 bridge: 0x%04x\n", port);
+ return;
+ }
+
+ pci_read_config_byte(dev, reg, &tmpbyte);
+ /* Turn on the right bits */
+ tmpbyte |= mask;
+ pci_write_config_byte(dev, reg, tmpbyte);
+ IRDA_MESSAGE("Activated ALi 1533 ISA bridge port 0x%04x.\n", port);
+ return;
}
static int __init preconfigure_through_ali(struct pci_dev *dev,
- struct smsc_ircc_subsystem_configuration *conf)
-{
- /* TODO: put in ALi 1533 configuration here. */
- IRDA_MESSAGE("SORRY: %s has an unsupported bridge controller (ALi): not pre-configured.\n", conf->name);
- return -ENODEV;
+ struct
+ smsc_ircc_subsystem_configuration
+ *conf)
+{
+ /* Configure the two ports on the ALi 1533 */
+ preconfigure_ali_port(dev, conf->sir_io);
+ preconfigure_ali_port(dev, conf->fir_io);
+
+ /* Pre-configure chip */
+ return preconfigure_smsc_chip(conf);
}
static int __init smsc_ircc_preconfigure_subsystems(unsigned short ircc_cfg,
@@ -2552,9 +2756,10 @@ static int __init smsc_ircc_preconfigure
struct smsc_ircc_subsystem_configuration *conf;
/*
- * Cache the subsystem vendor/device: some manufacturers fail to set
- * this for all components, so we save it in case there is just
- * 0x0000 0x0000 on the device we want to check.
+ * Cache the subsystem vendor/device:
+ * some manufacturers fail to set this for all components,
+ * so we save it in case there is just 0x0000 0x0000 on the
+ * device we want to check.
*/
if (dev->subsystem_vendor != 0x0000U) {
ss_vendor = dev->subsystem_vendor;
@@ -2564,13 +2769,20 @@ static int __init smsc_ircc_preconfigure
for( ; conf->subvendor; conf++) {
if(conf->vendor == dev->vendor &&
conf->device == dev->device &&
- conf->subvendor == ss_vendor && /* Sometimes these are cached values */
- (conf->subdevice == ss_device || conf->subdevice == 0xffff)) {
- struct smsc_ircc_subsystem_configuration tmpconf;
+ conf->subvendor == ss_vendor &&
+ /* Sometimes these are cached values */
+ (conf->subdevice == ss_device ||
+ conf->subdevice == 0xffff)) {
+ struct smsc_ircc_subsystem_configuration
+ tmpconf;
- memcpy(&tmpconf, conf, sizeof(struct smsc_ircc_subsystem_configuration));
+ memcpy(&tmpconf, conf,
+ sizeof(struct smsc_ircc_subsystem_configuration));
- /* Override the default values with anything passed in as parameter */
+ /*
+ * Override the default values with anything
+ * passed in as parameter
+ */
if (ircc_cfg != 0)
tmpconf.cfg_base = ircc_cfg;
if (ircc_fir != 0)
^ permalink raw reply related
* [PATCH] IrDA: irda-usb, unregister netdev when patch upload fails
From: Samuel Ortiz @ 2006-04-14 10:16 UTC (permalink / raw)
To: ext David S. Miller; +Cc: IrDA users, Jean Tourrilhes, netdev
Hi David,
In the STIR421x case, when the firmware upload fails, we need to unregister_netdev. Otherwise we hit a BUG on free_netdev(), if sysfs is enabled.
Signed-off-by: Samuel Ortiz <samuel.ortiz@nokia.com>
diff --git a/drivers/net/irda/irda-usb.c b/drivers/net/irda/irda-usb.c
index 606243d..96bdb73 100644
--- a/drivers/net/irda/irda-usb.c
+++ b/drivers/net/irda/irda-usb.c
@@ -1815,14 +1815,14 @@ static int irda_usb_probe(struct usb_int
self->needspatch = (ret < 0);
if (ret < 0) {
printk("patch_device failed\n");
- goto err_out_4;
+ goto err_out_5;
}
/* replace IrDA class descriptor with what patched device is now reporting */
irda_desc = irda_usb_find_class_desc (self->usbintf);
if (irda_desc == NULL) {
ret = -ENODEV;
- goto err_out_4;
+ goto err_out_5;
}
if (self->irda_desc)
kfree (self->irda_desc);
@@ -1832,6 +1832,8 @@ static int irda_usb_probe(struct usb_int
return 0;
+err_out_5:
+ unregister_netdev(self->netdev);
err_out_4:
kfree(self->speed_buff);
err_out_3:
^ permalink raw reply related
* Re: [PATCH] bcm43xx: iw_priv_args names should be <16 characters
From: Mitchell Blank Jr @ 2006-04-14 10:33 UTC (permalink / raw)
To: Erik Mouw; +Cc: Stephen Hemminger, bcm43xx-dev, netdev, torvalds
In-Reply-To: <20060414093503.GF20839@harddisk-recovery.com>
Erik Mouw wrote:
> On Thu, Apr 13, 2006 at 10:29:19AM -0700, Stephen Hemminger wrote:
> > Shouldn't compiler have gagged on this?
>
> Apparently not. At least the compiler I use doesn't warn about it (gcc
> version 3.3.5 (Debian 1:3.3.5-13)).
>
> Linus, this might be be something for sparse to check:
>
> struct mystruct {
> char name[16];
> };
>
> mystruct ms = { .name = "muchlongerthan16characters" };
If you actually try that example you'd see that gcc (even really old
versions) will warn you about that code.
What gcc WON'T warn about is if everything but the final '\0' fits in
the array.
So the code:
struct mystruct { char name[16]; };
struct mystruct exact_length = { .name = "0123456789abcdef" };
struct mystruct one_too_long = { .name = "0123456789abcdefg" };
Produces:
a.c:3: warning: initializer-string for array of chars is too long
a.c:3: warning: (near initialization for 'one_too_long.name')
I believe this is intentional and in line with the C specs. It's also
useful since it allows you to define macros like:
#define DECLARE_NON_TERMINATED_STRING(name, val) \
const name[sizeof(val "") - 1] = val;
Making sparse a bit stricter than gcc in this case might not be a bad idea,
though.
-Mitch
^ permalink raw reply
* Re: [PATCH] bcm43xx: iw_priv_args names should be <16 characters
From: Erik Mouw @ 2006-04-14 9:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: bcm43xx-dev, netdev, torvalds
In-Reply-To: <20060413102919.5e0bdb2e@localhost.localdomain>
On Thu, Apr 13, 2006 at 10:29:19AM -0700, Stephen Hemminger wrote:
> On Thu, 13 Apr 2006 15:02:27 +0200
> Erik Mouw <erik@harddisk-recovery.com> wrote:
>
> > The room for the names in bcm43xx_priv_wx_args[] are IFNAMSIZ long and
> > IFNAMSIZ is defined as 16, so the names in bcm43xx_priv_wx_args should
> > be 15 characters (16 including the trailing \0). This patch fixes that
> > for the "set_shortpreambl", "get_shortpreambl", "set_swencryption", and
> > "get_swencryption" private calls. Patch is against 2.6.17-rc1.
> >
> > Signed-off-by: Erik Mouw <erik@harddisk-recovery.com>
>
> Shouldn't compiler have gagged on this?
Apparently not. At least the compiler I use doesn't warn about it (gcc
version 3.3.5 (Debian 1:3.3.5-13)).
Linus, this might be be something for sparse to check:
struct mystruct {
char name[16];
};
mystruct ms = { .name = "muchlongerthan16characters" };
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Re: [stable] [PATCH 1/4] clip: run through Lindent
From: David S. Miller @ 2006-04-14 9:01 UTC (permalink / raw)
To: greg; +Cc: shemminger, chas, netdev, linux-atm-general, stable
In-Reply-To: <20060413224529.GA2476@kroah.com>
From: Greg KH <greg@kroah.com>
Date: Thu, 13 Apr 2006 15:45:29 -0700
> On Thu, Apr 13, 2006 at 03:22:24PM -0700, Stephen Hemminger wrote:
> > Run CLIP driver through Lindent script to fix formatting.
>
> That's well and good, but really not a -stable thing. In fact, I don't
> see any of these 4 patches being -stable material, do you?
Me neither.
Stephen please don't push patches into -stable until they've
been fully reviewed and integrated into Linus's tree first.
Please let me do my job as networking maintainer and let the
netdev list do it's job in reviewing your changes before they
go in.
Thanks.
^ permalink raw reply
* Re: [PATCH] ipw2100: wraps the debug module param within #ifdefs
From: Zhu Yi @ 2006-04-14 5:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, John W. Linville
In-Reply-To: <20060413103048.64f8d0f0@localhost.localdomain>
On Thu, 2006-04-13 at 10:30 -0700, Stephen Hemminger wrote:
> Please get rid of the debug config option. Make the debug code, default
> off and be low enough impact that everyone can ship with it.
This patch is exactly doing so. There won't be the debug module param if
CONFIG_IPW2200_DEBUG is not defined. Otherwise it could be used to set
different debug level, which helps a lot for the driver debuging.
Thanks,
-yi
^ permalink raw reply
* Re: [RFC PATCH] softmac: (v2) send WEXT assoc/disassoc events to userspace
From: Hans Fugal @ 2006-04-14 1:05 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, netdev, softmac-dev, David Woodhouse, Dan Williams,
bcm43xx-dev
In-Reply-To: <1144888334.4187.32.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]
With the patch, wpa_supplicant is able to work properly for WEP and
plaintext as tested with my bcm4306 (iBook), and the latest git.
However, and this may not be related, I still must issue an
ip link set up eth1
after loading the bcm43xx module but before starting wpa_supplicant or
it will not work.
--
Hans Fugal ; http://hans.fugal.net
There's nothing remarkable about it. All one has to do is hit the
right keys at the right time and the instrument plays itself.
-- Johann Sebastian Bach
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [RFC] Geographical/regulatory information for ieee80211
From: Larry Finger @ 2006-04-14 0:59 UTC (permalink / raw)
To: netdev, jeffl
I am planning on writing a new routine to be added to net/ieee80211/ieee80211_geo.c that will
populate an ieee80211_geo object given a country code. The new routine will eliminate the need for
each driver to do their own.
Finding the allowable channels, etc. for various countries has not been easy; however, Cisco
(http://www.cisco.com/en/US/products/ps6305/products_configuration_guide_chapter09186a008059c96f.html)
has what seems to be the most complete listing of country information. Neglecting any discussion of
maximum power, I have been able to arrange the countries into the following groups:
Group Countries b/g channels a channels
============================================================================
1 Austria 1-11 36, 40, 48, 52
2 Australia, Brazil, Canada 1-11 36, 40, 44, 48
Cyprus, Czech Republic, Estonia 52, 56, 60, 64
Hong Kong, Ireland, Lithuania, Latvia 149,153,157,161
New Zealand, Philippines, Poland
Slovenia, Slovak Republic
United States
3 Belgium, Israel 1-11 36, 40, 44, 48
52, 56, 60, 64
4 Israel Outdoors 5-13 36, 40, 44, 48
52, 56, 60, 64
5 Switzerland and Liechtenstein 1-11 36, 40, 44, 48
France, Hungary, United States Low
6 China, Republic of Korea (1) 1-13 149,153,157,161
7 Republic of Korea (2) 1-13 36, 40, 44, 48
52, 56, 60, 64
100,104,108,112
116,120,124
149,153,157,161
8 Germany, Denmark, Spain, Finland 1-11 36, 40, 44, 48
Great Britain, Iceland, Italy 52, 56, 60, 64
Luxembourg, Netherlands, Norway 104,108,112,116
Portugal, Sweden 120,124,128,132
140
9 Greece, India 1-11
10 Indonesia, Malaysia, Thailand 1-13
South Africa
11 Japan 1-14 (14 is b only) 36, 40, 44, 48
12 Japan High 1-14 (14 is b only) 36, 40, 44, 48
52, 56, 60, 64
13 Singapore 1-13 36, 40, 44, 48
52, 56, 60, 64
149,153,157,161
14 Taiwan 1-13 56, 60, 64
100,104
149,153,157,161
Any countries not listed above will be placed in group 9 with b/g channels of 1-11 and no valid "a"
channels.
Please tell me if I have (a) missed any countries, or (b) gotten them wrong. Once I have a
"netdev-list approved" set, I will do some coding. I have noticed that not all the ipw2200 codes
that are listed in Documentation/README.ipw2200 correspond to these groups. All of the differences
are in the valid "a" channels.
Thanks to Jeff Liebermann (jeffl@comix.santa-cruz.ca.us) for helping me find some of the
geographical/regulatory info on the Web.
Larry
^ permalink raw reply
* Re: [patch 1/3] softmac: return -EAGAIN from getscan while scanning
From: Jean Tourrilhes @ 2006-04-14 0:01 UTC (permalink / raw)
To: Stephen Hemminger, netdev
Stephen Hemminger wrote :
>
> Sounds like you want a message interface like netlink, not ioctl's.
We have the message interface (through a Wireless Events,
since WE-14). However, netlink is highly undesirable in embedded space
for bloat reason.
Jean
^ 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