Add prism 2/3 usb adaptor firmware for use with staging/wlan-ng driver.
PATCH 1/1 Add prism 2/3 usb adaptor firmware for use with staging/wlan-ng driver.
---
This firmware file can be installed and used as-is - it doesn't need any special pre-compilation since it is processed into the appropriate binary blob for the card by the driver itself.
As far as is known, the last copyright holder of this firmware was Conexant and that they were freely distributed.
The file prism2_ru.hex is renamed from ru010803.hex, a
secondary (STA/Adhoc/HostAP mode) firmware images for Prism 2/3 USB adapters
WHENCE | 24 + prism2_ru.hex | 3788 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 3812 insertions(+), 0 deletions(-) create mode 100644 prism2_ru.hex
WHENCE +24 -0
@@ -920,3 +920,27 @@ Source: usbdux/usbdux_firmware.asm Licence: GPLv2. See source code in usbdux/ subdirectory. Provided from the author, Bernd Porr <[email protected]> + +-------------------------------------------------------------------------- + +Driver: staging/wlan-ng - prism 2/3 usb 802.11 wireless lan adapters + +File: prism2_ru.hex + +License: + +The following binary firmware files are (c) Conexant, and do not fall +under the GPL or MPL. They are assumed to have the same license as +their windows client drivers, ie everyone who bought a card that came +with a windows driver already has a copy of and license to use the +necessary firmware, albeit possibly an older version. These were bundled +with linux-wlan-ng for convenience only, as many newer adapters +(eg Prism 3 w/SSF) require a firmware download in order to function at +all. + +As far as is known, the last copyright holder of these +binaries was Conexant and that they were freely distributed. + +The file prism2_ru.hex is renamed from ru010803.hex, a +secondary (STA/Adhoc/HostAP mode) firmware images for Prism 2/3 USB adapters +
prism2_ru.hex new file +3788 -0
2,973 lines not on this page · raw message
The rest of this diff is not shown. View the raw message.
Signature · 1 line
1.6.0.4
Part of the diff is not shown here. View the raw message.
Quoted 2 lines · Karl Relton
Signed-off-by Karl ReltonSigned-off-by Mark S. Mathews
The commit log is empty. Where is this driver? Is it in staging at least? If so does this get users of the driver a usable firmware? What is the future of the driver BTW?
Luis
Quoted 9 lines · Luis R. Rodriguez
Quoted 2 lines · Karl Relton
Signed-off-by Karl ReltonSigned-off-by Mark S. MathewsThe commit log is empty. Where is this driver? Is it in staging at least? If so does this get users of the driver a usable firmware? What is the future of the driver BTW?
Oops - put text in wrong part of patch documentation. I can move this up to the 'commit log' part.
The driver is under 'staging' - maintained by Greg Koah-Hartman
The firmware blob in 'srec' format for prism 2/3 usb adaptors. The driver will read the srec file using a standard request_firmware() call, and will convert it into the appropriate binary format and upload to the adaptor. Note the processing is left to the driver (rather than pre-compiling) because the driver needs to insert runtime data obtained from the adaptor into the blob. The appropriate insertion locations are conveyed by the srec format.
Karl
Quoted 16 lines · Karl Relton
Quoted 9 lines · Luis R. Rodriguez
Quoted 2 lines · Karl Relton
Signed-off-by Karl ReltonSigned-off-by Mark S. MathewsThe commit log is empty. Where is this driver? Is it in staging at least? If so does this get users of the driver a usable firmware? What is the future of the driver BTW?
Oops - put text in wrong part of patch documentation. I can move this up to the 'commit log' part.
The driver is under 'staging' - maintained by Greg Koah-Hartman
Quoted 7 lines
The firmware blob in 'srec' format for prism 2/3 usb adaptors. The driver will read the srec file using a standard
request_firmware()call, and will convert it into the appropriate binary format and upload to the adaptor. Note the processing is left to the driver (rather than pre-compiling) because the driver needs to insert runtime data obtained from the adaptor into the blob. The appropriate insertion locations are conveyed by the srec format.
Why all the srec->binary conversion? Doesn't this waste space on people's firmware directories?
Luis
Quoted 26 lines · Luis R. Rodriguez
Quoted 16 lines · Karl Relton
Quoted 9 lines · Luis R. Rodriguez
Quoted 2 lines · Karl Relton
Signed-off-by Karl ReltonSigned-off-by Mark S. MathewsThe commit log is empty. Where is this driver? Is it in staging at least? If so does this get users of the driver a usable firmware? What is the future of the driver BTW?
Oops - put text in wrong part of patch documentation. I can move this up to the 'commit log' part.
The driver is under 'staging' - maintained by Greg Koah-Hartman
Quoted 7 lines
The firmware blob in 'srec' format for prism 2/3 usb adaptors. The driver will read the srec file using a standard
request_firmware()call, and will convert it into the appropriate binary format and upload to the adaptor. Note the processing is left to the driver (rather than pre-compiling) because the driver needs to insert runtime data obtained from the adaptor into the blob. The appropriate insertion locations are conveyed by the srec format.
Quoted 3 lines
Why all the
srec->binaryconversion? Doesn't this waste space on people's firmware directories?
Yes, technically it does. The srec file is ~185KB, a binary image would be ~64KB.
The reason it was left is that the driver has to do some runtime plugging of data into the image, so pre-compilation would have meant inventing both a compiler tool and an intermediate format for the driver to read and process. Putting all the srec processing in the driver was more expedient (just meant porting existing userspace code into driver space).
Karl
Quoted 27 lines · Karl Relton
Quoted 26 lines · Luis R. Rodriguez
Quoted 23 lines · Karl Relton
Quoted 9 lines · Luis R. Rodriguez
Quoted 2 lines · Karl Relton
Signed-off-by Karl ReltonSigned-off-by Mark S. MathewsThe commit log is empty. Where is this driver? Is it in staging at least? If so does this get users of the driver a usable firmware? What is the future of the driver BTW?
Oops - put text in wrong part of patch documentation. I can move this up to the 'commit log' part.
The driver is under 'staging' - maintained by Greg Koah-Hartman
The firmware blob in 'srec' format for prism 2/3 usb adaptors. The driver will read the srec file using a standard
request_firmware()call, and will convert it into the appropriate binary format and upload to the adaptor. Note the processing is left to the driver (rather than pre-compiling) because the driver needs to insert runtime data obtained from the adaptor into the blob. The appropriate insertion locations are conveyed by the srec format.
Quoted 8 lines
Quoted 3 lines
Why all the
srec->binaryconversion? Doesn't this waste space on people's firmware directories?Yes, technically it does. The srec file is ~185KB, a binary image would be ~64KB.
The reason it was left is that the driver has to do some runtime plugging of data into the image
Can you elaborate on this a little. Does the driver currently take the srec file, append/prepend some data onto it and then run it on the target CPU?
Quoted 3 lines
, so pre-compilation would have meant
inventing both a compiler tool and an intermediate format for the driver to read and process.
The srec->binary conversion just needs to be done once, and not sure what the "extra" stuff is that you mention is required, but if its always the same can't that just be put into a final binary file?
Quoted 3 lines
Putting all the srec processing in the driver was
more expedient (just meant porting existing userspace code into driver space).
At the cost of a firmware file size 3 times the size of the binary file.
Luis
Quoted 3 lines · Luis R. Rodriguez
Can you elaborate on this a little. Does the driver currently take the srec file, append/prepend some data onto it and then run it on the target CPU?
Some data in the srec file is replaced by the data read from the card (so called plug data area, or PDA). "Plugging" refers to that process.
Quoted 7 lines
Quoted 3 lines
, so pre-compilation would have meant
inventing both a compiler tool and an intermediate format for the driver to read and process.The
srec->binaryconversion just needs to be done once, and not sure what the "extra" stuff is that you mention is required, but if its always the same can't that just be put into a final binary file?
We can use the same format as Spectrum firmware used in spectrum_cs, and reuse its parser/plugger. Spectrum and Prism chipsets are related and use the same idea of plugging, but Prism firmware is distributed as srec files, whereas Spectrum firmware is cut from binary drivers as a binary.
Signature · 2 lines
Regards, Pavel Roskin
Quoted 7 lines · Karl Relton
Quoted 3 lines · Luis R. Rodriguez
Why all the
srec->binaryconversion? Doesn't this waste space on people's firmware directories?Yes, technically it does. The srec file is ~185KB, a binary image would be ~64KB.
Quoted 6 lines
The reason it was left is that the driver has to do some runtime plugging of data into the image, so pre-compilation would have meant inventing both a compiler tool and an intermediate format for the driver to read and process. Putting all the srec processing in the driver was more expedient (just meant porting existing userspace code into driver space).
I can't find the wlan_ng request_firmware call in my wireless-testing tree (week or so old). Is that new?
Quoted 1 line
From what I can tell the
wlan_ng, hostap and orinoco drivers all program
firmware that has the same basic format. Hostap doesn't use request_firmware, and gives userspace the control over the write sequence. orinoco places a very simple header in front of the binary image.
Do we really want to add srec processing to the driver (or even the kernel)?
It would be nice if the FW image was in the same format for orinoco and wlan_ng, as the prism firmware ought to work on non-USB prism cards, and we should be able to make orinoco use it.
Regards,
Dave.
Quoted 23 lines · Dave
Quoted 7 lines · Karl Relton
Quoted 3 lines · Luis R. Rodriguez
Why all the
srec->binaryconversion? Doesn't this waste space on people's firmware directories?Yes, technically it does. The srec file is ~185KB, a binary image would be ~64KB.
Quoted 6 lines
The reason it was left is that the driver has to do some runtime plugging of data into the image, so pre-compilation would have meant inventing both a compiler tool and an intermediate format for the driver to read and process. Putting all the srec processing in the driver was more expedient (just meant porting existing userspace code into driver space).
I can't find the
wlan_ngrequest_firmwarecall in my wireless-testing tree (week or so old). Is that new?From what I can tell the
wlan_ng, hostap and orinoco drivers all program firmware that has the same basic format. Hostap doesn't userequest_firmware, and gives userspace the control over the write sequence. orinoco places a very simple header in front of the binary image.
Quoted 5 lines
Do we really want to add srec processing to the driver (or even the kernel)?
It would be nice if the FW image was in the same format for orinoco and
wlan_ng, as the prism firmware ought to work on non-USB prism cards, and we should be able to make orinoco use it.
I never got the wlan_ng stuff.. Anyway now it is under drivers/staging/wlan-ng. I was under the impression it targeted some devices not covered by hostapd or orinoco, is that no the case?
Luis
Quoted 26 lines · Luis R. Rodriguez
Quoted 25 lines · Dave
Quoted 7 lines · Karl Relton
Quoted 3 lines · Luis R. Rodriguez
Why all the
srec->binaryconversion? Doesn't this waste space on people's firmware directories?Yes, technically it does. The srec file is ~185KB, a binary image would be ~64KB.
Quoted 6 lines
The reason it was left is that the driver has to do some runtime plugging of data into the image, so pre-compilation would have meant inventing both a compiler tool and an intermediate format for the driver to read and process. Putting all the srec processing in the driver was more expedient (just meant porting existing userspace code into driver space).
I can't find the
wlan_ngrequest_firmwarecall in my wireless-testing tree (week or so old). Is that new?From what I can tell the
wlan_ng, hostap and orinoco drivers all program firmware that has the same basic format. Hostap doesn't userequest_firmware, and gives userspace the control over the write sequence. orinoco places a very simple header in front of the binary image.Do we really want to add srec processing to the driver (or even the kernel)?
Quoted 7 lines
Quoted 3 lines
It would be nice if the FW image was in the same format for orinoco and
wlan_ng, as the prism firmware ought to work on non-USB prism cards, and we should be able to make orinoco use it.I never got the
wlan_ngstuff.. Anyway now it is underdrivers/staging/wlan-ng. I was under the impression it targeted some devices not covered by hostapd or orinoco, is that no the case?
It targets USB devices. Neither orinoco or hostap handle USB devices, largely because USB is asynchronous and neither orinoco or hostap are built to communicate with the firmware asynchronously. I'm a bit skeptical of linux-wlan-ng ever getting out of staging because it really, really should be ported to hostap, but if that doesn't happen, it should really really get ported to cfg80211 first to ensure we don't just add *another* WEXT implementation to the pool. That's really all I care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.
Dan
Insist on cfg80211 for new drivers?
Quoted 3 lines · Dan Williams
That's really all I
care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.
Now there is a discussion we should have had in Berlin...is it time to insist on cfg80211-based configuration for all new drivers?
John
Signature · 3 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready. ¡Viva Honduras Libre!
Re: Insist on cfg80211 for new drivers?
Quoted 8 lines · John W. Linville
Quoted 3 lines · Dan Williams
That's really all I
care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.Now there is a discussion we should have had in Berlin...is it time to insist on cfg80211-based configuration for all new drivers?
Otherwise they get sent to staging? :)
Luis
Re: Insist on cfg80211 for new drivers?
In reply to John W. LinvilleQuoted 8 lines · John W. Linville
Quoted 3 lines · Dan Williams
That's really all I
care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.Now there is a discussion we should have had in Berlin...is it time to insist on cfg80211-based configuration for all new drivers?
Can't imagine there would have been much discussion on that with the crowd that was there -- I think we should. In fact, on the notes was "publish a wext deprecation statement" or something like that.
Just like we insist that nobody adds an entirely new wireless stack, we should insist that nobody add a new way of interpreting wext commands.
johannes
Re: Insist on cfg80211 for new drivers?
In reply to John W. LinvilleQuoted 7 lines · John W. Linville
Quoted 3 lines · Dan Williams
That's really all I
care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.Now there is a discussion we should have had in Berlin...
Yes, we missed this one.
Quoted 2 lines
is it time to insist on cfg80211-based configuration for all new drivers?
I vote for yes. In my books wext is depreceated and its use should be avoided. After Johannes' excellent work we need to start pushing the use of cfg80211 and nl80211.
Signature · 1 line
Kalle Valo
Re: Insist on cfg80211 for new drivers?
In reply to John W. LinvilleHi John,
Quoted 6 lines
Quoted 3 lines
That's really all I
care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.Now there is a discussion we should have had in Berlin...is it time to insist on cfg80211-based configuration for all new drivers?
there is really nothing much to discuss on this topic. The plan is to deprecate WEXT, that simple. So if the driver has no cfg80211 support, then it will not be included. Period.
Send such drivers off to staging and let them have their 6 month. Then we either remove them again or they got ported to cfg80211.
Regards
Marcel
Re: Insist on cfg80211 for new drivers?
Quoted 9 lines · Marcel Holtmann
Hi John,
Quoted 6 lines
Quoted 3 lines
That's really all I
care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.Now there is a discussion we should have had in Berlin...is it time to insist on cfg80211-based configuration for all new drivers?
Quoted 6 lines
there is really nothing much to discuss on this topic. The plan is to deprecate WEXT, that simple. So if the driver has no cfg80211 support, then it will not be included. Period.
Send such drivers off to staging and let them have their 6 month. Then we either remove them again or they got ported to cfg80211.
6 months only in staging ? Is this a rule now for staging?
Luis
Re: Insist on cfg80211 for new drivers?
Hi Luis,
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
That's really all I
care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.Now there is a discussion we should have had in Berlin...is it time to insist on cfg80211-based configuration for all new drivers?
Quoted 8 lines
Quoted 6 lines
there is really nothing much to discuss on this topic. The plan is to deprecate WEXT, that simple. So if the driver has no cfg80211 support, then it will not be included. Period.
Send such drivers off to staging and let them have their 6 month. Then we either remove them again or they got ported to cfg80211.
6 months only in staging ? Is this a rule now for staging?
that is what Greg mentioned to me. If there is no activity for 6 month and the driver is not getting anywhere, he going to drop it.
Regards
Marcel
Re: Insist on cfg80211 for new drivers?
Quoted 13 lines · Marcel Holtmann
Hi Luis,
Quoted 11 lines
Quoted 11 lines
Quoted 6 lines
Quoted 3 lines
That's really all I
care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.Now there is a discussion we should have had in Berlin...is it time to insist on cfg80211-based configuration for all new drivers?
there is really nothing much to discuss on this topic. The plan is to deprecate WEXT, that simple. So if the driver has no cfg80211 support, then it will not be included. Period.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Send such drivers off to staging and let them have their 6 month. Then we either remove them again or they got ported to cfg80211.
6 months only in staging ? Is this a rule now for staging?
that is what Greg mentioned to me. If there is no activity for 6 month and the driver is not getting anywhere, he going to drop it.
That is "within reason". If a driver is still needed there, I'l probably keep it, and will take each one on a case-by-case basis.
thanks,
greg k-h
Re: Insist on cfg80211 for new drivers?
Hi Greg,
Quoted 14 lines
Quoted 14 lines
Quoted 14 lines
Quoted 13 lines
Quoted 6 lines
Quoted 3 lines
That's really all I
care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.Now there is a discussion we should have had in Berlin...is it time to insist on cfg80211-based configuration for all new drivers?
there is really nothing much to discuss on this topic. The plan is to deprecate WEXT, that simple. So if the driver has no cfg80211 support, then it will not be included. Period.
Send such drivers off to staging and let them have their 6 month. Then we either remove them again or they got ported to cfg80211.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
6 months only in staging ? Is this a rule now for staging?
that is what Greg mentioned to me. If there is no activity for 6 month and the driver is not getting anywhere, he going to drop it.
That is "within reason". If a driver is still needed there, I'l probably keep it, and will take each one on a case-by-case basis.
what do you mean "within reason". If the driver is just sitting there and no effort in making in upstream ready it is doing clearly more harm than any good. And I am not talking about removing some kernel version details or typedefs or coding style. Drivers with missing cfg80211 need active porting. And it is not that hard. See the orinoco one for an example.
If we see developers committed to fixing it that is a different story, but a lot of drivers in staging are getting no attention all. So they are fully pointless and are not doing any good for Linux. We need to send the vendors a clear message that code drops of their crappy Windows code are not desired.
Regards
Marcel
Re: Insist on cfg80211 for new drivers?
Quoted 21 lines · Marcel Holtmann
Hi Greg,
Quoted 19 lines
Quoted 18 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
That's really all I
care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.Now there is a discussion we should have had in Berlin...is it time to insist on cfg80211-based configuration for all new drivers?
Quoted 8 lines
Quoted 6 lines
there is really nothing much to discuss on this topic. The plan is to deprecate WEXT, that simple. So if the driver has no cfg80211 support, then it will not be included. Period.
Send such drivers off to staging and let them have their 6 month. Then we either remove them again or they got ported to cfg80211.
6 months only in staging ? Is this a rule now for staging?
that is what Greg mentioned to me. If there is no activity for 6 month and the driver is not getting anywhere, he going to drop it.
Quoted 6 lines
Quoted 2 lines
That is "within reason". If a driver is still needed there, I'l probably keep it, and will take each one on a case-by-case basis.
what do you mean "within reason". If the driver is just sitting there and no effort in making in upstream ready it is doing clearly more harm than any good.
Who is it "harming"? You? no.
Quoted 3 lines
And I am not talking about removing some kernel version details or typedefs or coding style. Drivers with missing cfg80211 need active porting. And it is not that hard. See the orinoco one for an example.
Let me know if anything needs to be ported/fixed in the staging directory. Never use anything in that directory as a reason to not change any kernel apis, I will always fix up things as needed.
Quoted 5 lines
If we see developers committed to fixing it that is a different story, but a lot of drivers in staging are getting no attention all. So they are fully pointless and are not doing any good for Linux. We need to send the vendors a clear message that code drops of their crappy Windows code are not desired.
Oh yeah, "clear messages", I'm _sure_ that would get through to them...
{sigh}
Seriously, I will take each driver on a case-by-case basis.
thanks,
greg k-h
Re: Insist on cfg80211 for new drivers?
In reply to Marcel HoltmannHi,
Quoted 21 lines · On Thursday 02 July 2009 00:18:49 Marcel Holtmann wrote:
Hi Greg,
Quoted 19 lines
Quoted 18 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
That's really all I
care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.Now there is a discussion we should have had in Berlin...is it time to insist on cfg80211-based configuration for all new drivers?
Quoted 8 lines
Quoted 6 lines
there is really nothing much to discuss on this topic. The plan is to deprecate WEXT, that simple. So if the driver has no cfg80211 support, then it will not be included. Period.
Send such drivers off to staging and let them have their 6 month. Then we either remove them again or they got ported to cfg80211.
6 months only in staging ? Is this a rule now for staging?
that is what Greg mentioned to me. If there is no activity for 6 month and the driver is not getting anywhere, he going to drop it.
Quoted 7 lines
Quoted 2 lines
That is "within reason". If a driver is still needed there, I'l probably keep it, and will take each one on a case-by-case basis.
what do you mean "within reason". If the driver is just sitting there and no effort in making in upstream ready it is doing clearly more harm than any good. And I am not talking about removing some kernel version details or typedefs or coding style. Drivers with missing cfg80211 need
Well, most of those drivers need a major cleanup before porting..
Quoted 2 lines
active porting. And it is not that hard. See the orinoco one for an example.
Could you please provide some more pointers here, I don't see any such changes in linux-next yet and I'm very interested in seeing a practical example of such conversion (thanks!).
Quoted 5 lines
If we see developers committed to fixing it that is a different story, but a lot of drivers in staging are getting no attention all. So they are fully pointless and are not doing any good for Linux. We need to send the vendors a clear message that code drops of their crappy Windows code are not desired.
How's about sending a clear _positive_ message for a change?
Where one can find an up to date documentation for {mac,cfg,nl}80211 (not just some random DocBook generated excerpts, I mean the real thing here, with references to kernel versions when API changes were introduced, some practical examples and exemplary drivers) and more importantly when one can find the _porting_ guide for the older stacks?
Thanks,
Bart
Re: Insist on cfg80211 for new drivers?
Quoted 32 lines · Bartlomiej Zolnierkiewicz
Hi,
Quoted 21 lines · On Thursday 02 July 2009 00:18:49 Marcel Holtmann wrote:
Hi Greg,
Quoted 19 lines
Quoted 18 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
That's really all I
care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.Now there is a discussion we should have had in Berlin...is it time to insist on cfg80211-based configuration for all new drivers?
Quoted 8 lines
Quoted 6 lines
there is really nothing much to discuss on this topic. The plan is to deprecate WEXT, that simple. So if the driver has no cfg80211 support, then it will not be included. Period.
Send such drivers off to staging and let them have their 6 month. Then we either remove them again or they got ported to cfg80211.
6 months only in staging ? Is this a rule now for staging?
that is what Greg mentioned to me. If there is no activity for 6 month and the driver is not getting anywhere, he going to drop it.
Quoted 7 lines
Quoted 2 lines
That is "within reason". If a driver is still needed there, I'l probably keep it, and will take each one on a case-by-case basis.
what do you mean "within reason". If the driver is just sitting there and no effort in making in upstream ready it is doing clearly more harm than any good. And I am not talking about removing some kernel version details or typedefs or coding style. Drivers with missing cfg80211 need
Quoted 8 lines
Well, most of those drivers need a major cleanup before porting..
Quoted 2 lines
active porting. And it is not that hard. See the orinoco one for an example.
Could you please provide some more pointers here, I don't see any such changes in linux-next yet and I'm very interested in seeing a practical example of such conversion (thanks!).
http://osdir.com/ml/linux-wireless/2009-06/msg01141.html
It's not in -next, it's in wireless-testing, which gets dumped to next periodically. Wireless stuff happens first in wireless-testing, of course.
Quoted 6 lines
Quoted 5 lines
If we see developers committed to fixing it that is a different story, but a lot of drivers in staging are getting no attention all. So they are fully pointless and are not doing any good for Linux. We need to send the vendors a clear message that code drops of their crappy Windows code are not desired.
Quoted 7 lines
How's about sending a clear _positive_ message for a change?
Where one can find an up to date documentation for {mac,cfg,nl}80211 (not just some random DocBook generated excerpts, I mean the real thing here, with references to kernel versions when API changes were introduced, some practical examples and exemplary drivers) and more importantly when one can find the _porting_ guide for the older stacks?
Johannes has done an much-better-than-average job of documenting cfg80211 and nl80211, which is more than I can say for many other subsystems.
Dan
Re: Insist on cfg80211 for new drivers?
In reply to Marcel HoltmannQuoted 2 lines · Marcel Holtmann
that is what Greg mentioned to me. If there is no activity for 6 month and the driver is not getting anywhere, he going to drop it.
If that were true and not just an excuse the whole initial batch and a couple of later drivers would be gone now.
Re: Insist on cfg80211 for new drivers?
In reply to John W. LinvilleQuoted 8 lines · John W. Linville
Quoted 3 lines · Dan Williams
That's really all I
care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.Now there is a discussion we should have had in Berlin...is it time to insist on cfg80211-based configuration for all new drivers?
Should we publish something like this:
http://wireless.kernel.org/wext-statement (don't want it indexed by google yet so you need to log on to view it), for example on lwn? Just so more application developers are also aware.
johannes
Re: Insist on cfg80211 for new drivers?
Quoted 7 lines · Johannes Berg
Quoted 6 lines · John W. Linville
Quoted 3 lines · Dan Williams
That's really all I
care about, I don't want another WEXT-based driver accepted; I want all the new ones using cfg80211.
Quoted 7 lines
Quoted 2 lines
Now there is a discussion we should have had in Berlin...is it time to insist on cfg80211-based configuration for all new drivers?
Should we publish something like this:
http://wireless.kernel.org/wext-statement (don't want it indexed by google yet so you need to log on to view it), for example on lwn? Just so more application developers are also aware.
Yes, that seems fine to me.
John
Signature · 3 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready. ¡Viva Honduras Libre!
Re: Insist on cfg80211 for new drivers?
In reply to Johannes BergQuoted 5 lines · Johannes Berg
Should we publish something like this:
http://wireless.kernel.org/wext-statement (don't want it indexed by google yet so you need to log on to view it), for example on lwn? Just so more application developers are also aware.
I made one small grammatical change. In English, "between" is used when dealing with two entities and "among" if more than two. As there are more than two drivers that share cfg80211 features and code...
Otherwise it looks great, and I certainly subscribe to the idea behind it.
Larry
Re: Insist on cfg80211 for new drivers?
Quoted 10 lines · Larry Finger
Quoted 5 lines · Johannes Berg
Should we publish something like this:
http://wireless.kernel.org/wext-statement (don't want it indexed by google yet so you need to log on to view it), for example on lwn? Just so more application developers are also aware.I made one small grammatical change. In English, "between" is used when dealing with two entities and "among" if more than two. As there are more than two drivers that share cfg80211 features and code...
Subtle! Thanks Larry, I wasn't aware of this distinction.
johannes
Re: Insist on cfg80211 for new drivers?
2009/7/6 Johannes Berg <[email protected]>:
Quoted 8 lines · Larry Finger
Quoted 7 lines
Quoted 5 lines · Johannes Berg
Should we publish something like this:
http://wireless.kernel.org/wext-statement (don't want it indexed by google yet so you need to log on to view it), for example on lwn? Just so more application developers are also aware.
Quoted 8 lines
Quoted 3 lines
I made one small grammatical change. In English, "between" is used when dealing with two entities and "among" if more than two. As there are more than two drivers that share cfg80211 features and code...
Subtle! Thanks Larry, I wasn't aware of this distinction.
johannes
Another small change...
As such, drivers written without cfg80211 -> As such, drivers written without cfg80211 support
Looks fine to me too ;-)
Signature · 3 lines
GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick
Quoted 33 lines · Karl Relton
Quoted 26 lines · Luis R. Rodriguez
Quoted 16 lines · Karl Relton
Quoted 9 lines · Luis R. Rodriguez
Quoted 2 lines · Karl Relton
Signed-off-by Karl ReltonSigned-off-by Mark S. MathewsThe commit log is empty. Where is this driver? Is it in staging at least? If so does this get users of the driver a usable firmware? What is the future of the driver BTW?
Oops - put text in wrong part of patch documentation. I can move this up to the 'commit log' part.
The driver is under 'staging' - maintained by Greg Koah-Hartman
Quoted 7 lines
The firmware blob in 'srec' format for prism 2/3 usb adaptors. The driver will read the srec file using a standard
request_firmware()call, and will convert it into the appropriate binary format and upload to the adaptor. Note the processing is left to the driver (rather than pre-compiling) because the driver needs to insert runtime data obtained from the adaptor into the blob. The appropriate insertion locations are conveyed by the srec format.Quoted 3 lines
Why all the
srec->binaryconversion? Doesn't this waste space on people's firmware directories?Yes, technically it does. The srec file is ~185KB, a binary image would be ~64KB.
Quoted 6 lines
The reason it was left is that the driver has to do some runtime plugging of data into the image, so pre-compilation would have meant inventing both a compiler tool and an intermediate format for the driver to read and process. Putting all the srec processing in the driver was more expedient (just meant porting existing userspace code into driver space).
The kernel has support for a binary form of srec files (well, of ihex files, which are fairly much the same thing).
See include/linux/ihex.h and firmware/ihex2fw.c.
Signature · 2 lines
David Woodhouse Open Source Technology Centre [email protected] Intel Corporation
Quoted 41 lines · David Woodhouse
Quoted 33 lines · Karl Relton
Quoted 26 lines · Luis R. Rodriguez
Quoted 16 lines · Karl Relton
Quoted 9 lines · Luis R. Rodriguez
Quoted 2 lines · Karl Relton
Signed-off-by Karl ReltonSigned-off-by Mark S. MathewsThe commit log is empty. Where is this driver? Is it in staging at least? If so does this get users of the driver a usable firmware? What is the future of the driver BTW?
Oops - put text in wrong part of patch documentation. I can move this up to the 'commit log' part.
The driver is under 'staging' - maintained by Greg Koah-Hartman
Quoted 7 lines
The firmware blob in 'srec' format for prism 2/3 usb adaptors. The driver will read the srec file using a standard
request_firmware()call, and will convert it into the appropriate binary format and upload to the adaptor. Note the processing is left to the driver (rather than pre-compiling) because the driver needs to insert runtime data obtained from the adaptor into the blob. The appropriate insertion locations are conveyed by the srec format.Quoted 3 lines
Why all the
srec->binaryconversion? Doesn't this waste space on people's firmware directories?Yes, technically it does. The srec file is ~185KB, a binary image would be ~64KB.
Quoted 6 lines
The reason it was left is that the driver has to do some runtime plugging of data into the image, so pre-compilation would have meant inventing both a compiler tool and an intermediate format for the driver to read and process. Putting all the srec processing in the driver was more expedient (just meant porting existing userspace code into driver space).
Quoted 5 lines
The kernel has support for a binary form of srec files (well, of ihex files, which are fairly much the same thing).
See
include/linux/ihex.handfirmware/ihex2fw.c.
Hi David
Thanks for this info.
Assuming the necessary work was done to suitably pre-process srec to a binary, would the firmware image (with its currently somewhat ambiguous license statement) be allowed into linux-firmware anyway, or would it simply not pass the criteria you need to apply?
Karl
Quoted 10 lines · Karl Relton
WHENCE +10
-0+ +-------------------------------------------------------------------------- + +Driver: staging/wlan-ng - prism 2/3 usb 802.11 wireless lan adapters + +File: prism2_ru.hex + +License: + +The following binary firmware files are (c) Conexant, and do not fall
WHENCE Source: usbdux/usbdux_firmware.asm · line 942
Quoted 10 lines
WHENCE +10
-0+under the GPL or MPL. They are assumed to have the same license as +their windows client drivers, ie everyone who bought a card that came +with a windows driver already has a copy of and license to use the +necessary firmware, albeit possibly an older version. These were bundled +with linux-wlan-ng for convenience only, as many newer adapters +(eg Prism 3 w/SSF) require a firmware download in order to function at +all. + +As far as is known, the last copyright holder of these +binaries was Conexant and that they were freely distributed.
Is this really good enough? What is the difference between the above and cutting firmware images out of the (freely distributed) Broadcom drivers for Windows?
John
Signature · 3 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready. ¡Viva Honduras Libre!