* 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
* Re: wireless (was Re: 2.6.18 -mm merge plans)
From: Jeff Garzik @ 2006-06-05 12:52 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Christoph Hellwig, Andrew Morton, linux-kernel, netdev, linville
In-Reply-To: <1149511707.3111.57.camel@laptopd505.fenrus.org>
On Mon, Jun 05, 2006 at 02:48:27PM +0200, Arjan van de Ven wrote:
> 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?
Yes.
> Paying attention to proper reverse engineering is good. Being
> overzealous is not.
Being overzealous about merging drivers without first checking the legal
ramifications is a good way to torpedo Linux.
Far too many people have a careless "U.S.A. laws suck, merge it anyway"
attitude.
Jeff
^ permalink raw reply
* Re: wireless (was Re: 2.6.18 -mm merge plans)
From: John W. Linville @ 2006-06-05 13:27 UTC (permalink / raw)
To: Christoph Hellwig, Jeff Garzik, Andrew Morton, linux-kernel,
netdev
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
> and merge it (I'll do another review ASAP).
Actually, I was planning to merge the softmac-based version for 2.6.18.
It looks like I may want some of Andrew's patches on top (ia64, alpha, etc).
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/master/
0003-wireless-add-acx-driver.txt
0004-acxsm-merge-from-acx-0.3.32.txt
0005-tiacx-Let-only-ACX_PCI-ACX_USB-be-user-visible.txt
0007-tiacx-revert-neither-PCI-nor-USB-is-selected-change.txt
0008-tiacx-implement-much-more-flexible-firmware-statistics-parsing.txt
0009-tiacx-Change-acx_ioctl_-get-set-_encode-to-use-kernel-80211-stack.txt
0010-tiacx-fix-breakage-of-Get-rid-of-circular-list-of-adev-s.txt
0011-tiacx-split-module-into-acx-common-acx-pci-acx-usb.txt
Of course, I didn't know there were serious concerns about this
driver's origin. I hope we aren't confusing this with the atheros
driver...?
> 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.
This bugbear does seem to keep visiting us. It is a bit of a
minefield.
I'm inclined to think that Christoph and Arjan are right, that we
have been too cautious. Of course, neither of these fine gentlemen
are known for their timidity... :-)
Does not the Signed-off-by: line on a patch submission give us some
level of "good faith" protection?
I'm tempted to take contributors at their word, that they have produced
their own work and not copied from others. What else do we need?
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: wireless (was Re: 2.6.18 -mm merge plans)
From: Christoph Hellwig @ 2006-06-05 13:31 UTC (permalink / raw)
To: Christoph Hellwig, Jeff Garzik, Andrew Morton, linux-kernel,
netdev
In-Reply-To: <20060605132732.GA23350@tuxdriver.com>
On Mon, Jun 05, 2006 at 09:27:37AM -0400, John W. Linville wrote:
> Actually, I was planning to merge the softmac-based version for 2.6.18.
> It looks like I may want some of Andrew's patches on top (ia64, alpha, etc).
duh, didn't know that wasn't in -mm. we want the softmac version of course.
^ permalink raw reply
* Re: [PATCH] hush noisy ieee80211 CCMP printks
From: Jouni Malinen @ 2006-06-05 13:31 UTC (permalink / raw)
To: Jason Lunz; +Cc: linville, netdev
In-Reply-To: <20060605001208.GA4585@opus.vpn-dev.reflex>
On Sun, Jun 04, 2006 at 08:12:09PM -0400, Jason Lunz wrote:
> 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 are not normal, i.e., they should not really show up unless
something goes wrong. In many cases, this may be caused by something
missing in local filtering (e.g., retry duplicates are not filtered out
correctly or messages to incorrect addresses are allowed through, etc.).
In other cases, it can indicate incorrect implementation of rekeying or
some other bugs in either end of the connection. Anyway, I don't have
anything against removing the messages in default kernel builds. If
there is a suitable build time debug option, that might be nicer way of
doing this, though, since these can provide valuable information when
figuring out why something does not work.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: wireless (was Re: 2.6.18 -mm merge plans)
From: Arjan van de Ven @ 2006-06-05 13:42 UTC (permalink / raw)
To: John W. Linville
Cc: Christoph Hellwig, Jeff Garzik, Andrew Morton, linux-kernel,
netdev
In-Reply-To: <20060605132732.GA23350@tuxdriver.com>
> Of course, I didn't know there were serious concerns about this
> driver's origin. I hope we aren't confusing this with the atheros
> driver...?
>
> > 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.
>
> This bugbear does seem to keep visiting us. It is a bit of a
> minefield.
>
> I'm inclined to think that Christoph and Arjan are right, that we
> have been too cautious. Of course, neither of these fine gentlemen
> are known for their timidity... :-)
>
> Does not the Signed-off-by: line on a patch submission give us some
> level of "good faith" protection?
I would suggest asking them an explicit "did you copy anything" and make
sure their "we didn't copy" answer is in the description of the original
patch submission.
>
> I'm tempted to take contributors at their word, that they have produced
> their own work and not copied from others. What else do we need?
to a large degree that's all you can do. (of course you can look at the
code for something that looks "obviously not from here" as well, and we
all tend to do that anyway since such stuff tends to highly violate
coding style anyway)
^ permalink raw reply
* Linux kernel and laws
From: Adrian Bunk @ 2006-06-05 14:02 UTC (permalink / raw)
To: Jeff Garzik
Cc: Arjan van de Ven, Christoph Hellwig, Andrew Morton, linux-kernel,
netdev, linville
In-Reply-To: <20060605125235.GB6066@havoc.gtf.org>
On Mon, Jun 05, 2006 at 08:52:35AM -0400, Jeff Garzik wrote:
>...
> > Paying attention to proper reverse engineering is good. Being
> > overzealous is not.
>
> Being overzealous about merging drivers without first checking the legal
> ramifications is a good way to torpedo Linux.
>
> Far too many people have a careless "U.S.A. laws suck, merge it anyway"
> attitude.
Independent of this issue:
An interesting question is how to handle legal issues properly.
Where is the borderline for rejecting code due to legal issues?
Might not be 100% correct according to laws in the USA.
Might not be 100% correct according to laws in Germany.
Might not be 100% correct according to laws in Finland.
Might not be 100% correct according to laws in Norway.
Might not be 100% correct according to laws in Brasil.
Might not be 100% correct according to laws in Japan.
Might not be 100% correct according to laws in India.
Might not be 100% correct according to laws in Russia.
Might not be 100% correct according to laws in China.
Might not be 100% correct according to laws in Saudi Arabia.
Might not be 100% correct according to laws in Iran.
For me living in Germany, none of these laws except for the German one
has any relevance.
I've never seen people on this list pointing to probable problems with
Chinese laws although these laws are relevant for four times as many
people as US laws.
If someone would state a submission to the kernel might have issues
according to Chinese laws, or Iranian laws, or Russian laws, would this
be enough for keeping code out of the kernel?
This might sound like a theoretical question, but e.g. considering that
the kernel contains cryptography code it's a question that might have
wide practical implications.
> Jeff
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: move zd1201 where it belongs
From: John W. Linville @ 2006-06-05 14:13 UTC (permalink / raw)
To: Pavel Machek
Cc: Arjan van de Ven, Jirka Lenost Benc, kernel list, netdev, pe1rxq
In-Reply-To: <20060605113332.GB2132@elf.ucw.cz>
On Mon, Jun 05, 2006 at 01:33:33PM +0200, Pavel Machek wrote:
> On Po 05-06-06 13:15:20, Arjan van de Ven wrote:
> > On Mon, 2006-06-05 at 12:39 +0200, Pavel Machek wrote:
> > > zd1201 is wifi adapter, yet it is hiding in drivers/usb/net where
> > > noone can find it. This moves Kconfig/Makefile to right place; you
> > > still need to manually move .c and .h files.
> > do you think it should at least depend in some form or another on
> > CONFIG_USB ?
>
> Right, added USB && to depends directive.
Did you mean to only copy Jiri and LKML?
It seems like you should have sent at least sent this to
netdev@vger.kernel.org, if not also to me, Jeroen Vreeken and/or
possibly Greg K-H (USB subsystem).
Will you be posting a new version, with the CONFIG_USB change?
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