Daniel, just to add something about the website, the list about the devices with the chip was very useful. It helped me to buy an additional dongle for development. The other ZD1211 is inside my Shuttle and the Zydas driver didn't work at 64 bit. Under the 32 bit it didn't work as expected ;-). It connected to a neighbour's network regardless what ESSID I have been setting. At least Zydas published their code under the GPL, so we have a chance to find out, what the driver is doing. Linux drivers for other WLAN USB dongles are delivered with a big library object and a source kernel interface.
Daniel Drake wrote: > How do you feel about the current design of your driver? I feel it is quite right for the task to understand the chip and getting an idea, what is going on. If that would not be a problem, I would not be so explicit. You could discuss for instance the wrapper functions for register accesses. The idea is currently to separate the USB interface, the chip, the RF module, the soft mac and the net device. This way I hope to write a lot of tiny functions, which are easy to understand and not this function monsters of the original driver (TOD). I looked at the soft-mac for the broadcom chip, but it didn't brought much functionality to the table and it had spin locks in every code path, which means we can't sleep waiting for the URB callbacks or we have to create asynchronous work queue functions for everything, making things much more complex. There might be comparable issues with ieee80211 stack, but it has much more functionality, so it makes no sense to ignore it. Not using out-of-kernel modules will make it easier for others to test the drivers and will increase the chances to get into the kernel. > I'm wondering whether you have also found the same - have you developed your > driver and had thoughts that you eventually need to try a new approach? Yes, I have moved things around quite a bit. > I'm still picking up > things, haven't spent a great deal of time looking at the project yet. Maybe my notes_zd1211.txt could help a little bit and zd_chip.h might also give some ideas. Thanks for the pointer regarding the docs. Every piece of information about the chip, will help to get an idea. For instance I got some ideas about the RF chip from the data sheet about the predecessor chip. Otherwise I would not have had any ideas about the serial interface and that register addresses and values are coded in one word. I would also like to know, what all the physical registers are doing and I hope that variance will be not so high as with the software registers controlled by the firmware. I agree that the firmware load sequence is strange, TOD has code which seems to support a kind of auto-address mode, I implemented it and it didn't work. Cheers, Uli -- Ulrich Kunitz - [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
