Johannes' ar9170 has been in development for a while.
However he is very busy pushing on the mac80211 stack...
I'll take a bite and try to help with ar9170 kernel inclusion.
before the fatal bit-rot claims a victim.
the diffstat:
MAINTAINERS | 8
drivers/net/wireless/Kconfig | 1
drivers/net/wireless/Makefile | 1
drivers/net/wireless/ar9170/Kconfig | 23
drivers/net/wireless/ar9170/Makefile | 6
drivers/net/wireless/ar9170/ar9170.h | 177 ++++
drivers/net/wireless/ar9170/cmd.c | 118 ++
drivers/net/wireless/ar9170/cmd.h | 87 ++
drivers/net/wireless/ar9170/eeprom.h | 179 ++++
drivers/net/wireless/ar9170/hw.h | 385 +++++++++
drivers/net/wireless/ar9170/led.c | 167 +++
drivers/net/wireless/ar9170/mac.c | 302 +++++++
drivers/net/wireless/ar9170/main.c | 1486 +++++++++++++++++++++++++++++++++++
drivers/net/wireless/ar9170/phy.c | 1223 ++++++++++++++++++++++++++++
drivers/net/wireless/ar9170/usb.c | 754 +++++++++++++++++
drivers/net/wireless/ar9170/usb.h | 80 +
16 files changed, 4997 insertions(+)
obvious fact: that's nearly 5000 lines of code...
I really hope that you guys have a few comments and tips , so we hit 5k ;-)
Please give me some feedback and mmmmooore patches!
And don't forget to update the copyright boilerplate!
Enjoy!
On Friday 20 March 2009 21:13:26 Greg KH wrote:
> On Fri, Mar 20, 2009 at 08:36:08PM +0100, Christian Lamparter wrote:
> > Based on the number of mails I got, this driver should be ready for inclusion.
> > So, this is probably the last RFC and the official patches will follow on
> > sunday (only if no one finds a bug that needs to be fixed ASAP.)
>
> Wonderful!
:-)
> When the driver goes into the "real" portion of drivers/net please let
> me know and I'll drop the otus driver from the drivers/staging/
> location.
Well, I doubt that we can replace Otus, ever...
But it would be nice to tell/warn the otus user (and possible devs)
about the existence of an alternative driver, that does not
TAINT the kernel.
> thanks,
>
> greg k-h
Regards,
Chr
Based on the number of mails I got, this driver should be ready for inclusion.
So, this is probably the last RFC and the official patches will follow on
sunday (only if no one finds a bug that needs to be fixed ASAP.)
Changes:
- enabled HW crypto acceleration (on by default)
- report noise and signal levels in dBm
- sniffer/promiscouous mode now works in BSS
- LED code rework
- fixed last remaining checkpatch.pl ERRORs
Features:
- managed and (full) monitor mode
(other modes may work too... but were not tested)
- QoS
- tx status => automatic rate control
- offload for ccmp, tkip & wep
- programmable LEDs
Note: The whole patch series can be found in the linux-wireless archive.
e.g: http://marc.info/?l=linux-wireless&r=1&b=200903&w=2
Regards,
Chr
---
John what's your verdict? would you accept the driver in its current state?
Hallo Christian!
> Now, what "changes" are you referring to?
I wand see this changes in Johannes' git.
> Most of the qos, hw & rate control changes were already present in
> Johannes' tree.
No rate control like minstrel doesn't work in Johannes' git tree. It ha=
ngs ever at 1 MBit and don't come higher.
> What's missing? Well, there is no BA (fail) & MCS rate report, true..=
=2E
> But under normal operation the rate should go up or down depending on=
the
> current link quality.
>=20
> However, please tell me about your idea. As my way of solving this is=
sue
> properly has some drawbacks (of course, I'm _fully_ aware of them)!
I must test your code first to answer.
Regards
Alina
--=20
Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal gesch=FCtz=
t?
Jetzt absichern: https://homebanking.gmx.net/[email protected]
Hello Christian,
I have now tested your new code with wireless-testing as the complete k=
ernel. It doesn't work and freezes the complete network subsystem. Othe=
r USB sicks like zd1211rw works fine.
Regards
Alina
--=20
Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal gesch=FCtz=
t?
Jetzt absichern: https://homebanking.gmx.net/[email protected]
On Friday 20 March 2009 23:49:20 Alina Friedrichsen wrote:
> > Well, a few features that the vendors uses to encourage potential buyers:
> > - HT ( 802.11n - aka 300mbps )
>
> Hopefully someone can implement it.
Well, first the rate control algorithm needs to support it ;-).
so there's plenty of time to theorize what to do.
> > - AP/AD-Hoc
>
> Ad-Hoc mode with fixed BSSIDs works absolutely fine with this driver. I only didn't find a way to reset the TSF, so that IBSS merges works standard compliant.
>
> In the praxis all mesh networks uses fixed BSSIDs.
Thanks for confirming!
Regards,
Chr
On Friday 20 March 2009 22:25:15 Greg KH wrote:
> On Fri, Mar 20, 2009 at 10:14:51PM +0100, Christian Lamparter wrote:
> > On Friday 20 March 2009 21:13:26 Greg KH wrote:
> > > On Fri, Mar 20, 2009 at 08:36:08PM +0100, Christian Lamparter wrote:
> > > > Based on the number of mails I got, this driver should be ready for inclusion.
> > > > So, this is probably the last RFC and the official patches will follow on
> > > > sunday (only if no one finds a bug that needs to be fixed ASAP.)
> > >
> > > Wonderful!
> > :-)
> >
> > > When the driver goes into the "real" portion of drivers/net please let
> > > me know and I'll drop the otus driver from the drivers/staging/
> > > location.
> > Well, I doubt that we can replace Otus, ever...
>
> Why, what is lacking in the version you have that is in the otus driver?
>
Well, a few features that the vendors uses to encourage potential buyers:
- HT ( 802.11n - aka 300mbps )
- ANI (ambient noise immunity - so it works in noisy environments),
- TPC/DFS (802.11h - crucial if you want to "blast" the 5GHz band
in most countries)
- AP/AD-Hoc
comes to my mind. That said I didn't really look into otus to see which
of these feature actually works as advertised
Nevertheless ar9170 should fit the bill for users with 802.11b/g
accesspoint just fine.
and of course one could always argue that 802.11n is !still! a draft,
5GHz is not very widespread yet, and ANI only helps on very weak links...
However, I suggest that we wait and see what's the situation when
the first ar9170 bits are about to enter vanilla... deal?
Regards,
Chr
On Fri, Mar 20, 2009 at 11:12:57PM +0100, Christian Lamparter wrote:
> On Friday 20 March 2009 22:25:15 Greg KH wrote:
> > On Fri, Mar 20, 2009 at 10:14:51PM +0100, Christian Lamparter wrote:
> > > On Friday 20 March 2009 21:13:26 Greg KH wrote:
> > > > On Fri, Mar 20, 2009 at 08:36:08PM +0100, Christian Lamparter wrote:
> > > > > Based on the number of mails I got, this driver should be ready for inclusion.
> > > > > So, this is probably the last RFC and the official patches will follow on
> > > > > sunday (only if no one finds a bug that needs to be fixed ASAP.)
> > > >
> > > > Wonderful!
> > > :-)
> > >
> > > > When the driver goes into the "real" portion of drivers/net please let
> > > > me know and I'll drop the otus driver from the drivers/staging/
> > > > location.
> > > Well, I doubt that we can replace Otus, ever...
> >
> > Why, what is lacking in the version you have that is in the otus driver?
> >
> Well, a few features that the vendors uses to encourage potential buyers:
> - HT ( 802.11n - aka 300mbps )
> - ANI (ambient noise immunity - so it works in noisy environments),
> - TPC/DFS (802.11h - crucial if you want to "blast" the 5GHz band
> in most countries)
> - AP/AD-Hoc
>
> comes to my mind. That said I didn't really look into otus to see which
> of these feature actually works as advertised
>
> Nevertheless ar9170 should fit the bill for users with 802.11b/g
> accesspoint just fine.
>
> and of course one could always argue that 802.11n is !still! a draft,
> 5GHz is not very widespread yet, and ANI only helps on very weak links...
>
> However, I suggest that we wait and see what's the situation when
> the first ar9170 bits are about to enter vanilla... deal?
Sounds good to me, let me know what you want to do then.
thanks,
greg k-h
On Friday 20 March 2009 21:07:36 Alina Friedrichsen wrote:
> Hello Christian!
Hello!
> > Based on the number of mails I got, this driver should be ready for
> > inclusion.
>
> ACK
Good ;-)
> > So, this is probably the last RFC and the official patches will follow on
> > sunday (only if no one finds a bug that needs to be fixed ASAP.)
>
> This is not same driver. Its much different, and I couldn't follow the changes in Johannes' git repository.
Well, the USB code was rewritten & "outsourced" into a separate module...
I did that because:
1. we might want to replace most of the "common" code with portions of ath9k.
(no one, except Atheros' developers can really us with ANI/BC/HT/
ABOLT/VAP etc. ;-) )
2. The otus driver talks about SPI devices. So maybe one day, we will need to
add another frontend for the people with a handhelds or tablet with such a
chip.
Now, what "changes" are you referring to?
Most of the qos, hw & rate control changes were already present in Johannes' tree.
And all I did was moving lines from other mac80211 driver around. :)
> Today, if have implement rate control (the needed ieee80211_tx_status_irqsafe() calls) for the original code. Now after one hour this code already outdated. :/
well, this "rate control" code was already part of the first RFC...
which was posted earlier this week?!
> In your code the implementation of it is not yet complete?
What's missing? Well, there is no BA (fail) & MCS rate report, true...
But under normal operation the rate should go up or down depending on the
current link quality.
However, please tell me about your idea. As my way of solving this issue
properly has some drawbacks (of course, I'm _fully_ aware of them)!
Regards,
Chr
On Fri, Mar 20, 2009 at 10:14:51PM +0100, Christian Lamparter wrote:
> On Friday 20 March 2009 21:13:26 Greg KH wrote:
> > On Fri, Mar 20, 2009 at 08:36:08PM +0100, Christian Lamparter wrote:
> > > Based on the number of mails I got, this driver should be ready for inclusion.
> > > So, this is probably the last RFC and the official patches will follow on
> > > sunday (only if no one finds a bug that needs to be fixed ASAP.)
> >
> > Wonderful!
> :-)
>
> > When the driver goes into the "real" portion of drivers/net please let
> > me know and I'll drop the otus driver from the drivers/staging/
> > location.
> Well, I doubt that we can replace Otus, ever...
Why, what is lacking in the version you have that is in the otus driver?
thanks,
greg k-h
On Fri, Mar 20, 2009 at 08:36:08PM +0100, Christian Lamparter wrote:
> Based on the number of mails I got, this driver should be ready for inclusion.
> So, this is probably the last RFC and the official patches will follow on
> sunday (only if no one finds a bug that needs to be fixed ASAP.)
Wonderful!
When the driver goes into the "real" portion of drivers/net please let
me know and I'll drop the otus driver from the drivers/staging/
location.
thanks,
greg k-h
Hello Christian!
> Based on the number of mails I got, this driver should be ready for
> inclusion.
ACK
> So, this is probably the last RFC and the official patches will follow on
> sunday (only if no one finds a bug that needs to be fixed ASAP.)
This is not same driver. Its much different, and I couldn't follow the changes in Johannes' git repository.
Today, if have implement rate control (the needed ieee80211_tx_status_irqsafe() calls) for the original code. Now after one hour this code already outdated. :/
In your code the implementation of it is not yet complete?
Regards
Alina
--
Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal gesch?tzt?
Jetzt absichern: https://homebanking.gmx.net/[email protected]
On Sat, 2009-03-21 at 15:59 +0100, Alina Friedrichsen wrote:
> Hello Christian,
>
> your new code is not compatible with compat-wireless. The function
> usb_poison_anchored_urbs() is missing in the 2.6.27 kernel.
That's something compat has to fix then -- we don't impose any backward
compatibility rules for the kernel code.
johannes
Hello Johannes!
> > your new code is not compatible with compat-wireless. The function
> > usb_poison_anchored_urbs() is missing in the 2.6.27 kernel.
>=20
> That's something compat has to fix then -- we don't impose any backwa=
rd
> compatibility rules for the kernel code.
ACK, I only want advert on this.
Regards
Alina
--=20
Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal gesch=FCtz=
t?
Jetzt absichern: https://homebanking.gmx.net/[email protected]
Hello!
> Well, a few features that the vendors uses to encourage potential buy=
ers:
> - HT ( 802.11n - aka 300mbps )
Hopefully someone can implement it.
> - AP/AD-Hoc=20
Ad-Hoc mode with fixed BSSIDs works absolutely fine with this driver. I=
only didn't find a way to reset the TSF, so that IBSS merges works sta=
ndard compliant.
In the praxis all mesh networks uses fixed BSSIDs.
Regards
Alina
--=20
Psssst! Schon vom neuen GMX MultiMessenger geh=F6rt? Der kann`s mit all=
en: http://www.gmx.net/de/go/multimessenger
Hello Christian,
your new code is not compatible with compat-wireless. The function usb_=
poison_anchored_urbs() is missing in the 2.6.27 kernel.
Regards
Alina
--=20
Aufgepasst: Sind Ihre Daten beim Online-Banking auch optimal gesch=FCtz=
t?
Jetzt absichern: https://homebanking.gmx.net/[email protected]