* Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
From: Meelis Roos @ 2006-06-04 12:39 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Andrew Morton, bugme-daemon, netdev
In-Reply-To: <44804379.60808@trash.net>
> Please enable DEBUG_IP_FIREWALL_USER in net/netfilter/x_tables.c as well
> and retry. Results of the raw or mangle table would also be interesting
> because they contain a different number of built-in chains.
Sorry it took so long, I was away. Adding this define does not seem to
do much (table->private->number prints only):
On boot (1 nat rule):
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (1536 buckets, 12288 max) - 224 bytes per conntrack
translate_table: size 632
Finished chain 0
Finished chain 3
Finished chain 4
table->private->number = 4
t->private->number = 4
translate_table: size 800
Bad offset cba528d4
modprobe iptable_nat succeeded in manual modprobe.
modprobe iptable_filter:
translate_table: size 632
Bad offset cbbd910c
modprobe iptable_mangle:
translate_table: size 936
Bad offset cbbd80dc
modprobe iptable_raw:
translate_table: size 480
Bad offset cb8abd44
Retrying ifup and ifdown that tried to do iptables -D and iptables -I:
t->private->number = 4
t->private->number = 4
t->private->number = 4
translate_table: size 800
Bad offset cbbd80dc
t->private->number = 4
And retrying it more (succeeded this time):
t->private->number = 4
t->private->number = 4
translate_table: size 800
Finished chain 0
Finished chain 3
Finished chain 4
ip_tables: Translated table
do_replace: oldnum=4, initnum=4, newnum=5
t->private->number = 5
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: OLPC (One Laptop Per Child) Developer's program.
From: Anand Kumria @ 2006-06-04 13:17 UTC (permalink / raw)
To: netdev
In-Reply-To: <1149335345.5053.177.camel@pmac.infradead.org>
On Sat, 03 Jun 2006 12:49:05 +0100, David Woodhouse wrote:
> On Tue, 2006-05-30 at 17:42 -0400, Jim Gettys wrote:
>> As you know, we've said we were going to have a developer's program. You
>> can find more information, including how to apply for boards at:
>>
>> http://wiki.laptop.org/index.php/Developers_Program
>>
>> Note that these are bare PC prototype boards, not packaged machines.
>> Jim Gettys
>
> ObNetdev:
>
> One thing we really need is NAT-PT or an equivalent for allowing access
> to the Legacy Internet from IPv6-only hosts. As soon as I finish playing
> with JFFS2 improvements, I plan to start looking at that.
Wouldn't miredo mostly fit the bill? It won't get through Symmetric NATs
(by design) but those are supposed to be uncommon.
Cheers,
Anand
^ permalink raw reply
* PATCH SB1250 NAPI support
From: Tom Rix @ 2006-06-04 16:45 UTC (permalink / raw)
To: tbm, jgarzik, netdev, linux-mips, mark.e.mason, trix@specifix.com
In-Reply-To: <20060525133505.GH8746@deprecation.cyrius.com>
[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]
A while ago I submitted this patch for NAPI support for SB1250 / SB1480.
I have tested it again on the recent (6/3/06) linux-mips kernel.
Tom
Below is the original posting.
This patch adds NAPI support for the Broadcom Sibyte SB1xxx family. The
changes are limited to adding a new config key SBMAC_NAPI to the drivers/
net/Kconfig and by adding the poll op and interrupt support to drivers/
net/sb1250-mac.c.
This patch also has a fix to drivers/net/sb1250-mac.c, the dma descriptor
table ptr is allocated, aligned and the aligned ptr is freed. If the ptr
was not already aligned (usually is) then the free would not work of what
was returned by the kmalloc. A variable was added to store the unaligned
pointer so that it could be properly freed.
I have tested this patch on a BCM91250A-SWARM Pass 2 / An.
Mark Mason from Broadcom was very helpful and tested this patch on at
least a 1480.
Tom
On Thu, 25 May 2006 08:35:05 -0500, Martin Michlmayr <tbm@cyrius.com>
wrote:
> * Tom Rix <trix@specifix.com> [2006-05-25 08:06]:
>> I am busy now but will get to it sometime.
>> It will require retesting with the latest kernel source.
>> Is there a particular maintainer(s) that I should cc on this patch?
>
> jgarzik@pobox.com
>
> He just reminded people that the merge window for 2.6.18 will open
> soon (and that he's collecting patches for that already) so now would
> be an excellent time.
>
> Thanks.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
[-- Attachment #2: mips-sb1250-mac-NAPI-3.patch --]
[-- Type: application/octet-stream, Size: 10804 bytes --]
diff -rup a/drivers/net/Kconfig b/drivers/net/Kconfig
--- a/drivers/net/Kconfig 2006-03-09 04:25:38.000000000 -0600
+++ b/drivers/net/Kconfig 2006-03-09 05:30:48.000000000 -0600
@@ -2008,10 +2008,6 @@ config R8169_NAPI
If in doubt, say N.
-config NET_SB1250_MAC
- tristate "SB1250 Ethernet support"
- depends on SIBYTE_SB1xxx_SOC
-
config R8169_VLAN
bool "VLAN support"
depends on R8169 && VLAN_8021Q
@@ -2021,6 +2017,27 @@ config R8169_VLAN
If in doubt, say Y.
+config NET_SB1250_MAC
+ tristate "SB1250 Ethernet support"
+ depends on SIBYTE_SB1xxx_SOC
+
+config SBMAC_NAPI
+ bool "Use Rx Polling (NAPI) (EXPERIMENTAL)"
+ depends on NET_SB1250_MAC && EXPERIMENTAL
+ help
+ NAPI is a new driver API designed to reduce CPU and interrupt load
+ when the driver is receiving lots of packets from the card. It is
+ still somewhat experimental and thus not yet enabled by default.
+
+ If your estimated Rx load is 10kpps or more, or if the card will be
+ deployed on potentially unfriendly networks (e.g. in a firewall),
+ then say Y here.
+
+ See <file:Documentation/networking/NAPI_HOWTO.txt> for more
+ information.
+
+ If in doubt, say y.
+
config SIS190
tristate "SiS190/SiS191 gigabit ethernet support"
depends on PCI
diff -rup a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c
--- a/drivers/net/sb1250-mac.c 2006-03-09 04:25:41.000000000 -0600
+++ b/drivers/net/sb1250-mac.c 2006-03-09 05:30:52.000000000 -0600
@@ -209,6 +209,7 @@ typedef struct sbmacdma_s {
* This stuff is for maintenance of the ring
*/
+ sbdmadscr_t *sbdma_dscrtable_unaligned;
sbdmadscr_t *sbdma_dscrtable; /* base of descriptor table */
sbdmadscr_t *sbdma_dscrtable_end; /* end of descriptor table */
@@ -291,8 +292,8 @@ static int sbdma_add_rcvbuffer(sbmacdma_
static int sbdma_add_txbuffer(sbmacdma_t *d,struct sk_buff *m);
static void sbdma_emptyring(sbmacdma_t *d);
static void sbdma_fillring(sbmacdma_t *d);
-static void sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d);
-static void sbdma_tx_process(struct sbmac_softc *sc,sbmacdma_t *d);
+static int sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d, int poll);
+static void sbdma_tx_process(struct sbmac_softc *sc,sbmacdma_t *d, int poll);
static int sbmac_initctx(struct sbmac_softc *s);
static void sbmac_channel_start(struct sbmac_softc *s);
static void sbmac_channel_stop(struct sbmac_softc *s);
@@ -313,6 +314,10 @@ static struct net_device_stats *sbmac_ge
static void sbmac_set_rx_mode(struct net_device *dev);
static int sbmac_mii_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
static int sbmac_close(struct net_device *dev);
+#if defined (CONFIG_SBMAC_NAPI)
+static int sbmac_poll(struct net_device *poll_dev, int *budget);
+#endif
+
static int sbmac_mii_poll(struct sbmac_softc *s,int noisy);
static int sbmac_mii_probe(struct net_device *dev);
@@ -740,7 +745,7 @@ static void sbdma_initctx(sbmacdma_t *d,
d->sbdma_maxdescr = maxdescr;
- d->sbdma_dscrtable = (sbdmadscr_t *)
+ d->sbdma_dscrtable_unaligned = d->sbdma_dscrtable = (sbdmadscr_t *)
kmalloc((d->sbdma_maxdescr+1)*sizeof(sbdmadscr_t), GFP_KERNEL);
/*
@@ -782,7 +787,6 @@ static void sbdma_initctx(sbmacdma_t *d,
d->sbdma_int_timeout = 0;
}
#endif
-
}
/**********************************************************************
@@ -1150,13 +1154,14 @@ static void sbdma_fillring(sbmacdma_t *d
* nothing
********************************************************************* */
-static void sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d)
+static int sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d, int poll)
{
int curidx;
int hwidx;
sbdmadscr_t *dsc;
struct sk_buff *sb;
int len;
+ int work_done = 0;
for (;;) {
/*
@@ -1234,8 +1239,15 @@ static void sbdma_rx_process(struct sbma
sb->ip_summed = CHECKSUM_NONE;
}
}
-
+
+#if defined(CONFIG_SBMAC_NAPI)
+ if (0 == poll)
+ netif_rx(sb);
+ else
+ netif_receive_skb(sb);
+#else
netif_rx(sb);
+#endif
}
} else {
/*
@@ -1252,8 +1264,9 @@ static void sbdma_rx_process(struct sbma
*/
d->sbdma_remptr = SBDMA_NEXTBUF(d,sbdma_remptr);
-
+ work_done++;
}
+ return work_done;
}
@@ -1275,15 +1288,22 @@ static void sbdma_rx_process(struct sbma
* nothing
********************************************************************* */
-static void sbdma_tx_process(struct sbmac_softc *sc,sbmacdma_t *d)
+static void sbdma_tx_process(struct sbmac_softc *sc,sbmacdma_t *d, int poll)
{
int curidx;
int hwidx;
sbdmadscr_t *dsc;
struct sk_buff *sb;
unsigned long flags;
+ int packets_handled = 0;
spin_lock_irqsave(&(sc->sbm_lock), flags);
+
+ if (d->sbdma_remptr == d->sbdma_addptr)
+ goto end_unlock;
+
+ hwidx = (int) (((__raw_readq(d->sbdma_curdscr) & M_DMA_CURDSCR_ADDR) -
+ d->sbdma_dscrtable_phys) / sizeof(sbdmadscr_t));
for (;;) {
/*
@@ -1298,15 +1318,12 @@ static void sbdma_tx_process(struct sbma
*/
curidx = d->sbdma_remptr - d->sbdma_dscrtable;
- hwidx = (int) (((__raw_readq(d->sbdma_curdscr) & M_DMA_CURDSCR_ADDR) -
- d->sbdma_dscrtable_phys) / sizeof(sbdmadscr_t));
/*
* If they're the same, that means we've processed all
* of the descriptors up to (but not including) the one that
* the hardware is working on right now.
*/
-
if (curidx == hwidx)
break;
@@ -1337,6 +1354,7 @@ static void sbdma_tx_process(struct sbma
d->sbdma_remptr = SBDMA_NEXTBUF(d,sbdma_remptr);
+ packets_handled++;
}
/*
@@ -1344,15 +1362,15 @@ static void sbdma_tx_process(struct sbma
* Other drivers seem to do this when we reach a low
* watermark on the transmit queue.
*/
+
+ if (packets_handled)
+ netif_wake_queue(d->sbdma_eth->sbm_dev);
- netif_wake_queue(d->sbdma_eth->sbm_dev);
-
+ end_unlock:
spin_unlock_irqrestore(&(sc->sbm_lock), flags);
}
-
-
/**********************************************************************
* SBMAC_INITCTX(s)
*
@@ -1396,7 +1414,6 @@ static int sbmac_initctx(struct sbmac_so
* Initialize the DMA channels. Right now, only one per MAC is used
* Note: Only do this _once_, as it allocates memory from the kernel!
*/
-
sbdma_initctx(&(s->sbm_txdma),s,0,DMA_TX,SBMAC_MAX_TXDESCR);
sbdma_initctx(&(s->sbm_rxdma),s,0,DMA_RX,SBMAC_MAX_RXDESCR);
@@ -1420,9 +1437,9 @@ static int sbmac_initctx(struct sbmac_so
static void sbdma_uninitctx(struct sbmacdma_s *d)
{
- if (d->sbdma_dscrtable) {
- kfree(d->sbdma_dscrtable);
- d->sbdma_dscrtable = NULL;
+ if (d->sbdma_dscrtable_unaligned) {
+ kfree(d->sbdma_dscrtable_unaligned);
+ d->sbdma_dscrtable_unaligned = d->sbdma_dscrtable = NULL;
}
if (d->sbdma_ctxtable) {
@@ -1609,12 +1626,12 @@ static void sbmac_channel_start(struct s
#if defined(CONFIG_SIBYTE_BCM1x55) || defined(CONFIG_SIBYTE_BCM1x80)
__raw_writeq(M_MAC_RXDMA_EN0 |
- M_MAC_TXDMA_EN0, s->sbm_macenable);
+ M_MAC_TXDMA_EN0, s->sbm_macenable);
#elif defined(CONFIG_SIBYTE_SB1250) || defined(CONFIG_SIBYTE_BCM112X)
__raw_writeq(M_MAC_RXDMA_EN0 |
- M_MAC_TXDMA_EN0 |
- M_MAC_RX_ENABLE |
- M_MAC_TX_ENABLE, s->sbm_macenable);
+ M_MAC_TXDMA_EN0 |
+ M_MAC_RX_ENABLE |
+ M_MAC_TX_ENABLE, s->sbm_macenable);
#else
#error invalid SiByte MAC configuation
#endif
@@ -1624,15 +1641,15 @@ static void sbmac_channel_start(struct s
* Accept any TX interrupt and EOP count/timer RX interrupts on ch 0
*/
__raw_writeq(((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_TX_CH0) |
- ((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_RX_CH0), s->sbm_imr);
+ ((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_RX_CH0),
+ s->sbm_imr);
#else
/*
* Accept any kind of interrupt on TX and RX DMA channel 0
*/
__raw_writeq((M_MAC_INT_CHANNEL << S_MAC_TX_CH0) |
- (M_MAC_INT_CHANNEL << S_MAC_RX_CH0), s->sbm_imr);
+ (M_MAC_INT_CHANNEL << S_MAC_RX_CH0), s->sbm_imr);
#endif
-
/*
* Enable receiving unicasts and broadcasts
*/
@@ -2067,7 +2084,6 @@ static irqreturn_t sbmac_intr(int irq,vo
* Read the ISR (this clears the bits in the real
* register, except for counter addr)
*/
-
isr = __raw_readq(sc->sbm_isr) & ~M_MAC_COUNTER_ADDR;
if (isr == 0)
@@ -2079,13 +2095,31 @@ static irqreturn_t sbmac_intr(int irq,vo
* Transmits on channel 0
*/
+#if defined(CONFIG_SBMAC_NAPI)
if (isr & (M_MAC_INT_CHANNEL << S_MAC_TX_CH0)) {
- sbdma_tx_process(sc,&(sc->sbm_txdma));
+ sbdma_tx_process(sc,&(sc->sbm_txdma), 0);
}
/*
* Receives on channel 0
*/
+ if (isr & (M_MAC_INT_CHANNEL << S_MAC_RX_CH0)) {
+ if (netif_rx_schedule_prep(dev))
+ {
+ __raw_writeq(0, sc->sbm_imr);
+ __netif_rx_schedule(dev);
+ }
+ else
+ {
+ sbdma_rx_process(sc,&(sc->sbm_rxdma), 0);
+ }
+ }
+#else
+ /* Non NAPI */
+
+ if (isr & (M_MAC_INT_CHANNEL << S_MAC_TX_CH0)) {
+ sbdma_tx_process(sc,&(sc->sbm_txdma), 0);
+ }
/*
* It's important to test all the bits (or at least the
@@ -2105,8 +2139,9 @@ static irqreturn_t sbmac_intr(int irq,vo
if (isr & (M_MAC_INT_CHANNEL << S_MAC_RX_CH0)) {
- sbdma_rx_process(sc,&(sc->sbm_rxdma));
+ sbdma_rx_process(sc,&(sc->sbm_rxdma), 0);
}
+#endif
}
return IRQ_RETVAL(handled);
}
@@ -2405,7 +2440,10 @@ static int sbmac_init(struct net_device
dev->do_ioctl = sbmac_mii_ioctl;
dev->tx_timeout = sbmac_tx_timeout;
dev->watchdog_timeo = TX_TIMEOUT;
-
+#if defined(CONFIG_SBMAC_NAPI)
+ dev->poll = sbmac_poll;
+ dev->weight = 16;
+#endif
dev->change_mtu = sb1250_change_mtu;
/* This is needed for PASS2 for Rx H/W checksum feature */
@@ -2818,7 +2856,37 @@ static int sbmac_close(struct net_device
return 0;
}
+#if defined(CONFIG_SBMAC_NAPI)
+static int sbmac_poll(struct net_device *dev, int *budget)
+{
+ int work_to_do;
+ int work_done;
+ struct sbmac_softc *sc = netdev_priv(dev);
+
+ work_to_do = min(*budget, dev->quota);
+ work_done = sbdma_rx_process(sc,&(sc->sbm_rxdma), 1);
+ sbdma_tx_process(sc,&(sc->sbm_txdma), 1);
+
+ *budget -= work_done;
+ dev->quota -= work_done;
+
+ if (work_done < work_to_do) {
+ netif_rx_complete(dev);
+
+#ifdef CONFIG_SBMAC_COALESCE
+ __raw_writeq(((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_TX_CH0) |
+ ((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_RX_CH0),
+ sc->sbm_imr);
+#else
+ __raw_writeq((M_MAC_INT_CHANNEL << S_MAC_TX_CH0) |
+ (M_MAC_INT_CHANNEL << S_MAC_RX_CH0), sc->sbm_imr);
+#endif
+ }
+
+ return (work_done >= work_to_do);
+}
+#endif
#if defined(SBMAC_ETH0_HWADDR) || defined(SBMAC_ETH1_HWADDR) || defined(SBMAC_ETH2_HWADDR) || defined(SBMAC_ETH3_HWADDR)
static void
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: John Que @ 2006-06-04 16:29 UTC (permalink / raw)
To: Oliver Neukum
Cc: Daniel Drake, linux-usb-devel, John W. Linville, netdev,
Ulrich Kunitz
In-Reply-To: <200606040025.32275.oliver@neukum.org>
Hello,
I must confess I don't know much about the ZyDas driver and the rewrite
dirver, but folliowing this post I looked a bit at the code (of both
zd1211 and the rewrite version) and I have a little question; this may
be
seen as a (little) off topic but I will be happy if somebody will
raise this coin.
I had noticed that the zd1211 driver does call request_irq() in zd1205_open(),
file zd1205.c; grepping for request_irq() in the rewrite driver yields
no results.
(I looked at the rewrite version from a week ago but in this point it
is probably the
same).
Why is this so ? I assume that the softmac layer does not call request_irq() on
behalf of the driver because this is not supposed to be like it, as I understand
its functionality. Can anybody briefly calrify this point ?
Regards,
John
On 6/4/06, Oliver Neukum <oliver@neukum.org> wrote:
> Am Samstag, 3. Juni 2006 21:35 schrieb Daniel Drake:
> > Oliver Neukum wrote:
> > > +static int read_mac_addr(struct zd_chip *chip, u8 *mac_addr)
> > > +{
> > > + static const zd_addr_t addr[2] = { CR_MAC_ADDR_P1, CR_MAC_ADDR_P2 };
> > > + return _read_mac_addr(chip, mac_addr, (const zd_addr_t *)addr);
> > > +}
> > >
> > > Why on the stack?
> >
> > Technically it's not on the stack because it is static const (it goes in
> > rodata), but I don't think that this invalidates your point. What's the
> > alternative? kmalloc and kfree every time?
>
> In this case rodata will work. However, if you ever switch to direct DMA
> it will fail. I really did overlook the const keyword.
>
> [..]
> > > +static void disconnect(struct usb_interface *intf)
> > > This is racy. It allows io to disconnected devices. You must take the
> > > lock and set a flag that you test after you've taken the lock elsewhere.
> >
> > Will fix, thanks.
>
> You're welcome
>
> Regards
> Oliver
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Oliver Neukum @ 2006-06-04 17:17 UTC (permalink / raw)
To: John Que
Cc: Daniel Drake, linux-usb-devel, John W. Linville, netdev,
Ulrich Kunitz
In-Reply-To: <ada605fb0606040929p7a6ea69aw9488a75d611b23e5@mail.gmail.com>
Am Sonntag, 4. Juni 2006 18:29 schrieb John Que:
> I had noticed that the zd1211 driver does call request_irq() in zd1205_open(),
> file zd1205.c; grepping for request_irq() in the rewrite driver yields
> no results.
> (I looked at the rewrite version from a week ago but in this point it
> is probably the
> same).
> Why is this so ? I assume that the softmac layer does not call request_irq() on
> behalf of the driver because this is not supposed to be like it, as I understand
> its functionality. Can anybody briefly calrify this point ?
A USB driver never will request an irq. Interrupt handling is done in
the core usb layer. Individual drivers have no business there.
Regards
Oliver
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Rami Rosen @ 2006-06-04 18:03 UTC (permalink / raw)
To: Oliver Neukum
Cc: John Que, Daniel Drake, linux-usb-devel, John W. Linville, netdev,
Ulrich Kunitz
In-Reply-To: <200606041917.55496.oliver@neukum.org>
Hi,
While I did not yet review fully the code , I saw some definitions
which are not in use. (more than 150 such definitions, in one file) I
think it may be better to remove this #define statements to make the
code more readable. In case there will be a need in the future, the needed
#define statements can be returned.
The definitions which are not in use are from zd_chip.h.
It is mentioned there that these definitions are taken from the ZYDAS
driver and not all of them are relevant for the rewrite driver;
however, it seems to me that
removing them may be thought of.
Anyhow you did a great job and I hope I will find time to really delve
into the code.
The definitions I am talking about are: (see zd_chip.h)
CR_RF_IF_CLK
CR_RF_IF_DATA
CR_PE1_PE2
CR_PE2_DLY
CR_LE1
CR_LE2
CR_RADIO_PD
CR_RF2948_PD
CR_ENABLE_PS_MANUAL_AGC
CR_SA2400_SER_AP
CR_I2C_WRITE
CR_SA2400_SER_RP
CR_RADIO_PE
CR_RST_BUS_MASTER
CR_HSTSCHG
CR_PHY_ON
CR_RX_DELAY
CR_GPIO_1
CR_GPIO_2
CR_EncryBufMux
CR_MAC_PS_STATE
INT_TX_COMPLETE
INT_RX_COMPLETE
INT_RETRY_FAIL
INT_WAKEUP
INT_DTIM_NOTIFY
INT_CFG_NEXT_BCN
INT_BUS_ABORT
INT_TX_FIFO_READY
INT_UART
INT_TX_COMPLETE_EN
INT_RX_COMPLETE_EN
INT_RETRY_FAIL_EN
INT_WAKEUP_EN
INT_DTIM_NOTIFY_EN
INT_CFG_NEXT_BCN_EN
INT_BUS_ABORT_EN
INT_TX_FIFO_READY_EN
INT_UART_EN
CR_TSF_LOW_PART
CR_TSF_HIGH_PART
CR_UART_RBR_THR_DLL
CR_UART_DLM_IER
CR_UART_IIR_FCR
CR_UART_LCR
CR_UART_MCR
CR_UART_LSR
CR_UART_MSR
CR_UART_ECR
CR_UART_STATUS
CR_PCI_TX_ADDR_P1
CR_PCI_TX_AddR_P2
CR_PCI_RX_AddR_P1
CR_PCI_RX_AddR_P2
CR_BSSID_P1
CR_BSSID_P2
CR_RX_TIMEOUT
CR_RATE_9M
CR_RATE_18M
CR_RATE_36M
CR_RATE_48M
CR_RATE_54M
CR_RX_OFFSET
CR_PHY_DELAY
CR_BCN_FIFO
CR_DEVICE_STATE
CR_UNDERRUN_CNT
CR_BCN_FIFO_SEMAPHORE
CR_IFS_VALUE
CR_RX_TIME_OUT
CR_TOTAL_RX_FRM
CR_CRC32_CNT
CR_CRC16_CNT
CR_DECRYPTION_ERR_UNI
CR_RX_FIFO_OVERRUN
CR_DECRYPTION_ERR_MUL
CR_NAV_CNT
CR_NAV_CCA
CR_RETRY_CNT
CR_READ_TCB_ADDR
CR_READ_RFD_ADDR
CR_TOTAL_TX_FRM
CR_CAM_MODE
CR_CAM_ROLL_TB_LOW
CR_CAM_ROLL_TB_HIGH
CR_CAM_ADDRESS
CR_CAM_DATA
CR_ROMDIR
CR_DECRY_ERR_FLG_LOW
CR_DECRY_ERR_FLG_HIGH
CR_WEPKEY0
CR_WEPKEY1
CR_WEPKEY2
CR_WEPKEY3
CR_WEPKEY4
CR_WEPKEY5
CR_WEPKEY6
CR_WEPKEY7
CR_WEPKEY8
CR_WEPKEY9
CR_WEPKEY10
CR_WEPKEY11
CR_WEPKEY12
CR_WEPKEY13
CR_WEPKEY14
CR_WEPKEY15
CR_TKIP_MODE
CR_EEPROM_PROTECT0
CR_EEPROM_PROTECT1
CR_DBG_FIFO_RD
CR_DBG_SELECT
CR_FIFO_Length
CR_RSSI_MGC
CR_PON
CR_RX_ON
CR_TX_ON
CR_CHIP_EN
CR_LO_SW
CR_TXRX_SW
CR_S_MD
CR_USB_DEBUG_PORT
STA_RX_FILTER
E2P_PWR_CAL_VALUE2
E2P_PWR_CAL_VALUE3
E2P_PWR_CAL_VALUE4
E2P_PWR_INT_VALUE2
E2P_PWR_INT_VALUE3
E2P_PWR_INT_VALUE4
E2P_ALLOWED_CHANNEL
E2P_DEVICE_VER
E2P_36M_CAL_VALUE2
E2P_36M_CAL_VALUE3
E2P_36M_CAL_VALUE4
E2P_11A_INT_VALUE1
E2P_11A_INT_VALUE2
E2P_11A_INT_VALUE3
E2P_11A_INT_VALUE4
E2P_48M_CAL_VALUE2
E2P_48M_CAL_VALUE3
E2P_48M_CAL_VALUE4
E2P_48M_INT_VALUE1
E2P_48M_INT_VALUE2
E2P_48M_INT_VALUE3
E2P_48M_INT_VALUE4
E2P_54M_CAL_VALUE2
E2P_54M_CAL_VALUE3
E2P_54M_CAL_VALUE4
E2P_54M_INT_VALUE1
E2P_54M_INT_VALUE2
E2P_54M_INT_VALUE3
E2P_54M_INT_VALUE4
FW_SOFT_RESET
FW_FLASH_CHK
Regards,
Rami Rosen
On 6/4/06, Oliver Neukum <oliver@neukum.org> wrote:
> Am Sonntag, 4. Juni 2006 18:29 schrieb John Que:
> > I had noticed that the zd1211 driver does call request_irq() in zd1205_open(),
> > file zd1205.c; grepping for request_irq() in the rewrite driver yields
> > no results.
> > (I looked at the rewrite version from a week ago but in this point it
> > is probably the
> > same).
> > Why is this so ? I assume that the softmac layer does not call request_irq() on
> > behalf of the driver because this is not supposed to be like it, as I understand
> > its functionality. Can anybody briefly calrify this point ?
>
> A USB driver never will request an irq. Interrupt handling is done in
> the core usb layer. Individual drivers have no business there.
>
> Regards
> Oliver
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: John Que @ 2006-06-04 18:22 UTC (permalink / raw)
To: Oliver Neukum
Cc: Daniel Drake, linux-usb-devel, John W. Linville, netdev,
Ulrich Kunitz
In-Reply-To: <200606041917.55496.oliver@neukum.org>
Hello Oliver,
I am sorry, but I think I don't understand ,
You said:
>A USB driver never will request an irq. Interrupt handling is done in
> the core usb layer. Individual drivers have no business there.
but in the zd1211 driver (not the rewrite version) I found this
call to request an irq:
request_irq(dev->irq, &zd1205_intr, SA_SHIRQ, dev->name, dev)
Also when looking in the linux tree, I see some request_irq() calls in USB
drivers, for exmaple in some drivers under usb/gadgaets, and more.
Can you please elaborate a bit ? What do you mean by saying
"A USB driver never will request an irq"?
-- John
On 6/4/06, Oliver Neukum <oliver@neukum.org> wrote:
> Am Sonntag, 4. Juni 2006 18:29 schrieb John Que:
> > I had noticed that the zd1211 driver does call request_irq() in zd1205_open(),
> > file zd1205.c; grepping for request_irq() in the rewrite driver yields
> > no results.
> > (I looked at the rewrite version from a week ago but in this point it
> > is probably the
> > same).
> > Why is this so ? I assume that the softmac layer does not call request_irq() on
> > behalf of the driver because this is not supposed to be like it, as I understand
> > its functionality. Can anybody briefly calrify this point ?
>
> A USB driver never will request an irq. Interrupt handling is done in
> the core usb layer. Individual drivers have no business there.
>
> Regards
> Oliver
>
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Oliver Neukum @ 2006-06-04 19:06 UTC (permalink / raw)
To: John Que
Cc: Daniel Drake, linux-usb-devel, John W. Linville, netdev,
Ulrich Kunitz
In-Reply-To: <ada605fb0606041122w36ad8320wa0a5d8241c98644c@mail.gmail.com>
Am Sonntag, 4. Juni 2006 20:22 schrieb John Que:
> Hello Oliver,
>
> I am sorry, but I think I don't understand ,
> You said:
> >A USB driver never will request an irq. Interrupt handling is done in
> > the core usb layer. Individual drivers have no business there.
>
> but in the zd1211 driver (not the rewrite version) I found this
> call to request an irq:
> request_irq(dev->irq, &zd1205_intr, SA_SHIRQ, dev->name, dev)
>
> Also when looking in the linux tree, I see some request_irq() calls in USB
> drivers, for exmaple in some drivers under usb/gadgaets, and more.
>
> Can you please elaborate a bit ? What do you mean by saying
> "A USB driver never will request an irq"?
The architecture is as follows:
device driver <---> USB core <---> host driver <=== USB ===> gadget driver <---> function driver
Only those drivers that deal with the hardware directly request interrupts.
A device driver submits URBs and deals with callbacks.
Regards
Oliver
^ permalink raw reply
* [PATCH] bcm43xx: quiet down log spam from set_security
From: Michael Buesch @ 2006-06-04 21:05 UTC (permalink / raw)
To: John Linville; +Cc: netdev, bcm43xx-dev, Jason Lunz
John, please queue for 2.6.18.
--
From: Jason Lunz <lunz@falooley.org>
The debug logging in bcm43xx_ieee80211_set_security() is pretty noisy.
Make it more silent.
Signed-off-by: Jason Lunz <lunz@falooley.org>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
diff -ur linux-2.6.17-rc5-git11/drivers/net/wireless/bcm43xx/bcm43xx_main.c linux-2.6.17-rc5-git11.quiet/drivers/net/wireless/bcm43xx/bcm43xx_main.c
--- linux-2.6.17-rc5-git11/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-29 12:33:56.000000000 -0400
+++ linux-2.6.17-rc5-git11.quiet/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-06-04 14:51:09.000000000 -0400
@@ -3568,7 +3568,7 @@
unsigned long flags;
int keyidx;
- dprintk(KERN_INFO PFX "set security called\n");
+ dprintk(KERN_INFO PFX "set security called");
bcm43xx_lock_mmio(bcm, flags);
@@ -3581,24 +3581,25 @@
if (sec->flags & SEC_ACTIVE_KEY) {
secinfo->active_key = sec->active_key;
- dprintk(KERN_INFO PFX " .active_key = %d\n", sec->active_key);
+ dprintk(", .active_key = %d", sec->active_key);
}
if (sec->flags & SEC_UNICAST_GROUP) {
secinfo->unicast_uses_group = sec->unicast_uses_group;
- dprintk(KERN_INFO PFX " .unicast_uses_group = %d\n", sec->unicast_uses_group);
+ dprintk(", .unicast_uses_group = %d", sec->unicast_uses_group);
}
if (sec->flags & SEC_LEVEL) {
secinfo->level = sec->level;
- dprintk(KERN_INFO PFX " .level = %d\n", sec->level);
+ dprintk(", .level = %d", sec->level);
}
if (sec->flags & SEC_ENABLED) {
secinfo->enabled = sec->enabled;
- dprintk(KERN_INFO PFX " .enabled = %d\n", sec->enabled);
+ dprintk(", .enabled = %d", sec->enabled);
}
if (sec->flags & SEC_ENCRYPT) {
secinfo->encrypt = sec->encrypt;
- dprintk(KERN_INFO PFX " .encrypt = %d\n", sec->encrypt);
+ dprintk(", .encrypt = %d", sec->encrypt);
}
+ dprintk("\n");
if (bcm->initialized && !bcm->ieee->host_encrypt) {
if (secinfo->enabled) {
/* upload WEP keys to hardware */
--
Greetings Michael.
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Daniel Drake @ 2006-06-04 21:45 UTC (permalink / raw)
To: John Que
Cc: Oliver Neukum, linux-usb-devel, John W. Linville, netdev,
Ulrich Kunitz
In-Reply-To: <ada605fb0606040929p7a6ea69aw9488a75d611b23e5@mail.gmail.com>
John Que wrote:
> I had noticed that the zd1211 driver does call request_irq() in
> zd1205_open(),
> file zd1205.c;
Look at it in context:
#ifndef HOST_IF_USB
if ((rc = request_irq(dev->irq, &zd1205_intr, SA_SHIRQ, dev->name,
dev)) != 0) {
printk(KERN_ERR "zd1205: failed to request_irq\n");
The ZD1211 vendor driver appears to be an adapted version of another
ZyDAS driver which supports a PCI wifi chip, presumably there are some
similarities. There are many such headaches when trying to read through
this driver...
request_irq never happens because HOST_IF_USB gets defined.
Daniel
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Daniel Drake @ 2006-06-04 21:51 UTC (permalink / raw)
To: Rami Rosen
Cc: Oliver Neukum, John Que, linux-usb-devel, John W. Linville,
netdev, Ulrich Kunitz
In-Reply-To: <ae5426fb0606041103od6bf095sd4403ab2966a1e1f@mail.gmail.com>
Rami Rosen wrote:
> It is mentioned there that these definitions are taken from the ZYDAS
> driver and not all of them are relevant for the rewrite driver;
> however, it seems to me that
> removing them may be thought of.
They are mostly relevant, not all come from the vendor driver directly,
some will be used later, many are useful for documenting the bits and
bobs that we *do* know about the CR registers (not a lot).
I don't think there are any readability issues while all defines are
kept out of the way from the code.
Daniel
^ permalink raw reply
* [PATCH] hush noisy ieee80211 CCMP printks
From: Jason Lunz @ 2006-06-05 0:12 UTC (permalink / raw)
To: jkmaline, linville; +Cc: netdev
Don't swamp syslog with
CCMP: decrypt failed: STA=00:12:17:3a:e2:c7
and
CCMP: replay detected: STA=00:12:17:3a:e2:c7 previous PN 000000000004 received PN 000000000004
messages.
These both seem to be completely normal in regular use, especially
'decrypt failed' whenever another wpa-using station on the same AP is
within range.
These events are still being counted in the statistics.
Signed-off-by: Jason Lunz <lunz@falooley.org>
---
net/ieee80211/ieee80211_crypt_ccmp.c | 11 -----------
1 file changed, 11 deletions(-)
Index: linux-2.6.17-rc5-git11/net/ieee80211/ieee80211_crypt_ccmp.c
===================================================================
--- linux-2.6.17-rc5-git11.orig/net/ieee80211/ieee80211_crypt_ccmp.c
+++ linux-2.6.17-rc5-git11/net/ieee80211/ieee80211_crypt_ccmp.c
@@ -326,13 +326,6 @@
pos += 8;
if (memcmp(pn, key->rx_pn, CCMP_PN_LEN) <= 0) {
- if (net_ratelimit()) {
- printk(KERN_DEBUG "CCMP: replay detected: STA=" MAC_FMT
- " previous PN %02x%02x%02x%02x%02x%02x "
- "received PN %02x%02x%02x%02x%02x%02x\n",
- MAC_ARG(hdr->addr2), MAC_ARG(key->rx_pn),
- MAC_ARG(pn));
- }
key->dot11RSNAStatsCCMPReplays++;
return -4;
}
@@ -357,10 +350,6 @@
}
if (memcmp(mic, a, CCMP_MIC_LEN) != 0) {
- if (net_ratelimit()) {
- printk(KERN_DEBUG "CCMP: decrypt failed: STA="
- MAC_FMT "\n", MAC_ARG(hdr->addr2));
- }
key->dot11RSNAStatsCCMPDecryptErrors++;
return -5;
}
^ permalink raw reply
* wireless (was Re: 2.6.18 -mm merge plans)
From: Jeff Garzik @ 2006-06-05 1:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev, linville
In-Reply-To: <20060604135011.decdc7c9.akpm@osdl.org>
On Sun, Jun 04, 2006 at 01:50:11PM -0700, Andrew Morton wrote:
> acx1xx-wireless-driver.patch
> fix-tiacx-on-alpha.patch
> tiacx-fix-attribute-packed-warnings.patch
> tiacx-pci-build-fix.patch
> tiacx-ia64-fix.patch
>
> It is about time we did something with this large and presumably useful
> wireless driver.
I've never had technical objections to merging this, just AFAIK it had a
highly questionable origin, namely being reverse-engineered in a
non-clean-room environment that might leave Linux legally vulnerable.
If we can clear that hurdle, by all means pass it on to John Linville
and get it moving towards upstream.
Jeff
^ permalink raw reply
* Re: wireless (was Re: 2.6.18 -mm merge plans)
From: Andrew Morton @ 2006-06-05 1:15 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel, netdev, linville, Denis Vlasenko
In-Reply-To: <20060605010636.GB17361@havoc.gtf.org>
On Sun, 4 Jun 2006 21:06:36 -0400
Jeff Garzik <jeff@garzik.org> wrote:
> On Sun, Jun 04, 2006 at 01:50:11PM -0700, Andrew Morton wrote:
> > acx1xx-wireless-driver.patch
> > fix-tiacx-on-alpha.patch
> > tiacx-fix-attribute-packed-warnings.patch
> > tiacx-pci-build-fix.patch
> > tiacx-ia64-fix.patch
> >
> > It is about time we did something with this large and presumably useful
> > wireless driver.
>
> I've never had technical objections to merging this, just AFAIK it had a
> highly questionable origin, namely being reverse-engineered in a
> non-clean-room environment that might leave Linux legally vulnerable.
I never knew that.
<reads changelog>
<reads website>
<reads wiki>
I still don't know that. Denis, do you know the details?
> If we can clear that hurdle, by all means pass it on to John Linville
> and get it moving towards upstream.
OK, thanks.
^ permalink raw reply
* Re: [Bug 6421] kernel 2.6.10-2.6.16 on alpha: arch/alpha/kernel/io.c, iowrite16_rep() BUG_ON((unsigned long)src & 0x1) triggered
From: David Miller @ 2006-06-05 4:48 UTC (permalink / raw)
To: herbert; +Cc: yoshfuji, bugme-daemon, netdev
In-Reply-To: <20060603110711.GA1754@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 3 Jun 2006 21:07:11 +1000
> On Sat, Jun 03, 2006 at 07:51:23PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> >
> > I think that people will start thinking why we cannot
> > skb_pull(skb, len) if skb_headlen(skb) == len; some comment needed...
>
> Good idea. Here is a better one.
>
> [TCP]: Avoid skb_pull if possible when trimming head
Applied, thanks a lot Herbert.
^ permalink raw reply
* Re: [Bugme-new] [Bug 6646] New: UDP socket doesn't return to bound state after association is dissolved by connect(..AF_UNSPEC)
From: Andrew Morton @ 2006-06-05 7:07 UTC (permalink / raw)
To: netdev, yujiang.wang; +Cc: bugme-daemon
In-Reply-To: <200606050658.k556wJ8X032608@fire-2.osdl.org>
On Sun, 4 Jun 2006 23:58:19 -0700
bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=6646
>
> Summary: UDP socket doesn't return to bound state after
> association is dissolved by connect(..AF_UNSPEC)
> Kernel Version: 2.6.12
> Status: NEW
> Severity: high
> Owner: shemminger@osdl.org
> Submitter: yujiang.wang@sun.com
>
>
> Most recent kernel where this bug did not occur:
> Distribution:
> Hardware Environment:
> Software Environment:
> Problem Description:
> When disconnect a UDP socket, Linux kernel set local port to zero if the port
> number comes from a implicit bind. Linux connect(2) man page reads:
> "Generally, connection-based protocol sockets may successfully *connect* only
> once; connectionless protocol sockets may use *connect* multiple times to change
> their association. Connectionless sockets may dissolve the association by
> connecting to an address with the /sa_family/ member of *sockaddr* set to
> *AF_UNSPEC*."
> But dissolve the association should not impact the local binding, while
> currently it does. In contrast, Unix variants like Solaris don't alter local
> binding when disconnecting a UDP socket.
>
> Steps to reproduce:
> Compile attached c file, and run it. You'll see local port number changed after
> a UDP socket disconnected.
>
> #include <errno.h>
> #include <string.h>
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> #include <net/if.h>
> #include <netdb.h>
> #include <arpa/inet.h>
> #include <stdio.h>
> #include <stdlib.h>
>
> #define SERV_PORT 12345
>
> void print_local_addr(int s);
>
> int main(int argc, char** argv)
> {
> int sockfd;
> struct sockaddr_in servaddr, cliaddr;
>
> if (argc != 2) {
> printf("Usage: disconnect_udp <ipaddress>");
> exit(0);
> }
>
> // creat a UDP socket which binds to a local address
> sockfd = socket(AF_INET, SOCK_DGRAM, 0);
> bzero(&cliaddr, sizeof(cliaddr));
> cliaddr.sin_family = AF_INET;
> if (inet_pton(AF_INET, argv[1], &cliaddr.sin_addr) != 1) {
> perror("inet_pton failed");
> }
> bind(sockfd, (struct sockaddr *)&cliaddr, sizeof(cliaddr));
>
> // connect this UDP socket
> bzero(&servaddr, sizeof(servaddr));
> servaddr.sin_family = AF_INET;
> servaddr.sin_port = htons(SERV_PORT);
> if (inet_pton(AF_INET, argv[1], &servaddr.sin_addr) != 1) {
> perror("inet_pton failed");
> }
> if (connect(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr)) != 0) {
> perror("connect failed");
> }
> print_local_addr(sockfd);
>
> // disconnect it
> servaddr.sin_family = AF_UNSPEC;
> if (connect(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr)) != 0) {
> perror("connect failed");
> }
> print_local_addr(sockfd);
>
> close(sockfd);
> }
>
> void print_local_addr(int s)
> {
> struct sockaddr_in localaddr;
> socklen_t len = 0;
> char temp[INET_ADDRSTRLEN];
>
> len = sizeof(localaddr);
> if (getsockname(s, (struct sockaddr *)&localaddr, &len) != 0) {
> perror("getsockname failed");
> }
>
> inet_ntop(AF_INET, &localaddr.sin_addr, temp, INET_ADDRSTRLEN);
> printf("Local binding: address=%s, port=%d\n",
> temp, ntohs(localaddr.sin_port));
> }
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply
* Re: wireless (was Re: 2.6.18 -mm merge plans)
From: Andreas Mohr @ 2006-06-05 8:33 UTC (permalink / raw)
To: Andrew Morton
Cc: Jeff Garzik, linux-kernel, netdev, linville, Denis Vlasenko,
acx100-devel, acx100-users
In-Reply-To: <20060604181515.8faa8fcf.akpm@osdl.org>
Hi,
On Sun, Jun 04, 2006 at 06:15:15PM -0700, Andrew Morton wrote:
> On Sun, 4 Jun 2006 21:06:36 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
> > > It is about time we did something with this large and presumably useful
> > > wireless driver.
> >
> > I've never had technical objections to merging this, just AFAIK it had a
> > highly questionable origin, namely being reverse-engineered in a
> > non-clean-room environment that might leave Linux legally vulnerable.
>
> I never knew that.
>
> <reads changelog>
> <reads website>
> <reads wiki>
>
> I still don't know that. Denis, do you know the details?
The acx100 project was started by about 5 people examining the various
acx100 binary Linux driver "releases" for distro kernels around 2.4.18 etc.
Since this might fail to comply with usual "clean-room" practices
(e.g. one party examining a driver and then a separate party implementing
a new driver with the data gained from examining the original driver),
it may fail to be seen as acceptable for Linux inclusion.
Since missing kernel inclusion is both a maintenance overhead and
(most importantly!) a huge user-level issue, I'd see this as a big problem.
In case there are development-unrelated obstacles against kernel inclusion,
I see (at least?) two possibilities:
a) asking TI to sprinkle our driver effort with the (ahem) holy penguin pee
required to have it blessed sufficiently for kernel inclusion (preferrably
in combination with nice firmware blob licensing and specs for those
chipsets would be nice)
This might be a problem given that Theo de Raadt and many other people had
fun repeatedly trying to contact TI for a useful statement concerning WLAN
support.
b) abandoning our unfortunately not as blessed as intended (stability,
community involvement, ...) big-effort driver efforts ("3 years and still
going strong...") [1] and suggesting donating about 100000 OEM WLAN cards
equipped with TI chipsets to various beautiful landfills in various
countries ;-)
Whichever way this irons out, at this point I'm quite indifferent to what
happens, given that I really don't feel like spending too many endless weekends
with hardware and driver puzzles any more in exchange for rather dubious gains.
There's also a lot of fun in generic Linux kernel hacking, so...
Andreas Mohr
[1] we're *still* having issues with spotty ACK reception and radio
temperature drift recalibration on those unsupported chipsets,
which requires quite some focused development efforts and close examination
of WLAN traffic in order to really find out what the heck is going wrong here.
And please note that there's now the newer TNETW1450 chipset variant (most
prominently used by AVM hardware with its initial x86-only Linux USB2.0 driver)
with similar support issues which would require even more development.
^ permalink raw reply
* Re: wireless (was Re: 2.6.18 -mm merge plans)
From: Arjan van de Ven @ 2006-06-05 8:45 UTC (permalink / raw)
To: Andreas Mohr
Cc: Andrew Morton, Jeff Garzik, linux-kernel, netdev, linville,
Denis Vlasenko, acx100-devel, acx100-users
In-Reply-To: <20060605083321.GA15690@rhlx01.fht-esslingen.de>
On Mon, 2006-06-05 at 10:33 +0200, Andreas Mohr wrote:
> Hi,
>
> On Sun, Jun 04, 2006 at 06:15:15PM -0700, Andrew Morton wrote:
> > On Sun, 4 Jun 2006 21:06:36 -0400
> > Jeff Garzik <jeff@garzik.org> wrote:
> > > > It is about time we did something with this large and presumably useful
> > > > wireless driver.
> > >
> > > I've never had technical objections to merging this, just AFAIK it had a
> > > highly questionable origin, namely being reverse-engineered in a
> > > non-clean-room environment that might leave Linux legally vulnerable.
> >
> > I never knew that.
> >
> > <reads changelog>
> > <reads website>
> > <reads wiki>
> >
> > I still don't know that. Denis, do you know the details?
>
> The acx100 project was started by about 5 people examining the various
> acx100 binary Linux driver "releases" for distro kernels around 2.4.18 etc.
> Since this might fail to comply with usual "clean-room" practices
> (e.g. one party examining a driver and then a separate party implementing
> a new driver with the data gained from examining the original driver),
> it may fail to be seen as acceptable for Linux inclusion.
I disagree there (not speaking for any company just for myself here):
the "clean room" thing is ONLY a USA thing, and is not even required in
the USA. It is a "we want to be extra safe in the USA" thing only. Eg if
you want to be tripple safe and do this in the USA, the clean room is a
good way to be sure.
If you do things in europe or elsewhere, and/or as long as you don't
copy from the original, only use it to learn how it works, you should be
fine as well. It's just that a cleanroom approach is a sure way to prove
you didn't copy. That's all.
If "clean room" now is a requirement for a driver to hit the kernel,
then we need to remove about half the drivers in the kernel I suspect;
that'd just be silly.
I would say that as long as you and the others can certify that you
didn't copy from the original driver, but only used it to learn how it
worked, the kernel should be fine with it.
^ permalink raw reply
* Re: wireless (was Re: 2.6.18 -mm merge plans)
From: Christoph Hellwig @ 2006-06-05 8:54 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, linux-kernel, netdev, linville
In-Reply-To: <20060605010636.GB17361@havoc.gtf.org>
On Sun, Jun 04, 2006 at 09:06:36PM -0400, Jeff Garzik wrote:
> On Sun, Jun 04, 2006 at 01:50:11PM -0700, Andrew Morton wrote:
> > acx1xx-wireless-driver.patch
> > fix-tiacx-on-alpha.patch
> > tiacx-fix-attribute-packed-warnings.patch
> > tiacx-pci-build-fix.patch
> > tiacx-ia64-fix.patch
> >
> > It is about time we did something with this large and presumably useful
> > wireless driver.
>
> I've never had technical objections to merging this, just AFAIK it had a
> highly questionable origin, namely being reverse-engineered in a
> non-clean-room environment that might leave Linux legally vulnerable.
As are at leasdt a fourth of linux drivers. Andrew, please just go ahead
and merge it (I'll do another review ASAP).
Please don't let this reverse engineering idiocy hinder wireless driver
adoption, we're already falling far behind openbsd who are very successfull
reverse engineering lots of wireless chipsets.
^ permalink raw reply
* Re: OLPC (One Laptop Per Child) Developer's program.
From: David Woodhouse @ 2006-06-05 9:07 UTC (permalink / raw)
To: Anand Kumria; +Cc: netdev
In-Reply-To: <e5umgs$lfj$1@sea.gmane.org>
On Sun, 2006-06-04 at 13:17 +0000, Anand Kumria wrote:
> > One thing we really need is NAT-PT or an equivalent for allowing access
> > to the Legacy Internet from IPv6-only hosts. As soon as I finish playing
> > with JFFS2 improvements, I plan to start looking at that.
>
> Wouldn't miredo mostly fit the bill? It won't get through Symmetric NATs
> (by design) but those are supposed to be uncommon.
That seems to be a method for IPv4 hosts to get IPv6 connectivity. What
I'm after is a method for IPv6 hosts to get IPv4 connectivity -- like
NAT-PT.
--
dwmw2
^ permalink raw reply
* Re: wireless (was Re: 2.6.18 -mm merge plans)
From: Alan Cox @ 2006-06-05 10:26 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Andreas Mohr, Andrew Morton, Jeff Garzik, linux-kernel, netdev,
linville, Denis Vlasenko, acx100-devel, acx100-users
In-Reply-To: <1149497109.3111.28.camel@laptopd505.fenrus.org>
Ar Llu, 2006-06-05 am 10:45 +0200, ysgrifennodd Arjan van de Ven:
> It's just that a cleanroom approach is a sure way to prove
> you didn't copy. That's all.
Which is an extremely important detail especially if you have been
reverse engineering another driver for the same or similar OS where it
is likely that people will retain knowledge and copy rather than
re-implement things.
We've had "fun" with this before and the pwc camera driver. I don't want
to see a repeat of that.
Alan
^ permalink raw reply
* Re: wireless (was Re: 2.6.18 -mm merge plans)
From: Arjan van de Ven @ 2006-06-05 10:35 UTC (permalink / raw)
To: Alan Cox
Cc: Andreas Mohr, Andrew Morton, Jeff Garzik, linux-kernel, netdev,
linville, Denis Vlasenko, acx100-devel, acx100-users
In-Reply-To: <1149503215.30554.6.camel@localhost.localdomain>
On Mon, 2006-06-05 at 11:26 +0100, Alan Cox wrote:
> Ar Llu, 2006-06-05 am 10:45 +0200, ysgrifennodd Arjan van de Ven:
> > It's just that a cleanroom approach is a sure way to prove
> > you didn't copy. That's all.
>
> Which is an extremely important detail especially if you have been
> reverse engineering another driver for the same or similar OS where it
> is likely that people will retain knowledge and copy rather than
> re-implement things.
oh don't get me wrong, it's important to not copy from the original.
(even if that original did copy from linux ;)
> We've had "fun" with this before and the pwc camera driver. I don't want
> to see a repeat of that.
yet at the same time, the cleanroom approach is not the ONLY way to do
it right. And making following that exact approach a strict requirement
is just silly. And it would mean we'd need to remove quite a few drivers
from the tree if you follow that logic.
And to be fair the pwc camera driver was just a guy with a personality
problem rather than any real legal standing.
Again doing things right is important. But I would say that if you do
the rev-engineering in Europe, just being careful and avoiding copying
should be enough (well and certifying that you were in fact careful and
didn't do any copying).
^ permalink raw reply
* Re: wireless (was Re: 2.6.18 -mm merge plans)
From: Alan Cox @ 2006-06-05 10:59 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Andreas Mohr, Andrew Morton, Jeff Garzik, linux-kernel, netdev,
linville, Denis Vlasenko, acx100-devel, acx100-users
In-Reply-To: <1149503730.3111.46.camel@laptopd505.fenrus.org>
Ar Llu, 2006-06-05 am 12:35 +0200, ysgrifennodd Arjan van de Ven:
> And to be fair the pwc camera driver was just a guy with a personality
> problem rather than any real legal standing.
I must disagree there having reviewed the code in question and been
directly involved in the fallout.
Alan
^ permalink raw reply
* Re: wireless (was Re: 2.6.18 -mm merge plans)
From: Jeff Garzik @ 2006-06-05 12:33 UTC (permalink / raw)
To: Christoph Hellwig, Andrew Morton, linux-kernel, netdev, linville
In-Reply-To: <20060605085451.GA26766@infradead.org>
On Mon, Jun 05, 2006 at 09:54:51AM +0100, Christoph Hellwig wrote:
> On Sun, Jun 04, 2006 at 09:06:36PM -0400, Jeff Garzik wrote:
> > On Sun, Jun 04, 2006 at 01:50:11PM -0700, Andrew Morton wrote:
> > > acx1xx-wireless-driver.patch
> > > fix-tiacx-on-alpha.patch
> > > tiacx-fix-attribute-packed-warnings.patch
> > > tiacx-pci-build-fix.patch
> > > tiacx-ia64-fix.patch
> > >
> > > It is about time we did something with this large and presumably useful
> > > wireless driver.
> >
> > I've never had technical objections to merging this, just AFAIK it had a
> > highly questionable origin, namely being reverse-engineered in a
> > non-clean-room environment that might leave Linux legally vulnerable.
>
> As are at leasdt a fourth of linux drivers. Andrew, please just go ahead
Hardly. The -vast majority- of drivers I've dealt with in my time
hacking the kernel are either blessed by the vendor, or are of
unquestionably legal origin.
It's a good thing I pay attention to this issue, too, Mr. Just Go Ahead
And Merge It.
> Please don't let this reverse engineering idiocy hinder wireless driver
> adoption, we're already falling far behind openbsd who are very successfull
> reverse engineering lots of wireless chipsets.
Thanks for your highly professional, legal opinion :)
Jeff
^ permalink raw reply
* Re: wireless (was Re: 2.6.18 -mm merge plans)
From: Arjan van de Ven @ 2006-06-05 12:48 UTC (permalink / raw)
To: Jeff Garzik
Cc: Christoph Hellwig, Andrew Morton, linux-kernel, netdev, linville
In-Reply-To: <20060605123304.GA6066@havoc.gtf.org>
>
> It's a good thing I pay attention to this issue, too, Mr. Just Go Ahead
> And Merge It.
dude, name calling is way out of line here.
Why is it a good thing you are blocking this driver? Do you have ANY
indication AT ALL that there is anything fishy about it?
(and don't say "they didn't follow cleanroom procedure", because you
know that cleanroom is not the only way to do reverse engineering
properly).
Paying attention to proper reverse engineering is good. Being
overzealous is not.
^ 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