* Re: pcnet32 devices with incorrect trident vendor ID
From: Bill Nottingham @ 2006-01-12 21:22 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Daniel Drake, Jon Mason, mulix, linux-kernel, netdev, linux-pci
In-Reply-To: <20060112210559.GL19769@parisc-linux.org>
Matthew Wilcox (matthew@wil.cx) said:
> On Thu, Jan 12, 2006 at 01:57:14PM -0700, Matthew Wilcox wrote:
> > On Thu, Jan 12, 2006 at 08:49:42PM +0000, Daniel Drake wrote:
> > > interesting:
> > >
> > > http://forums.gentoo.org/viewtopic-t-420013-highlight-trident.html
> > >
> > > The user saw the correct vendor ID (AMD) in 2.4, but when upgrading to
> > > 2.6, it changed to Trident.
> >
> > It looks to me like there used to be a quirk that knew about this bug
> > and fixed it.
> >
> > The reason I say this is that the lspci -x dumps are the same -- both
> > featuring the wrong vendor ID. Want to dig through 2.4 and look for
> > this quirk?
>
> Oh -- found it. It's still in 2.6:
>
> static void
> fixup_broken_pcnet32(struct pci_dev* dev)
> {
> if ((dev->class>>8 == PCI_CLASS_NETWORK_ETHERNET)) {
> dev->vendor = PCI_VENDOR_ID_AMD;
> pci_write_config_word(dev, PCI_VENDOR_ID, PCI_VENDOR_ID_AMD);
> }
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TRIDENT, PCI_ANY_ID,
> fixup_broken_pcnet32);
>
> Wonder why it isn't working now ... someone with a PPC box needs to check
> (a) whether this function is being called and (b) if it is called, why
> it's not doing what it's supposed to.
I remember looking at this a while back. I think the corrected information
is only being propagated to the 'vendor' file, and the write_config_word
isn't actually updating the 'config' entry in sysfs.
If you remove the "#if 0" from lib/sysfs.c in pciutils, it should
start reporting the corrected value in base lspci, etc.
Bill
^ permalink raw reply
* Re: pcnet32 devices with incorrect trident vendor ID
From: Bill Nottingham @ 2006-01-12 21:24 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Daniel Drake, Jon Mason, mulix, linux-kernel, netdev, linux-pci
In-Reply-To: <20060112212205.GA28395@devserv.devel.redhat.com>
Bill Nottingham (notting@redhat.com) said:
> I remember looking at this a while back. I think the corrected information
> is only being propagated to the 'vendor' file, and the write_config_word
> isn't actually updating the 'config' entry in sysfs.
Ah, here's an example from the box I remember working on this on
(without the libpci change):
root@pseries 0000:00:0c.0]# pwd
/sys/bus/pci/devices/0000:00:0c.0
[root@pseries 0000:00:0c.0]# lspci | grep 0c.0
00:0c.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26)
[root@pseries 0000:00:0c.0]# lspci -n | grep 0c.0
00:0c.0 Class 0200: 1023:2000 (rev 26)
[root@pseries 0000:00:0c.0]# cat vendor
0x1022
[root@pseries 0000:00:0c.0]# cat device
0x2000
[root@pseries 0000:00:0c.0]# od -x config
0000000 2310 0020 4701 8002 2600 0002 0048 0000
0000020 01f0 ff00 0070 21c3 0000 0000 0000 0000
0000040 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 10c3 0000 0000 0000 0000 1101 06ff
0000100 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400
Note that the config space is different than the vendor file. This
was with 2.6.9-ish, I don't have the box around any more to confirm
with something more recent.
Bill
^ permalink raw reply
* Re: [patch] ipw2100: support WEXT-18 enc_capa v3
From: Jeff Garzik @ 2006-01-12 21:38 UTC (permalink / raw)
To: Dan Williams; +Cc: jketreno, netdev, ipw2100-devel
In-Reply-To: <1136822098.7941.13.camel@dhcp83-115.boston.redhat.com>
Dan Williams wrote:
> Hi,
>
> This patch allows ipw2100 driver to advertise the WPA-related encryption
> options that it does really support. It's necessary to work correctly
> with NetworkManager and other programs that actually check driver & card
> capabilities.
>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
content OK, but:
[jgarzik@pretzel netdev-2.6]$ git-applymbox /g/tmp/mbox ~/info/signoff.txt
1 patch(es) to process.
Applying 'ipw2100: support WEXT-18 enc_capa v3'
error: patch failed: drivers/net/wireless/ipw2100.c:7236
error: drivers/net/wireless/ipw2100.c: patch does not apply
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: 2.6.15-mm3
From: Andrew Morton @ 2006-01-12 21:58 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-kernel, netdev
In-Reply-To: <200601122205.04714.rjw@sisk.pl>
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> Hi,
>
> On Wednesday, 11 January 2006 13:21, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15/2.6.15-mm3/
>
> I got that on system shutdown (x86-64, 1 CPU):
Thanks. ipv6 died. I think shemminger had a recent problem with ipv6 too?
I don't think there were any core networking changes in -mm3 which weren't
in linus-at-that-time.
> Unable to handle kernel NULL pointer dereference at 00000000000001b4 RIP:
> <ffffffff881cba51>{:ipv6:ip6_xmit+593}
> PGD 2441f067 PUD 231b1067 PMD 0
> Oops: 0000 [1] PREEMPT
> CPU 0
> Modules linked in: ipt_LOG ipt_limit ipt_pkttype ipt_state ipt_REJECT iptable_mangle iptable_nat iptable_filter ip6table_mangle ip_nat_ftp
> ip_nat ip_conntrack_ftp ip_conntrack ip_tables ip6table_filter ip6_tables ipv6 usbserial thermal processor fan button battery ac snd_pcm_os
> s snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc af_packet pcmcia firmware_class yen
> ta_socket rsrc_nonstatic pcmcia_core usbhid ehci_hcd ohci_hcd sk98lin evdev joydev sg st sr_mod sd_mod scsi_mod ide_cd cdrom dm_mod parport
> _pc lp parport
> Pid: 18912, comm: kcminit Not tainted 2.6.15-mm3 #25
> RIP: 0010:[<ffffffff881cba51>] <ffffffff881cba51>{:ipv6:ip6_xmit+593}
> RSP: 0018:ffffffff80489cc8 EFLAGS: 00010246
> RAX: ffff810029a47658 RBX: ffff810029a47658 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: ffffffff80489d50 RDI: ffff810001f33e00
> RBP: ffffffff80489d28 R08: 0000000000000000 R09: 0000000000000080
> R10: ffff8100201a9f5c R11: ffffffff80489d40 R12: ffff810001f33dd8
> R13: 0000000000000000 R14: ffffffff80489d38 R15: 0000000000000014
> FS: 00002aaaae769de0(0000) GS:ffffffff80515000(0000) knlGS:000000005617d560
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00000000000001b4 CR3: 00000000249eb000 CR4: 00000000000006e0
> Process kcminit (pid: 18912, threadinfo ffff8100233ca000, task ffff810028afa090)
> Stack: ffff810029a476a0 ffff8100201a9e60 0000000000000000 00000000881cb324
> ffff810029a47658 ffffffff80489d40 0600000180489d48 ffff810029a476a0
> ffffffff80489d40 ffff810001f33e00
> Call Trace: <IRQ> <ffffffff881e9aad>{:ipv6:tcp_v6_send_reset+525}
> <ffffffff80361dd8>{inet6_lookup_listener+264} <ffffffff881ec8e2>{:ipv6:tcp_v6_rcv+1842}
> <ffffffff881ccd48>{:ipv6:ip6_input+568} <ffffffff881cd14f>{:ipv6:ipv6_rcv+527}
> <ffffffff8030283b>{netif_receive_skb+635} <ffffffff80302939>{process_backlog+153}
> <ffffffff803014c3>{net_rx_action+179} <ffffffff80135f10>{__do_softirq+80}
> <ffffffff8010fd12>{call_softirq+30} <EOI> <ffffffff801116e5>{do_softirq+53}
> <ffffffff801361b2>{local_bh_enable+114} <ffffffff80302fc7>{dev_queue_xmit+583}
> <ffffffff8030971f>{neigh_resolve_output+639} <ffffffff881cbf82>{:ipv6:ip6_output2+562}
> <ffffffff881c9d40>{:ipv6:dst_output+0} <ffffffff881cc7cd>{:ipv6:ip6_output+2045}
> <ffffffff881cbaeb>{:ipv6:ip6_xmit+747} <ffffffff881f0f21>{:ipv6:inet6_csk_xmit+769}
> <ffffffff803357ff>{tcp_transmit_skb+1743} <ffffffff802fe4ff>{__alloc_skb+127}
> <ffffffff80335e43>{tcp_connect+723} <ffffffff881eba49>{:ipv6:tcp_v6_connect+1529}
> <ffffffff80148d33>{__mutex_init+83} <ffffffff803652d8>{_spin_unlock_bh+24}
> <ffffffff8034871f>{inet_stream_connect+207} <ffffffff803652d8>{_spin_unlock_bh+24}
> <ffffffff802fa369>{lock_sock+201} <ffffffff803652d8>{_spin_unlock_bh+24}
> <ffffffff80180b0a>{fget+170} <ffffffff802f92ac>{sys_connect+140}
> <ffffffff802f8022>{sys_setsockopt+162} <ffffffff8010ec9e>{system_call+126}
>
>
> Code: 41 8b 95 b4 01 00 00 89 90 98 00 00 00 48 8b 45 a8 8b 58 40
> RIP <ffffffff881cba51>{:ipv6:ip6_xmit+593} RSP <ffffffff80489cc8>
> CR2: 00000000000001b4
> <0>Kernel panic - not syncing: Aiee, killing interrupt handler!
> <4>atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
> atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
> atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
> atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
>
> and so on forever.
>
> Greetings,
> Rafael
^ permalink raw reply
* Re: 2.6.15-mm3
From: Patrick McHardy @ 2006-01-12 22:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: Rafael J. Wysocki, linux-kernel, netdev
In-Reply-To: <20060112135839.2e74d8a8.akpm@osdl.org>
Andrew Morton wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
>>Hi,
>>
>>On Wednesday, 11 January 2006 13:21, Andrew Morton wrote:
>>
>>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15/2.6.15-mm3/
>>
>>I got that on system shutdown (x86-64, 1 CPU):
>
>
> Thanks. ipv6 died. I think shemminger had a recent problem with ipv6 too?
>
> I don't think there were any core networking changes in -mm3 which weren't
> in linus-at-that-time.
>
>
>>Unable to handle kernel NULL pointer dereference at 00000000000001b4 RIP:
>><ffffffff881cba51>{:ipv6:ip6_xmit+593}
That crash is already fixed in Linus' latest tree by this patch:
tree 3d4ce288b86cb2845d79c6adec9e254054bb0e02
parent a7768097557be91d0d4c37e8f2e38cd126c4cdf9
author David Woodhouse <dwmw2@infradead.org> Thu, 12 Jan 2006 07:53:04 -0800
committer David S. Miller <davem@sunset.davemloft.net> Thu, 12 Jan 2006
08:32:13 -0800
[IPV6]: Avoid calling ip6_xmit() with NULL sk
The ip6_xmit() function now assumes that its sk argument is non-NULL,
which isn't currently true when TCPv6 code is sending RST or ACK
packets. This fixes that code to use a socket of its own for sending
such packets, as TCPv4 does. (Thanks Andi for the pointer).
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [git patches] 2.6.x net driver updates
From: Jeff Garzik @ 2006-01-12 22:13 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: netdev, linux-kernel
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following updates:
drivers/net/bonding/bond_alb.c | 4
drivers/net/bonding/bonding.h | 4
drivers/net/e100.c | 32 +++++
drivers/net/gianfar.c | 6 -
drivers/net/gianfar_mii.c | 5
drivers/net/phy/mdio_bus.c | 2
drivers/net/phy/phy.c | 2
drivers/net/tulip/uli526x.c | 6 -
drivers/net/via-velocity.c | 2
drivers/net/wireless/Kconfig | 2
drivers/net/wireless/atmel.c | 227 ++++++++++++++++++++++++++++++++++++++++-
include/linux/fsl_devices.h | 6 -
include/linux/phy.h | 3
include/net/ieee80211.h | 6 -
14 files changed, 281 insertions(+), 26 deletions(-)
Dan Williams:
wireless/atmel: add IWENCODEEXT, IWAUTH, and association event support
dann frazier:
CONFIG_AIRO needs CONFIG_CRYPTO
Eric Sesterhenn / snakebyte:
replace MODULE_PARM in tulip/uli526x.c
Jay Vosburgh:
bonding: UPDATED hash-table corruption in bond_alb.c
Johannes Berg:
fix wrong comments in ieee80211.h
John W. Linville:
via-velocity: use NETIF_F_IP_CSUM (hardware only support IPv4)
Kumar Gala:
gfar: fix compile error
gianfar mii: Use proper resource for MII memory region
phy: Added a macro to represent the string format used to match a phy device
gianfar: Use new PHY_ID_FMT macro
ODonnell, Michael:
corruption during e100 MDI register access
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index 854ddfb..f2a6318 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -169,9 +169,9 @@ static void tlb_clear_slave(struct bondi
index = next_index;
}
- _unlock_tx_hashtbl(bond);
-
tlb_init_slave(slave);
+
+ _unlock_tx_hashtbl(bond);
}
/* Must be called before starting the monitor timer */
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index f20bb85..3dd78d0 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -22,8 +22,8 @@
#include "bond_3ad.h"
#include "bond_alb.h"
-#define DRV_VERSION "3.0.0"
-#define DRV_RELDATE "November 8, 2005"
+#define DRV_VERSION "3.0.1"
+#define DRV_RELDATE "January 9, 2006"
#define DRV_NAME "bonding"
#define DRV_DESCRIPTION "Ethernet Channel Bonding Driver"
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 22cd045..23de226 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -132,6 +132,10 @@
* TODO:
* o several entry points race with dev->close
* o check for tx-no-resources/stop Q races with tx clean/wake Q
+ *
+ * FIXES:
+ * 2005/12/02 - Michael O'Donnell <Michael.ODonnell at stratus dot com>
+ * - Stratus87247: protect MDI control register manipulations
*/
#include <linux/config.h>
@@ -578,6 +582,7 @@ struct nic {
u16 leds;
u16 eeprom_wc;
u16 eeprom[256];
+ spinlock_t mdio_lock;
};
static inline void e100_write_flush(struct nic *nic)
@@ -876,15 +881,35 @@ static u16 mdio_ctrl(struct nic *nic, u3
{
u32 data_out = 0;
unsigned int i;
+ unsigned long flags;
+
+ /*
+ * Stratus87247: we shouldn't be writing the MDI control
+ * register until the Ready bit shows True. Also, since
+ * manipulation of the MDI control registers is a multi-step
+ * procedure it should be done under lock.
+ */
+ spin_lock_irqsave(&nic->mdio_lock, flags);
+ for (i = 100; i; --i) {
+ if (readl(&nic->csr->mdi_ctrl) & mdi_ready)
+ break;
+ udelay(20);
+ }
+ if (unlikely(!i)) {
+ printk("e100.mdio_ctrl(%s) won't go Ready\n",
+ nic->netdev->name );
+ spin_unlock_irqrestore(&nic->mdio_lock, flags);
+ return 0; /* No way to indicate timeout error */
+ }
writel((reg << 16) | (addr << 21) | dir | data, &nic->csr->mdi_ctrl);
- for(i = 0; i < 100; i++) {
+ for (i = 0; i < 100; i++) {
udelay(20);
- if((data_out = readl(&nic->csr->mdi_ctrl)) & mdi_ready)
+ if ((data_out = readl(&nic->csr->mdi_ctrl)) & mdi_ready)
break;
}
-
+ spin_unlock_irqrestore(&nic->mdio_lock, flags);
DPRINTK(HW, DEBUG,
"%s:addr=%d, reg=%d, data_in=0x%04X, data_out=0x%04X\n",
dir == mdi_read ? "READ" : "WRITE", addr, reg, data, data_out);
@@ -2562,6 +2587,7 @@ static int __devinit e100_probe(struct p
/* locks must be initialized before calling hw_reset */
spin_lock_init(&nic->cb_lock);
spin_lock_init(&nic->cmd_lock);
+ spin_lock_init(&nic->mdio_lock);
/* Reset the device before pci_set_master() in case device is in some
* funky state and has an interrupt pending - hint: we don't have the
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 146f951..0c18dbd 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -84,6 +84,7 @@
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/udp.h>
+#include <linux/in.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -398,12 +399,15 @@ static int init_phy(struct net_device *d
priv->einfo->device_flags & FSL_GIANFAR_DEV_HAS_GIGABIT ?
SUPPORTED_1000baseT_Full : 0;
struct phy_device *phydev;
+ char phy_id[BUS_ID_SIZE];
priv->oldlink = 0;
priv->oldspeed = 0;
priv->oldduplex = -1;
- phydev = phy_connect(dev, priv->einfo->bus_id, &adjust_link, 0);
+ snprintf(phy_id, BUS_ID_SIZE, PHY_ID_FMT, priv->einfo->bus_id, priv->einfo->phy_id);
+
+ phydev = phy_connect(dev, phy_id, &adjust_link, 0);
if (IS_ERR(phydev)) {
printk(KERN_ERR "%s: Could not attach to PHY\n", dev->name);
diff --git a/drivers/net/gianfar_mii.c b/drivers/net/gianfar_mii.c
index 04a462c..74e52fc 100644
--- a/drivers/net/gianfar_mii.c
+++ b/drivers/net/gianfar_mii.c
@@ -128,6 +128,7 @@ int gfar_mdio_probe(struct device *dev)
struct gianfar_mdio_data *pdata;
struct gfar_mii *regs;
struct mii_bus *new_bus;
+ struct resource *r;
int err = 0;
if (NULL == dev)
@@ -151,8 +152,10 @@ int gfar_mdio_probe(struct device *dev)
return -ENODEV;
}
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
/* Set the PHY base address */
- regs = (struct gfar_mii *) ioremap(pdata->paddr,
+ regs = (struct gfar_mii *) ioremap(r->start,
sizeof (struct gfar_mii));
if (NULL == regs) {
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 02940c0..459443b 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -81,7 +81,7 @@ int mdiobus_register(struct mii_bus *bus
phydev->dev.parent = bus->dev;
phydev->dev.bus = &mdio_bus_type;
- sprintf(phydev->dev.bus_id, "phy%d:%d", bus->id, i);
+ snprintf(phydev->dev.bus_id, BUS_ID_SIZE, PHY_ID_FMT, bus->id, i);
phydev->bus = bus;
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index b8686e4..1474b7c 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -42,7 +42,7 @@
*/
void phy_print_status(struct phy_device *phydev)
{
- pr_info("%s: Link is %s", phydev->dev.bus_id,
+ pr_info("PHY: %s - Link is %s", phydev->dev.bus_id,
phydev->link ? "Up" : "Down");
if (phydev->link)
printk(" - %d/%s", phydev->speed,
diff --git a/drivers/net/tulip/uli526x.c b/drivers/net/tulip/uli526x.c
index 1a43163..9839816 100644
--- a/drivers/net/tulip/uli526x.c
+++ b/drivers/net/tulip/uli526x.c
@@ -1689,9 +1689,9 @@ MODULE_AUTHOR("Peer Chen, peer.chen@uli.
MODULE_DESCRIPTION("ULi M5261/M5263 fast ethernet driver");
MODULE_LICENSE("GPL");
-MODULE_PARM(debug, "i");
-MODULE_PARM(mode, "i");
-MODULE_PARM(cr6set, "i");
+module_param(debug, int, 0644);
+module_param(mode, int, 0);
+module_param(cr6set, int, 0);
MODULE_PARM_DESC(debug, "ULi M5261/M5263 enable debugging (0-1)");
MODULE_PARM_DESC(mode, "ULi M5261/M5263: Bit 0: 10/100Mbps, bit 2: duplex, bit 8: HomePNA");
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index 82c6b75..c2d5907 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -791,7 +791,7 @@ static int __devinit velocity_found1(str
#endif
if (vptr->flags & VELOCITY_FLAGS_TX_CSUM) {
- dev->features |= NETIF_F_HW_CSUM;
+ dev->features |= NETIF_F_IP_CSUM;
}
ret = register_netdev(dev);
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 24f7967..c1a6e69 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -243,7 +243,7 @@ config IPW2200_DEBUG
config AIRO
tristate "Cisco/Aironet 34X/35X/4500/4800 ISA and PCI cards"
- depends on NET_RADIO && ISA_DMA_API && (PCI || BROKEN)
+ depends on NET_RADIO && ISA_DMA_API && CRYPTO && (PCI || BROKEN)
---help---
This is the standard Linux driver to support Cisco/Aironet ISA and
PCI 802.11 wireless cards.
diff --git a/drivers/net/wireless/atmel.c b/drivers/net/wireless/atmel.c
index e4729dd..f0ccfef 100644
--- a/drivers/net/wireless/atmel.c
+++ b/drivers/net/wireless/atmel.c
@@ -1407,6 +1407,17 @@ static int atmel_close(struct net_device
{
struct atmel_private *priv = netdev_priv(dev);
+ /* Send event to userspace that we are disassociating */
+ if (priv->station_state == STATION_STATE_READY) {
+ union iwreq_data wrqu;
+
+ wrqu.data.length = 0;
+ wrqu.data.flags = 0;
+ wrqu.ap_addr.sa_family = ARPHRD_ETHER;
+ memset(wrqu.ap_addr.sa_data, 0, ETH_ALEN);
+ wireless_send_event(priv->dev, SIOCGIWAP, &wrqu, NULL);
+ }
+
atmel_enter_state(priv, STATION_STATE_DOWN);
if (priv->bus_type == BUS_TYPE_PCCARD)
@@ -1780,10 +1791,10 @@ static int atmel_set_encode(struct net_d
priv->wep_is_on = 1;
priv->exclude_unencrypted = 1;
if (priv->wep_key_len[index] > 5) {
- priv->pairwise_cipher_suite = CIPHER_SUITE_WEP_64;
+ priv->pairwise_cipher_suite = CIPHER_SUITE_WEP_128;
priv->encryption_level = 2;
} else {
- priv->pairwise_cipher_suite = CIPHER_SUITE_WEP_128;
+ priv->pairwise_cipher_suite = CIPHER_SUITE_WEP_64;
priv->encryption_level = 1;
}
}
@@ -1853,6 +1864,181 @@ static int atmel_get_encode(struct net_d
return 0;
}
+static int atmel_set_encodeext(struct net_device *dev,
+ struct iw_request_info *info,
+ union iwreq_data *wrqu,
+ char *extra)
+{
+ struct atmel_private *priv = netdev_priv(dev);
+ struct iw_point *encoding = &wrqu->encoding;
+ struct iw_encode_ext *ext = (struct iw_encode_ext *)extra;
+ int idx, key_len;
+
+ /* Determine and validate the key index */
+ idx = encoding->flags & IW_ENCODE_INDEX;
+ if (idx) {
+ if (idx < 1 || idx > WEP_KEYS)
+ return -EINVAL;
+ idx--;
+ } else
+ idx = priv->default_key;
+
+ if ((encoding->flags & IW_ENCODE_DISABLED) ||
+ ext->alg == IW_ENCODE_ALG_NONE) {
+ priv->wep_is_on = 0;
+ priv->encryption_level = 0;
+ priv->pairwise_cipher_suite = CIPHER_SUITE_NONE;
+ }
+
+ if (ext->ext_flags & IW_ENCODE_EXT_SET_TX_KEY)
+ priv->default_key = idx;
+
+ /* Set the requested key */
+ switch (ext->alg) {
+ case IW_ENCODE_ALG_NONE:
+ break;
+ case IW_ENCODE_ALG_WEP:
+ if (ext->key_len > 5) {
+ priv->wep_key_len[idx] = 13;
+ priv->pairwise_cipher_suite = CIPHER_SUITE_WEP_128;
+ priv->encryption_level = 2;
+ } else if (ext->key_len > 0) {
+ priv->wep_key_len[idx] = 5;
+ priv->pairwise_cipher_suite = CIPHER_SUITE_WEP_64;
+ priv->encryption_level = 1;
+ } else {
+ return -EINVAL;
+ }
+ priv->wep_is_on = 1;
+ memset(priv->wep_keys[idx], 0, 13);
+ key_len = min ((int)ext->key_len, priv->wep_key_len[idx]);
+ memcpy(priv->wep_keys[idx], ext->key, key_len);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return -EINPROGRESS;
+}
+
+static int atmel_get_encodeext(struct net_device *dev,
+ struct iw_request_info *info,
+ union iwreq_data *wrqu,
+ char *extra)
+{
+ struct atmel_private *priv = netdev_priv(dev);
+ struct iw_point *encoding = &wrqu->encoding;
+ struct iw_encode_ext *ext = (struct iw_encode_ext *)extra;
+ int idx, max_key_len;
+
+ max_key_len = encoding->length - sizeof(*ext);
+ if (max_key_len < 0)
+ return -EINVAL;
+
+ idx = encoding->flags & IW_ENCODE_INDEX;
+ if (idx) {
+ if (idx < 1 || idx > WEP_KEYS)
+ return -EINVAL;
+ idx--;
+ } else
+ idx = priv->default_key;
+
+ encoding->flags = idx + 1;
+ memset(ext, 0, sizeof(*ext));
+
+ if (!priv->wep_is_on) {
+ ext->alg = IW_ENCODE_ALG_NONE;
+ ext->key_len = 0;
+ encoding->flags |= IW_ENCODE_DISABLED;
+ } else {
+ if (priv->encryption_level > 0)
+ ext->alg = IW_ENCODE_ALG_WEP;
+ else
+ return -EINVAL;
+
+ ext->key_len = priv->wep_key_len[idx];
+ memcpy(ext->key, priv->wep_keys[idx], ext->key_len);
+ encoding->flags |= IW_ENCODE_ENABLED;
+ }
+
+ return 0;
+}
+
+static int atmel_set_auth(struct net_device *dev,
+ struct iw_request_info *info,
+ union iwreq_data *wrqu, char *extra)
+{
+ struct atmel_private *priv = netdev_priv(dev);
+ struct iw_param *param = &wrqu->param;
+
+ switch (param->flags & IW_AUTH_INDEX) {
+ case IW_AUTH_WPA_VERSION:
+ case IW_AUTH_CIPHER_PAIRWISE:
+ case IW_AUTH_CIPHER_GROUP:
+ case IW_AUTH_KEY_MGMT:
+ case IW_AUTH_RX_UNENCRYPTED_EAPOL:
+ case IW_AUTH_PRIVACY_INVOKED:
+ /*
+ * atmel does not use these parameters
+ */
+ break;
+
+ case IW_AUTH_DROP_UNENCRYPTED:
+ priv->exclude_unencrypted = param->value ? 1 : 0;
+ break;
+
+ case IW_AUTH_80211_AUTH_ALG: {
+ if (param->value & IW_AUTH_ALG_SHARED_KEY) {
+ priv->exclude_unencrypted = 1;
+ } else if (param->value & IW_AUTH_ALG_OPEN_SYSTEM) {
+ priv->exclude_unencrypted = 0;
+ } else
+ return -EINVAL;
+ break;
+ }
+
+ case IW_AUTH_WPA_ENABLED:
+ /* Silently accept disable of WPA */
+ if (param->value > 0)
+ return -EOPNOTSUPP;
+ break;
+
+ default:
+ return -EOPNOTSUPP;
+ }
+ return -EINPROGRESS;
+}
+
+static int atmel_get_auth(struct net_device *dev,
+ struct iw_request_info *info,
+ union iwreq_data *wrqu, char *extra)
+{
+ struct atmel_private *priv = netdev_priv(dev);
+ struct iw_param *param = &wrqu->param;
+
+ switch (param->flags & IW_AUTH_INDEX) {
+ case IW_AUTH_DROP_UNENCRYPTED:
+ param->value = priv->exclude_unencrypted;
+ break;
+
+ case IW_AUTH_80211_AUTH_ALG:
+ if (priv->exclude_unencrypted == 1)
+ param->value = IW_AUTH_ALG_SHARED_KEY;
+ else
+ param->value = IW_AUTH_ALG_OPEN_SYSTEM;
+ break;
+
+ case IW_AUTH_WPA_ENABLED:
+ param->value = 0;
+ break;
+
+ default:
+ return -EOPNOTSUPP;
+ }
+ return 0;
+}
+
+
static int atmel_get_name(struct net_device *dev,
struct iw_request_info *info,
char *cwrq,
@@ -2289,13 +2475,15 @@ static int atmel_set_wap(struct net_devi
{
struct atmel_private *priv = netdev_priv(dev);
int i;
- static const u8 bcast[] = { 255, 255, 255, 255, 255, 255 };
+ static const u8 any[] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };
+ static const u8 off[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
unsigned long flags;
if (awrq->sa_family != ARPHRD_ETHER)
return -EINVAL;
- if (memcmp(bcast, awrq->sa_data, 6) == 0) {
+ if (!memcmp(any, awrq->sa_data, 6) ||
+ !memcmp(off, awrq->sa_data, 6)) {
del_timer_sync(&priv->management_timer);
spin_lock_irqsave(&priv->irqlock, flags);
atmel_scan(priv, 1);
@@ -2378,6 +2566,15 @@ static const iw_handler atmel_handler[]
(iw_handler) atmel_get_encode, /* SIOCGIWENCODE */
(iw_handler) atmel_set_power, /* SIOCSIWPOWER */
(iw_handler) atmel_get_power, /* SIOCGIWPOWER */
+ (iw_handler) NULL, /* -- hole -- */
+ (iw_handler) NULL, /* -- hole -- */
+ (iw_handler) NULL, /* SIOCSIWGENIE */
+ (iw_handler) NULL, /* SIOCGIWGENIE */
+ (iw_handler) atmel_set_auth, /* SIOCSIWAUTH */
+ (iw_handler) atmel_get_auth, /* SIOCGIWAUTH */
+ (iw_handler) atmel_set_encodeext, /* SIOCSIWENCODEEXT */
+ (iw_handler) atmel_get_encodeext, /* SIOCGIWENCODEEXT */
+ (iw_handler) NULL, /* SIOCSIWPMKSA */
};
static const iw_handler atmel_private_handler[] =
@@ -2924,6 +3121,8 @@ static void associate(struct atmel_priva
u16 ass_id = le16_to_cpu(ass_resp->ass_id);
u16 rates_len = ass_resp->length > 4 ? 4 : ass_resp->length;
+ union iwreq_data wrqu;
+
if (frame_len < 8 + rates_len)
return;
@@ -2954,6 +3153,14 @@ static void associate(struct atmel_priva
priv->station_is_associated = 1;
priv->station_was_associated = 1;
atmel_enter_state(priv, STATION_STATE_READY);
+
+ /* Send association event to userspace */
+ wrqu.data.length = 0;
+ wrqu.data.flags = 0;
+ memcpy(wrqu.ap_addr.sa_data, priv->CurrentBSSID, ETH_ALEN);
+ wrqu.ap_addr.sa_family = ARPHRD_ETHER;
+ wireless_send_event(priv->dev, SIOCGIWAP, &wrqu, NULL);
+
return;
}
@@ -3632,6 +3839,7 @@ static int reset_atmel_card(struct net_d
struct atmel_private *priv = netdev_priv(dev);
u8 configuration;
+ int old_state = priv->station_state;
/* data to add to the firmware names, in priority order
this implemenents firmware versioning */
@@ -3792,6 +4000,17 @@ static int reset_atmel_card(struct net_d
else
build_wep_mib(priv);
+ if (old_state == STATION_STATE_READY)
+ {
+ union iwreq_data wrqu;
+
+ wrqu.data.length = 0;
+ wrqu.data.flags = 0;
+ wrqu.ap_addr.sa_family = ARPHRD_ETHER;
+ memset(wrqu.ap_addr.sa_data, 0, ETH_ALEN);
+ wireless_send_event(priv->dev, SIOCGIWAP, &wrqu, NULL);
+ }
+
return 1;
}
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 934aa9b..a9f1cfd 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -50,14 +50,12 @@ struct gianfar_platform_data {
/* board specific information */
u32 board_flags;
- const char *bus_id;
+ u32 bus_id;
+ u32 phy_id;
u8 mac_addr[6];
};
struct gianfar_mdio_data {
- /* device specific information */
- u32 paddr;
-
/* board specific information */
int irq[32];
};
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 92a9696..331521a 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -53,6 +53,9 @@
#define PHY_MAX_ADDR 32
+/* Used when trying to connect to a specific phy (mii bus id:phy device id) */
+#define PHY_ID_FMT "%x:%02x"
+
/* The Bus class for PHYs. Devices which provide access to
* PHYs should register using this structure */
struct mii_bus {
diff --git a/include/net/ieee80211.h b/include/net/ieee80211.h
index cde2f4f..df05f46 100644
--- a/include/net/ieee80211.h
+++ b/include/net/ieee80211.h
@@ -363,8 +363,9 @@ enum ieee80211_reasoncode {
#define IEEE80211_OFDM_SHIFT_MASK_A 4
/* NOTE: This data is for statistical purposes; not all hardware provides this
- * information for frames received. Not setting these will not cause
- * any adverse affects. */
+ * information for frames received.
+ * For ieee80211_rx_mgt, you need to set at least the 'len' parameter.
+ */
struct ieee80211_rx_stats {
u32 mac_time;
s8 rssi;
@@ -1088,6 +1089,7 @@ extern int ieee80211_tx_frame(struct iee
/* ieee80211_rx.c */
extern int ieee80211_rx(struct ieee80211_device *ieee, struct sk_buff *skb,
struct ieee80211_rx_stats *rx_stats);
+/* make sure to set stats->len */
extern void ieee80211_rx_mgt(struct ieee80211_device *ieee,
struct ieee80211_hdr_4addr *header,
struct ieee80211_rx_stats *stats);
^ permalink raw reply related
* [PATCH] Spelling fix in IPW2100 and IPW2200 Kconfig entries
From: Alex Shepard @ 2006-01-12 22:15 UTC (permalink / raw)
To: jketreno, yi.zhu; +Cc: linux-kernel, netdev, trivial
s/remvoed/removed/
Signed-off-by: Alex Shepard <ashepard@u.washington.edu>
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -160,7 +160,7 @@ config IPW2100
<http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html>.
If you want to compile the driver as a module ( = code which can be
- inserted in and remvoed from the running kernel whenever you want),
+ inserted in and removed from the running kernel whenever you want),
say M here and read <file:Documentation/modules.txt>. The module
will be called ipw2100.ko.
@@ -213,7 +213,7 @@ config IPW2200
<http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html>.
If you want to compile the driver as a module ( = code which can be
- inserted in and remvoed from the running kernel whenever you want),
+ inserted in and removed from the running kernel whenever you want),
say M here and read <file:Documentation/modules.txt>. The module
will be called ipw2200.ko.
^ permalink raw reply
* Re: pcnet32 devices with incorrect trident vendor ID
From: Don Fry @ 2006-01-12 22:23 UTC (permalink / raw)
To: Matthew Wilcox, Daniel Drake, Jon Mason, mulix, linux-kernel,
netdev, linux-pci
In-Reply-To: <20060112212435.GB28395@devserv.devel.redhat.com>
There are just a few differences between the 2.4 (1.30h) version of
pcnet32.c and the 2.6 (1.30j) version, as I have tried to keep them
as similar as possible.
The driver was changed in February 2004 to recognize the incorrect
vendor ID so that the ppc workaround was no longer required, and so that
the cards would work in non ppc systems. From the driver perspective
the ppc workaround could be deleted.
On my systems lspci shows all the devices with the correct name whether
it is ppc or x86.
PPC:
donf@elm3b48:/usr/src> lspci | grep Ethernet
0000:01:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 54)
0000:21:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 0d)
0000:62:00.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0000:62:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0000:62:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0000:62:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0001:21:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 44)
0001:31:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0001:41:01.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
0001:61:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c978 [HomePNA] (rev 51)
donf@elm3b48:/usr/src>
x86:
[donf@elm3b45 linux-2.6.14-git11]$ lspci | grep Ethernet
00:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 54)
00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
02:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 16)
02:06.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 36)
05:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
05:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 54)
05:04.0 Ethernet controller: Advanced Micro Devices [AMD] 79c978 [HomePNA] (rev 51)
[donf@elm3b45 linux-2.6.14-git11]$
On Thu, Jan 12, 2006 at 04:24:35PM -0500, Bill Nottingham wrote:
> Bill Nottingham (notting@redhat.com) said:
> > I remember looking at this a while back. I think the corrected information
> > is only being propagated to the 'vendor' file, and the write_config_word
> > isn't actually updating the 'config' entry in sysfs.
>
> Ah, here's an example from the box I remember working on this on
> (without the libpci change):
>
> root@pseries 0000:00:0c.0]# pwd
> /sys/bus/pci/devices/0000:00:0c.0
> [root@pseries 0000:00:0c.0]# lspci | grep 0c.0
> 00:0c.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26)
> [root@pseries 0000:00:0c.0]# lspci -n | grep 0c.0
> 00:0c.0 Class 0200: 1023:2000 (rev 26)
> [root@pseries 0000:00:0c.0]# cat vendor
> 0x1022
> [root@pseries 0000:00:0c.0]# cat device
> 0x2000
> [root@pseries 0000:00:0c.0]# od -x config
> 0000000 2310 0020 4701 8002 2600 0002 0048 0000
> 0000020 01f0 ff00 0070 21c3 0000 0000 0000 0000
> 0000040 0000 0000 0000 0000 0000 0000 0000 0000
> 0000060 0000 10c3 0000 0000 0000 0000 1101 06ff
> 0000100 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0000400
>
> Note that the config space is different than the vendor file. This
> was with 2.6.9-ish, I don't have the box around any more to confirm
> with something more recent.
>
> Bill
--
Don Fry
brazilnut@us.ibm.com
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Linus Torvalds @ 2006-01-12 22:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, netdev, linux-kernel
In-Reply-To: <20060112221322.GA25470@havoc.gtf.org>
On Thu, 12 Jan 2006, Jeff Garzik wrote:
>
> dann frazier:
> CONFIG_AIRO needs CONFIG_CRYPTO
I think this is done wrong.
It should "select CRYPTO" rather than "depends on CRYPTO".
Otherwise people won't see it just because they don't have crypto enabled,
which is not very user-friendly.
Btw, why are these casts there? Either the functions are of the right
type, or they aren't. In neither case is the cast correct.
I do realize that there are comments in <net/iw_handler.h> that says that
you should do the cast, but that's no excuse for crap or stupid code.
If it's an issue of trying to make greppable code, why not have
just the comment?
> @@ -2378,6 +2566,15 @@ static const iw_handler atmel_handler[]
> (iw_handler) atmel_get_encode, /* SIOCGIWENCODE */
> (iw_handler) atmel_set_power, /* SIOCSIWPOWER */
> (iw_handler) atmel_get_power, /* SIOCGIWPOWER */
> + (iw_handler) NULL, /* -- hole -- */
> + (iw_handler) NULL, /* -- hole -- */
...
Hmm?
Linus
^ permalink raw reply
* Re: pcnet32 devices with incorrect trident vendor ID
From: Jon Mason @ 2006-01-12 22:33 UTC (permalink / raw)
To: Don Fry
Cc: Matthew Wilcox, Daniel Drake, Jon Mason, mulix, linux-kernel,
netdev, linux-pci
In-Reply-To: <20060112222320.GA19668@us.ibm.com>
On Thu, Jan 12, 2006 at 02:23:20PM -0800, Don Fry wrote:
> There are just a few differences between the 2.4 (1.30h) version of
> pcnet32.c and the 2.6 (1.30j) version, as I have tried to keep them
> as similar as possible.
>
> The driver was changed in February 2004 to recognize the incorrect
> vendor ID so that the ppc workaround was no longer required, and so that
> the cards would work in non ppc systems. From the driver perspective
> the ppc workaround could be deleted.
>
> On my systems lspci shows all the devices with the correct name whether
> it is ppc or x86.
Funny, I get the following on my opteron system:
# lspci | grep Ethernet
0000:03:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02)
0000:0e:01.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26)
>
> PPC:
> donf@elm3b48:/usr/src> lspci | grep Ethernet
> 0000:01:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 54)
> 0000:21:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 0d)
> 0000:62:00.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0000:62:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0000:62:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0000:62:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0001:21:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 44)
> 0001:31:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0001:41:01.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
> 0001:61:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c978 [HomePNA] (rev 51)
> donf@elm3b48:/usr/src>
>
> x86:
> [donf@elm3b45 linux-2.6.14-git11]$ lspci | grep Ethernet
> 00:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 54)
> 00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
> 02:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 16)
> 02:06.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 36)
> 05:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
> 05:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 54)
> 05:04.0 Ethernet controller: Advanced Micro Devices [AMD] 79c978 [HomePNA] (rev 51)
> [donf@elm3b45 linux-2.6.14-git11]$
>
> On Thu, Jan 12, 2006 at 04:24:35PM -0500, Bill Nottingham wrote:
> > Bill Nottingham (notting@redhat.com) said:
> > > I remember looking at this a while back. I think the corrected information
> > > is only being propagated to the 'vendor' file, and the write_config_word
> > > isn't actually updating the 'config' entry in sysfs.
> >
> > Ah, here's an example from the box I remember working on this on
> > (without the libpci change):
> >
> > root@pseries 0000:00:0c.0]# pwd
> > /sys/bus/pci/devices/0000:00:0c.0
> > [root@pseries 0000:00:0c.0]# lspci | grep 0c.0
> > 00:0c.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26)
> > [root@pseries 0000:00:0c.0]# lspci -n | grep 0c.0
> > 00:0c.0 Class 0200: 1023:2000 (rev 26)
> > [root@pseries 0000:00:0c.0]# cat vendor
> > 0x1022
> > [root@pseries 0000:00:0c.0]# cat device
> > 0x2000
> > [root@pseries 0000:00:0c.0]# od -x config
> > 0000000 2310 0020 4701 8002 2600 0002 0048 0000
> > 0000020 01f0 ff00 0070 21c3 0000 0000 0000 0000
> > 0000040 0000 0000 0000 0000 0000 0000 0000 0000
> > 0000060 0000 10c3 0000 0000 0000 0000 1101 06ff
> > 0000100 0000 0000 0000 0000 0000 0000 0000 0000
> > *
> > 0000400
> >
> > Note that the config space is different than the vendor file. This
> > was with 2.6.9-ish, I don't have the box around any more to confirm
> > with something more recent.
> >
> > Bill
> --
> Don Fry
> brazilnut@us.ibm.com
>
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Andrew Morton @ 2006-01-12 22:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: jgarzik, netdev, linux-kernel, Roman Zippel
In-Reply-To: <Pine.LNX.4.64.0601121423120.3535@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
> On Thu, 12 Jan 2006, Jeff Garzik wrote:
> >
> > dann frazier:
> > CONFIG_AIRO needs CONFIG_CRYPTO
>
> I think this is done wrong.
>
> It should "select CRYPTO" rather than "depends on CRYPTO".
>
> Otherwise people won't see it just because they don't have crypto enabled,
> which is not very user-friendly.
>
Yes, I think that's much more Aunt-Nellie-friendly, but Roman considers it
abuse of the Kconfig system in ways which I never completely understood?
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Jeff Garzik @ 2006-01-12 22:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0601121423120.3535@g5.osdl.org>
On Thu, Jan 12, 2006 at 02:30:19PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 12 Jan 2006, Jeff Garzik wrote:
> >
> > dann frazier:
> > CONFIG_AIRO needs CONFIG_CRYPTO
>
> I think this is done wrong.
>
> It should "select CRYPTO" rather than "depends on CRYPTO".
OK
> Otherwise people won't see it just because they don't have crypto enabled,
> which is not very user-friendly.
>
> Btw, why are these casts there? Either the functions are of the right
> type, or they aren't. In neither case is the cast correct.
>
> I do realize that there are comments in <net/iw_handler.h> that says that
> you should do the cast, but that's no excuse for crap or stupid code.
>
> If it's an issue of trying to make greppable code, why not have
> just the comment?
>
> > @@ -2378,6 +2566,15 @@ static const iw_handler atmel_handler[]
> > (iw_handler) atmel_get_encode, /* SIOCGIWENCODE */
> > (iw_handler) atmel_set_power, /* SIOCSIWPOWER */
> > (iw_handler) atmel_get_power, /* SIOCGIWPOWER */
> > + (iw_handler) NULL, /* -- hole -- */
> > + (iw_handler) NULL, /* -- hole -- */
> ...
>
> Hmm?
Welcome to the awful wireless driver API. This type crapola is a key
thing that needs changing, but its not the only thing. There are also
some nasty wireless APIs which do casts based on variable (passed-in)
struct offsets...
This needs to change to a type-safe thingy like struct ethtool_ops, but
the above is what we were lumped with.
Jeff
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Linus Torvalds @ 2006-01-12 22:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: jgarzik, netdev, linux-kernel, Roman Zippel
In-Reply-To: <20060112143938.5cf7d6a5.akpm@osdl.org>
On Thu, 12 Jan 2006, Andrew Morton wrote:
>
> Yes, I think that's much more Aunt-Nellie-friendly, but Roman considers it
> abuse of the Kconfig system in ways which I never completely understood?
Hmm. If Roman dislikes it, he must dislike the fact that we already do
exactly this for a ton of different things. There's something like 2000+
"select" statements in the kernel Kconfig tree, and just grepping for
"select.*CRYPTO" gets 52 hits..
So this isn't new..
Linus
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Adrian Bunk @ 2006-01-12 23:14 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linus Torvalds, Andrew Morton, netdev, linux-kernel
In-Reply-To: <20060112224227.GA26888@havoc.gtf.org>
On Thu, Jan 12, 2006 at 05:42:27PM -0500, Jeff Garzik wrote:
> On Thu, Jan 12, 2006 at 02:30:19PM -0800, Linus Torvalds wrote:
> >
> >
> > On Thu, 12 Jan 2006, Jeff Garzik wrote:
> > >
> > > dann frazier:
> > > CONFIG_AIRO needs CONFIG_CRYPTO
> >
> > I think this is done wrong.
> >
> > It should "select CRYPTO" rather than "depends on CRYPTO".
>
> OK
>...
What was wrong with my patch [1] that did not only this, but also fixes
the same bug with AIRO_CS and removes all the #ifdef's for the
non-compiling CRYPTO=n case from the driver?
> Jeff
cu
Adrian
[1] http://lkml.org/lkml/2006/1/10/328
--
"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: [PATCH 2/4 - 2.6.15]net: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Shaun Pereira @ 2006-01-13 3:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnaldo Carvalho de Melo, Andi Kleen, linux-kenel, x25 maintainer,
David S. Miller, netdev, SP
In-Reply-To: <200601121924.02747.arnd@arndb.de>
Hi Arnd
Thank you for reviewing that bit of code.
I had a look at compat_sys_gettimeofday and sys32_gettimeofday codes.
They seem to work in a similar way, casting a pointer to the structure
from user space to a compat_timeval type.
But to make sure I have tested the routine by forcing the sk-
>sk_stamp.tv_sec value to 0 in the x25_module ( for testing purposes
only, as it is initialised to -1). Now when
I make a 32 bit userspace SIOCGSTAMP ioctl to the 64 bit kernel I should
get the current time back in user space. This seems to work, the ioctl
returns the system time (just after TEST6:)
So I have left the patch as is for now. However if necessary to use
the element-by-element __put_user routine as in put_tv32, then I can
make the change, just let me know.
Lastly, if anyone following this mail can help with adding this into the
next release, that would be really helpful. We are building a network
management application on linux for a telco and while they have
the support of the SuSE's and Redhat's, any patches accepted by the
kernel community makes a difference, besides saving us from building
custom patches. (BTW, the application used to run on HP-UX, we are now
porting it to linux).
Many Thanks
Shaun
------------------------------
ghostview:/home/spereira/x25_32/src/func_tests/server # uname -a
Linux ghostview 2.6.15-smp #9 SMP Fri Jan 13 12:43:27 EST 2006 x86_64
x86_64 x86_64 GNU/Linux
ghostview:/home/spereira/x25_32/src/func_tests/server # file server
server: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped
ghostview:/home/spereira/x25_32/src/func_tests/server # ./server
usage: server <local X.121 address> <interface name>
ghostview:/home/spereira/x25_32/src/func_tests/server # ./server
05052384500000 x25tap0
TEST1: create socket : passed
TEST2: bind socket : passed
TEST3: set subscription: passed
TEST4: set facilities: passed
**************
Window size in = 2
Window size out = 2
Packet size in = 7
Packet size out = 7
Reverse flag = 00
Throughput = DD
**************
TEST5: set call user data on listen passed
cud[ 0 ] = 02
cud[ 1 ] = 03
TEST6: set matchlength on listen socket handle passed
The time stamp is Fri Jan 13 13:37:17 2006
TEST7: listen on socket: passed
Waiting for X25 packets
-----------------------------------------------------------
On Thu, 2006-01-12 at 19:24 +0000, Arnd Bergmann wrote:
> On Thursday 12 January 2006 06:02, Shaun Pereira wrote:
> > +int compat_sock_get_timestamp(struct sock *sk, struct timeval __user
> > *userstamp)
> > +{
> > + struct compat_timeval __user *ctv;
> > + ctv = (struct compat_timeval __user*) userstamp;
> > + if(!sock_flag(sk, SOCK_TIMESTAMP))
> > + sock_enable_timestamp(sk);
> > + if(sk->sk_stamp.tv_sec == -1)
> > + return -ENOENT;
> > + if(sk->sk_stamp.tv_sec == 0)
> > + do_gettimeofday(&sk->sk_stamp);
> > + return copy_to_user(ctv, &sk->sk_stamp, sizeof(struct
> > compat_timeval)) ?
> > + -EFAULT : 0;
> > +}
>
> This looks wrong, you're not doing any conversion here.
> You cannot just copy sk_stamp to ctv, they are not compatible.
> See compat_sys_gettimeofday on how to copy a struct timeval
> correctly.
>
> The other patches look good.
>
> Arnd <><
^ permalink raw reply
* Re: Tx packet fragmentation?
From: Denis Vlasenko @ 2006-01-13 11:00 UTC (permalink / raw)
To: acx100-devel, netdev; +Cc: Andreas Mohr
In-Reply-To: <20060112165853.GA17789@rhlx01.fht-esslingen.de>
On Thursday 12 January 2006 18:58, Andreas Mohr wrote:
> Hi,
>
> I'd like to ask some things about packet fragmentation (you remember I wanted
> to work on this due to my very bad link quality?). I'm asking now since I
> will probably have some time during the weekend to work on it.
>
> Problem is that fragmenting packets requires allocating several tx descriptors
> in a row, then preparing and sending the data packet piecemeal via those
> various descriptors in acx_l_tx_data().
> Do you have any recommendations on how to do it?
> (the split between acx_l_alloc_tx() and acx_l_tx_data() is a bit problematic)
Basically you want to modify this part of acx_i_start_xmit():
tx = acx_l_alloc_tx(priv);
if (unlikely(!tx)) {
printk_ratelimited("%s: start_xmit: txdesc ring is full, "
"dropping tx\n", dev->name);
txresult = NOT_OK;
goto end;
}
txbuf = acx_l_get_txbuf(priv, tx);
if (unlikely(!txbuf)) {
/* Card was removed */
txresult = NOT_OK;
acx_l_dealloc_tx(priv, tx);
goto end;
}
len = acx_ether_to_txbuf(priv, txbuf, skb);
if (unlikely(len < 0)) {
/* Error in packet conversion */
txresult = NOT_OK;
acx_l_dealloc_tx(priv, tx);
goto end;
}
acx_l_tx_data(priv, tx, len);
As seen here, current code produces and tx'es just one wlan packet.
Possible adaptation:
struct frag_vec {
int len;
void *tx;
void *txbuf;
};
/* allocates and fills from 1 to N wlan fragments */
int acx_ether_to_frags(wlandevice_t *priv, const struct sk_buff *skb, struct frag_vec *frag, int len);
acx_i_start_xmit():
struct frag_vec frag[N];
...
n = acx_ether_to_frags(priv, skb, frag, N);
if (n <= 0) {
/* Error in packet conversion */
txresult = NOT_OK;
goto end;
}
for(1..n)
acx_l_tx_data(priv, frag[i].tx, frag[i].len);
> Or should this be the job of the OS to care about fragmenting the packets
> to be sent? (then it would just call our data tx stuff multiple times itself
> anyway).
Yes, it must be done by softmac layer.
> And what about the multiple host txhostdescs that we (need to?) initialize
> in order to work around "bugs"?
It should not matter here, you won't even need to touch pci.c
except for maybe setting some FIRSTFRAG and/or MORE_FRAG bits
as appropriate.
> Are we sure that this is a bug of specific(???) cards or not simply a bug of
> certain firmware versions or even a bug in our driver? (maybe due to doing
> some things in weird ways that the firmware totally doesn't expect?).
I think firmware was debugged only to meet needs of Windows driver.
--
vda
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: [PATCH 2/4 - 2.6.15]net: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Arnd Bergmann @ 2006-01-13 11:46 UTC (permalink / raw)
To: spereira
Cc: Arnaldo Carvalho de Melo, Andi Kleen, linux-kenel, x25 maintainer,
David S. Miller, netdev, SP
In-Reply-To: <1137122079.5589.34.camel@spereira05.tusc.com.au>
On Friday 13 January 2006 03:14, Shaun Pereira wrote:
> Thank you for reviewing that bit of code.
> I had a look at compat_sys_gettimeofday and sys32_gettimeofday codes.
> They seem to work in a similar way, casting a pointer to the structure
> from user space to a compat_timeval type.
The part with the case is ok, except that you don't have to write
struct compat_timeval __user *ctv;
ctv = (struct compat_timeval __user*) userstamp;
Instead,
struct compat_timeval __user *ctv = userstamp;
is the more common way to write it. The result is the same, since
userstamp is a 'void __user *'.
> But to make sure I have tested the routine by forcing the sk-
> >sk_stamp.tv_sec value to 0 in the x25_module ( for testing purposes
> only, as it is initialised to -1). Now when
> I make a 32 bit userspace SIOCGSTAMP ioctl to the 64 bit kernel I should
> get the current time back in user space. This seems to work, the ioctl
> returns the system time (just after TEST6:)
>
> So I have left the patch as is for now. However if necessary to use
> the element-by-element __put_user routine as in put_tv32, then I can
> make the change, just let me know.
You need to to exactly that, yes. I'm not sure what exactly you have
tested, but the expected result of your code would be that you see
the sk_stamp.tv_sec value in the output, but not the tv_usec value.
On little-endian system like x86_64, that is not much of a difference
(less than a second) that you might miss in a test case, but on
big-endian, it would be fatal.
The layout of the structures on most systems is
64 bit LE 64 bit BE 32 bit
bytes 0-3 tv_sec low tv_sec high tv_sec low
bytes 4-7 tv_sec high tv_sec low tv_usec low
bytes 8-11 tv_usec low tv_usec high
bytes 12-15 tv_usec high tv_usec low
You code copies the first eight bytes of the 64 bit data structure
into the 32 bit data structure.
Arnd <><
^ permalink raw reply
* Re: WCONF, netlink based WE replacement.
From: Thomas Graf @ 2006-01-13 13:15 UTC (permalink / raw)
To: Michael Buesch; +Cc: linux-kernel, netdev
In-Reply-To: <200601121824.02892.mbuesch@freenet.de>
* Michael Buesch <mbuesch@freenet.de> 2006-01-12 18:24
> This is an attempt to rewrite the Wireless Extensions
> userspace API, using netlink sockets.
> There should also be a notification API, to inform
> userspace for changes (config changes, state changes, etc).
> It is not implemented, yet.
I'll only comment on the netlink bits and leave the rest to
others. I'd highly recommend the use of attributes instead
of fixed message structures to allow the interface to be
flexible to extensions while staying binary compatible.
Another idea might be to use the new generic netlink family
to make things a bit easier to use.
^ permalink raw reply
* [2.6 patch] schedule SHAPER for removal
From: Adrian Bunk @ 2006-01-13 14:13 UTC (permalink / raw)
To: Alan Cox; +Cc: Andi Kleen, David Woodhouse, jgarzik, netdev, linux-kernel
In-Reply-To: <1136944738.28616.0.camel@localhost.localdomain>
On Wed, Jan 11, 2006 at 01:58:58AM +0000, Alan Cox wrote:
> On Mer, 2006-01-11 at 01:53 +0100, Andi Kleen wrote:
> > shaper is completely obsolete and it's probably best to just remove
> > all references to it and the kernel driver too.
>
> I would agree with that but it nees to go through a proper obsolesence
> and obliteration cycle not just vanish.
Patch below.
cu
Adrian
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt.old 2006-01-13 15:02:15.000000000 +0100
+++ linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt 2006-01-13 15:06:19.000000000 +0100
@@ -164,0 +165,6 @@
+---------------------------
+
+What: Traffic Shaper (CONFIG_SHAPER)
+When: July 2006
+Why: obsoleted by the code in net/sched/
+Who: Adrian Bunk <bunk@stusta.de
--- linux-2.6.15-mm3-full/drivers/net/Kconfig.old 2006-01-13 15:06:34.000000000 +0100
+++ linux-2.6.15-mm3-full/drivers/net/Kconfig 2006-01-13 15:06:49.000000000 +0100
@@ -2663,7 +2663,7 @@
"SCSI generic support".
config SHAPER
- tristate "Traffic Shaper (EXPERIMENTAL)"
+ tristate "Traffic Shaper (OBSOLETE)"
depends on EXPERIMENTAL
---help---
The traffic shaper is a virtual network device that allows you to
^ permalink raw reply
* Re: WCONF, netlink based WE replacement.
From: Stephen Hemminger @ 2006-01-13 17:55 UTC (permalink / raw)
To: Michael Buesch; +Cc: linux-kernel, netdev
In-Reply-To: <200601121824.02892.mbuesch@freenet.de>
On Thu, 12 Jan 2006 18:24:02 +0100
Michael Buesch <mbuesch@freenet.de> wrote:
> This is an attempt to rewrite the Wireless Extensions
> userspace API, using netlink sockets.
> There should also be a notification API, to inform
> userspace for changes (config changes, state changes, etc).
> It is not implemented, yet.
>
> This is against the devicescape stack.
> This patch is not to be used, but only to be commented on. ;)
> Basically I would like comments on the API definition
> in wconf.h
>
1. You will need more documentation, eventually in Documentation directory.
2. Is there 1:1 relationship between ieee80211_device and net_device or
N net_devices per ieee80211_device?
3. Don't put a version number on the protocol messages. The way to
us netlink is to us Type Length Variable structures. And write the
code to ignore unknown types. Once you decide on a particular Type
then it has to be frozen for ABI compatibility. The version numbering
in the WE API is part of the problem
4. What about non-ieee80211 devices? With the growth of (mostly proprietary)
cell phone carrier wireless, you don't want to shut out that.
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Roman Zippel @ 2006-01-13 17:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, jgarzik, netdev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0601121444030.3535@g5.osdl.org>
Hi,
On Thu, 12 Jan 2006, Linus Torvalds wrote:
> > Yes, I think that's much more Aunt-Nellie-friendly, but Roman considers it
> > abuse of the Kconfig system in ways which I never completely understood?
>
> Hmm. If Roman dislikes it, he must dislike the fact that we already do
> exactly this for a ton of different things. There's something like 2000+
> "select" statements in the kernel Kconfig tree, and just grepping for
> "select.*CRYPTO" gets 52 hits..
The basic problem is that it overrides any other dependencies and it makes
easy to screw them up.
The basic rule should be to use select only to include library
functionality, which is mostly independent and has no other dependencies.
Selecting larger subsystem, which may require more configuration itself,
should be avoided.
bye, Roman
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Jens Axboe @ 2006-01-13 19:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, jgarzik, netdev, linux-kernel, Roman Zippel
In-Reply-To: <20060112143938.5cf7d6a5.akpm@osdl.org>
On Thu, Jan 12 2006, Andrew Morton wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > On Thu, 12 Jan 2006, Jeff Garzik wrote:
> > >
> > > dann frazier:
> > > CONFIG_AIRO needs CONFIG_CRYPTO
> >
> > I think this is done wrong.
> >
> > It should "select CRYPTO" rather than "depends on CRYPTO".
> >
> > Otherwise people won't see it just because they don't have crypto enabled,
> > which is not very user-friendly.
> >
>
> Yes, I think that's much more Aunt-Nellie-friendly, but Roman considers it
> abuse of the Kconfig system in ways which I never completely understood?
'select' is really cool as a concept, but when you can't figure out why
you cannot disable CONFIG_FOO because CONFIG_BAR selects it it's really
annoying. Would be nice to actually be able to see if another option has
selected this option.
--
Jens Axboe
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Sam Ravnborg @ 2006-01-13 19:28 UTC (permalink / raw)
To: Jens Axboe
Cc: Andrew Morton, Linus Torvalds, jgarzik, netdev, linux-kernel,
Roman Zippel
In-Reply-To: <20060113192316.GX3945@suse.de>
On Fri, Jan 13, 2006 at 08:23:16PM +0100, Jens Axboe wrote:
>
> 'select' is really cool as a concept, but when you can't figure out why
> you cannot disable CONFIG_FOO because CONFIG_BAR selects it it's really
> annoying. Would be nice to actually be able to see if another option has
> selected this option.
In menuconfig:
Typing '?' on CONFIG_HOTPLUG revealed:
Selected by: PCCARD || HOTPLUG_PCI && PCI && EXPERIMENTAL || FW_LOADER
Then use '/' to search for the CONFIG_ symbols to see where they are
defined.
Sam
^ permalink raw reply
* Re: [git patches] 2.6.x net driver updates
From: Jens Axboe @ 2006-01-13 19:36 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Andrew Morton, Linus Torvalds, jgarzik, netdev, linux-kernel,
Roman Zippel
In-Reply-To: <20060113192813.GA10560@mars.ravnborg.org>
On Fri, Jan 13 2006, Sam Ravnborg wrote:
> On Fri, Jan 13, 2006 at 08:23:16PM +0100, Jens Axboe wrote:
> >
> > 'select' is really cool as a concept, but when you can't figure out why
> > you cannot disable CONFIG_FOO because CONFIG_BAR selects it it's really
> > annoying. Would be nice to actually be able to see if another option has
> > selected this option.
>
> In menuconfig:
>
> Typing '?' on CONFIG_HOTPLUG revealed:
> Selected by: PCCARD || HOTPLUG_PCI && PCI && EXPERIMENTAL || FW_LOADER
>
> Then use '/' to search for the CONFIG_ symbols to see where they are
> defined.
Live and learn, thanks, didn't know you could do that!
--
Jens Axboe
^ permalink raw reply
* wireless: recap of current issues (intro)
From: John W. Linville @ 2006-01-13 21:26 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, Jiri Benc, Stefan Rompf, Mike Kershaw,
Krzysztof Halasa, Robert Hancock, Alistair John Strachan,
Dominik Brodowski, Denis Vlasenko, Danny van Dyk,
Stephen Hemminger, feyd, Chase Venters, Andreas Mohr,
Bas Vermeulen, Jean Tourrilhes, Daniel Drake, Ulrich Kunitz,
Phil Dibowitz, Simon Kelley, Michael Buesch, Marcel Holtmann,
Patrick McHardy, Ingo Oeser
In-Reply-To: <20060113195723.GB16166@tuxdriver.com>
My original post got eaten by the lists -- probably too big...
I'm reposting in sections. After this intro follow sections on
Configuration, Compatibility, Stack, Other Issues, and Actions.
Enjoy! :-)
---
WiFi-ers...
Here I am, still feeling "up to the challenge"... I have stopped
hyper-ventilating and the nervous vomiting is all over... :-)
Having accepted the wireless role, I wanted to review the discussions
prompted by Jeff's "State of the Union" message from a little over a
week ago. There is lots of good talent involved in these discussions,
and I believe a surprisingly high level of agreement (some of it
nearly violent!) amongst the players.
Below I have recapped what I saw as most of the important issues.
I have endorsed some of the ideas, mostly those which seem to have
broad agreement. I have also thrown-out a few ideas of my own.
Please do comment on all of them, as neither my summaries nor my
original ideas are likely to be without fault. :-)
I have primarily grouped the issues into configuration, compatibility,
and stack concerns. I also included an "other" group for a few other
concerns that I though were worth mentioning.
Finally, I have included an "actions" section to reveal some of my
near-term plans and some of what I am thinking about beyond that.
I would love to hear any comments you might have on these items
as well.
Thanks for taking the time to look this over. Creating this recap
has reinforced one thing: this is far too big for just a single person
(or even a small group) to tackle alone!
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ 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