zd1211 ported to Devicescape stack

zd1211 ported to Devicescape stack

[Michael Wu]

[-- Attachment #1.1: Type: text/plain, Size: 1626 bytes --]

Hi,
	I have finished a port of the zd1211 driver to the Devicescape 802.11 stack. 
Due to the size of the patch, the patch that copies the zd1211 directory to 
the d80211 directory has been omitted, but can be found at my git repo. 
(git://git.kernel.org/pub/scm/linux/kernel/git/mwu/d80211-drivers.git up) The 
two other patches relevant to porting the driver are bzip2ed and attached due 
to size concerns.

This port works fairly well in STA mode, with adhoc and monitor modes to come 
in the future. I tried to minimize changes to the structure of the driver and 
code whenever possible to make it easier to port patches from the softmac 
based zd1211 driver to this driver. However:

	- The original driver does not seem to check if a frame has been successfully 
TXed (as in RXed an ACK), so the port does not properly report to the stack 
whether or not a TX succeeded.
	-Because d80211 does not have complete regulatory domains support yet, the 
associated code was trimmed to the bare minimum of reading the region code. 
It should be a trivial patch to add regulatory domains support once the 
infrastructure is in place in d80211.
	- d80211 doesn't tell us the size of the next fragment, so that part of the 
hardware TX header isn't set anymore. This might be fixed in the future.
	- The LED link status isn't too reliable - I haven't found a way to reliably 
tell if the upper layer thinks it is associated, and I don't know how to use 
the LED api. Not too worried about this issue though.

I will push this to wireless-dev soon if there are no major problems.

Thanks,
-Michael Wu

[-- Attachment #1.2: zd1211-kconfig.bz2 --]
[-- Type: application/x-bzip2, Size: 1229 bytes --]

[-- Attachment #1.3: zd1211-port-to-d80211.bz2 --]
[-- Type: application/x-bzip2, Size: 13210 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: zd1211 ported to Devicescape stack

[Ulrich Kunitz]

Hi Michael,

> 	I have finished a port of the zd1211 driver to the Devicescape 802.11 stack. 

This is absolutely great news. I will look into it and check it
today.

> 	- The original driver does not seem to check if a frame has been successfully 
> TXed (as in RXed an ACK), so the port does not properly report to the stack 
> whether or not a TX succeeded.

TX is atomic. Do you really want to spin for the received ACK? Layer 2 doesn't
need to make any guarantees for packet transmission, so I have
trouble to see the point here. The Linux Device Driver book says
explicitly that packet transmission must not have been completed
at the point in time the function returns.

> 	-Because d80211 does not have complete regulatory domains support yet, the 
> associated code was trimmed to the bare minimum of reading the region code. 

I have to look into it, but the code we had, didn't rely on upper
layer support. I would suggest to maintain it until d80211 has
complete regulatory domains support.

> 	- The LED link status isn't too reliable - I haven't found a way to reliably 
> tell if the upper layer thinks it is associated, and I don't know how to use 
> the LED api. Not too worried about this issue though.

It took us also some time to do it for softmac. But it appears
that the d80211 stack needs still a fair amount of work.

-- 
Uli Kunitz

Re: zd1211 ported to Devicescape stack

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

On Saturday 02 December 2006 08:25, Ulrich Kunitz wrote:
> > 	- The original driver does not seem to check if a frame has been
> > successfully TXed (as in RXed an ACK), so the port does not properly
> > report to the stack whether or not a TX succeeded.
>
> TX is atomic. Do you really want to spin for the received ACK? Layer 2
> doesn't need to make any guarantees for packet transmission, so I have
> trouble to see the point here. The Linux Device Driver book says
> explicitly that packet transmission must not have been completed
> at the point in time the function returns.
>
And it doesn't. Sleeping at that point would be bad. However, the p54 driver 
looks for special frames from the card that report the success/failure of 
sent frames, and adm8211 can tell if a frame was TXed successfully on TX ring 
cleanup. The notification is then done by calling ieee80211_tx_status, not by 
returning an error code. No sleeping necessary. This is needed for the upper 
layer to resend frames and to also do rate control.

> I would suggest to maintain it until d80211 has
> complete regulatory domains support.
>
Why? It's not like any other d80211 drivers have regulatory domains support, 
and they need the exactly the same features that zd1211 needs. Also, the 
limited support for regulatory domains that d80211 does have restricts it to 
channels 1-11 (FCC) regardless, so the code would not be effective.

Thanks,
-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: zd1211 ported to Devicescape stack

[Daniel Drake]

Michael Wu wrote:
> Hi,
> 	I have finished a port of the zd1211 driver to the Devicescape 802.11 stack. 

Yeah!! thanks so much for doing this.

Are you willing to maintain this in terms of porting upcoming patches to 
it? I think I also speak for Ulrich when I say that at the moment we are 
more concerned about getting our work into mainline and don't have time 
to maintain a ported driver, but we will be happy to switch immediately 
as soon as devicescape is declared ready for mainline inclusion.

> 	- The original driver does not seem to check if a frame has been successfully 
> TXed (as in RXed an ACK), so the port does not properly report to the stack 
> whether or not a TX succeeded.

Indeed, the situation is that silence means transmission succeeded, and 
we get a retry_failed interrupt if it didn't.

> 	- d80211 doesn't tell us the size of the next fragment, so that part of the 
> hardware TX header isn't set anymore. This might be fixed in the future.

Even though ieee80211 appeared to have the infrastructure to do so, I 
don't think it was ever passing us multiple fragments. So this is no big 
deal.

> 	- The LED link status isn't too reliable - I haven't found a way to reliably 
> tell if the upper layer thinks it is associated, and I don't know how to use 
> the LED api. Not too worried about this issue though.

Watch out, the single most common bug report for zd1211rw (vs vendor 
driver) was that the LED didn't blink until recently :)

Thanks!
Daniel

Re: zd1211 ported to Devicescape stack

[Ulrich Kunitz]

On 06-12-02 10:58 Daniel Drake wrote:

> Michael Wu wrote:
> >Hi,
> >	I have finished a port of the zd1211 driver to the Devicescape 
> >	802.11 stack. 
> 
> Yeah!! thanks so much for doing this.
> 
> Are you willing to maintain this in terms of porting upcoming patches to 
> it? I think I also speak for Ulrich when I say that at the moment we are 
> more concerned about getting our work into mainline and don't have time 
> to maintain a ported driver, but we will be happy to switch immediately 
> as soon as devicescape is declared ready for mainline inclusion.

I intend to track the d80211 stack, care for the forward porting
and see also a number of things, which should be done for d80211.

- 802.11a support
- better d80211 integration (d80211_tx_status, led stuff)
- cleanups

Daniel your hardware crypto patches should certainly be included
here.

This will make the d80211 driver the development branch and the
mainline driver the maintenance branch. As already stated I intend
care for forwardportsi of the mainline fixes, but IMHO we should
not care to much for backports and backport compatibility. 

-- 
Uli Kunitz

Re: zd1211 ported to Devicescape stack

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

On Saturday 02 December 2006 12:57, Ulrich Kunitz wrote:
> I intend to track the d80211 stack, care for the forward porting
> and see also a number of things, which should be done for d80211.
>
> - 802.11a support
> - better d80211 integration (d80211_tx_status, led stuff)
> - cleanups
>
Great! I expected to handle the patch porting alone, but it's better to have 
someone used to this hardware doing this.

> This will make the d80211 driver the development branch and the
> mainline driver the maintenance branch. As already stated I intend
> care for forwardportsi of the mainline fixes, but IMHO we should
> not care to much for backports and backport compatibility.
I avoided cleanups in the patch to make any patch porting from the mainline 
driver easier, but if it's okay with you, I might make a few zd1211-d80211 
specific clean up patches.

Thanks,
-Michael Wu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: zd1211 ported to Devicescape stack

[Daniel Drake]

Ulrich Kunitz wrote:
> I intend to track the d80211 stack, care for the forward porting
> and see also a number of things, which should be done for d80211.

OK, sorry for the false assumptions in my last mail.

In that case, I guess we should both switch to developing zd1211rw on 
d80211 primarily. I am still interested in seeing stuff in mainline so I 
will spend time backporting some of the new developments (but nothing 
major).

We should also use this opportunity to switch to developing in kernel 
git trees (as opposed to external kernel module git trees) for the 
d80211 port.

To start with, I would ask you to pull my git tree then John (or 
Michael?) would pull from you. We should start this at the point when 
Michael's port enters wireless-dev.git

What do you think?

> Daniel your hardware crypto patches should certainly be included
> here.

The patch only enables hardware decryption and doesn't work completely. 
Needs more work.

Daniel

Re: zd1211 ported to Devicescape stack

[Ulrich Kunitz]

On 06-12-02 13:55 Daniel Drake wrote:

> Ulrich Kunitz wrote:
> >I intend to track the d80211 stack, care for the forward porting
> >and see also a number of things, which should be done for d80211.
> 
> OK, sorry for the false assumptions in my last mail.

It's true, I have not much time during the week to work on it. But
a few hours over the weekend are always possible.

> In that case, I guess we should both switch to developing zd1211rw on 
> d80211 primarily. I am still interested in seeing stuff in mainline so I 
> will spend time backporting some of the new developments (but nothing 
> major).

That's ok. However I wouldn't like to step back from changes
simply to make backporting easier. It doesn't feel like things are
handled in the kernel.

> We should also use this opportunity to switch to developing in kernel 
> git trees (as opposed to external kernel module git trees) for the 
> d80211 port.

It shouldn't surprise you that I'm in violent agreement.

> To start with, I would ask you to pull my git tree then John (or 
> Michael?) would pull from you. We should start this at the point when 
> Michael's port enters wireless-dev.git
> 
> What do you think?

I really liked the way it worked out between both of us. I think
the master branch worked pretty well and we hadn't a lot of
arguments about changes, which were put in there. So I wouldn't
mind if you would continue to handle the upstream also for d80211.
But for now I could agree to maintain the upstream branch. It
it works exactly well between the three of us, Michael could take
over that task also. 

Michael do you agree on a common upstream branch, which only
contains agreed patches?

-- 
Uli Kunitz