orinoco: create a Kconfig option for Prism2
PATCH 3/3 orinoco: create a Kconfig option for Prism2
Since v2.6.14, Prism 2/2.5/3 devices are better supported using the HostAP driver, which was made to work with these exclusively.
Having the same IDs supported by orinoco too confuses users who have both drivers compiled in or as modules who expect hostap to drive the device.
Telling users to echo to /sys/bus/pci/drivers/*/unbind and bind is not exactly user-friendly.
Create an option to disable support for Prism devices in orinoco driver which disabled the IDs for the PCMCIA module and creates a Kconfig dependency for the Prism PCI modules.
--- drivers/net/wireless/Kconfig | 31 ++++++++++++++++-- drivers/net/wireless/orinoco_cs.c | 60 +++++++++++++++++++------------------ 2 files changed, 58 insertions(+), 33 deletions(-)
drivers/net/wireless/Kconfig +27 -4
@@ -334,9 +334,22 @@ config APPLE_AIRPORT This driver does not support the Airport Extreme (802.11b/g). Use the BCM43xx driver for Airport Extreme cards. +config HERMES_PRISM + bool "Prism 2/2.5 support for Hermes (DEPRECATED)" + depends on HERMES + help + Say Y here to enable support for Intersil HFA384x (Prism 2/2.5) + devices in the Hermes driver. This is discouraged since there nowa + is a separate driver for these chipsets called Host AP. + + Enabling this option is not enough to operate your device with the + Hermes driver; you will need to enable support for PLX9052-based + TMD07160-based, Nortel emobility or Prism 2.5 PCI adapters or the + Prism support for the PCMCIA driver. + config PLX_HERMES tristate "Hermes in PLX9052 based PCI adaptor support (Netgear MA301 etc.)" - depends on PCI && HERMES + depends on PCI && HERMES_PRISM help Enable support for PCMCIA cards supported by the "Hermes" (aka orinoco) driver when used in PLX9052 based PCI adaptors. These
@@ -347,7 +360,7 @@ config PLX_HERMES config TMD_HERMES tristate "Hermes in TMD7160 based PCI adaptor support" - depends on PCI && HERMES + depends on PCI && HERMES_PRISM help Enable support for PCMCIA cards supported by the "Hermes" (aka orinoco) driver when used in TMD7160 based PCI adaptors. These
@@ -357,7 +370,7 @@ config TMD_HERMES config NORTEL_HERMES tristate "Nortel emobility PCI adaptor support" - depends on PCI && HERMES + depends on PCI && HERMES_PRISM help Enable support for PCMCIA cards supported by the "Hermes" (aka orinoco) driver when used in Nortel emobility PCI adaptors. These
@@ -366,7 +379,7 @@ config NORTEL_HERMES config PCI_HERMES tristate "Prism 2.5 PCI 802.11b adaptor support" - depends on PCI && HERMES + depends on PCI && HERMES_PRISM help Enable support for PCI and mini-PCI 802.11b wireless NICs based on the Prism 2.5 chipset. These are true PCI cards, not the 802.11b
@@ -389,6 +402,16 @@ config PCMCIA_HERMES configure your card and that /etc/pcmcia/wireless.opts works: <http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html>. +config PCMCIA_HERMES_PRISM + bool "Prism 2/2.5 PCMCIA card support for Hermes" + depends on PCMCIA_HERMES && HERMES_PRISM + help + Enable support for Prism 2/2.5 (Intersil HFA384x) chipsets in the + Hermes PCMCIA driver. + + Usage of this option is strongly discouraged. You should use the + Host AP driver instead. + config PCMCIA_SPECTRUM tristate "Symbol Spectrum24 Trilogy PCMCIA card support" depends on PCMCIA && HERMES
drivers/net/wireless/orinoco_cs.c +31 -29
115 lines not on this page · raw message
Signature · 1 line
1.5.2.4
Pavel Roskin
NAKQuoted 11 lines · Faidon Liambotis
Since v2.6.14, Prism 2/2.5/3 devices are better supported using the HostAP driver, which was made to work with these exclusively.
Having the same IDs supported by orinoco too confuses users who have both drivers compiled in or as modules who expect hostap to drive the device.Telling users to echo to
/sys/bus/pci/drivers/*/unbindand bind is not exactly user-friendly.Create an option to disable support for Prism devices in orinoco driver which disabled the IDs for the PCMCIA module and creates a
Kconfigdependency for the Prism PCI modules.
NAK.
Nortel cards consist of a bridge and a PCMCIA card with Symbol firmware. Their PCI IDs (0x126c:0x8030 and 0x1562:0x0001) are in hostap_plx, but I really doubt that hostap_plx would even be able to initialize those cards properly, given the fact that it lacks Nortel specific code (look for "118" in orinoco_nortel and hostap_plx).
And even if hostap_plx could initialize the hardware, it would not be able to use it. Support for Agere and Symbol firmware in Hostap is rudimentary at best. It would not even be able to set WEP.
In any case, since your changes are meant to cut support for Prism to firmware from Orinoco, it's wrong deceive users and cut support for Symbol firmware based devices instead.
If you want to pursue this approach, it would be logical to also have an option for hostap to remove support for non-Prism devices. Better yet, it should be removed unconditionally, since it's known to be broken, unlike support for Prism devices in Orinoco.
Now let's consider PLX bridges. There is a great variety of them, and some of them were sold to be used with Orinoco branded cards, i.e. with Agere firmware. Some were sold with Prism based cards. 3com branded cards were likely shipped with cards using Symbol firmware.
It is possible to classify the PCMCIA card by using the PCMCIA configuration space available through the PLX bridge, but the driver would be loaded by then.
In case of TMD cards, even PCMCIA configuration space is not available, so the firmware can only be identified by its version.
Only in case of true PCI cards, orinoco_pci supports the same cards are hostap_pci.
I think we should consider other approaches:
1) Be careful and only cut the IDs for the devices definitely known to have been sold with Prism based cards. In the came time, cut support for Agere and Symbol based devices from hostap.
2) Add code to Orinoco to hand over the devices found to have Prism firmware to hostap. The device would be deinitialized and the bus specific hostap driver (e.g. hostap_plx) would be called the way it's called by the kernel then the device ID matches.
3) Make Orinoco use hostap backend for the cards found to have Prism firmware, i.e. bypass hostap's bus specific modules. That would require quite a lot of impedance matching, but it should be possible.
The later approach is perhaps the most ambitious, but I think it's in the Linux spirit of integrating the drivers rather than keeping them as separate blobs.
Signature · 2 lines
Regards, Pavel Roskin
[I'm adding Jouni to Cc to help us :)]
Quoted 21 lines · Pavel Roskin
Quoted 11 lines · Faidon Liambotis
Since v2.6.14, Prism 2/2.5/3 devices are better supported using the HostAP driver, which was made to work with these exclusively.
Having the same IDs supported by orinoco too confuses users who have both drivers compiled in or as modules who expect hostap to drive the device.Telling users to echo to
/sys/bus/pci/drivers/*/unbindand bind is not exactly user-friendly.Create an option to disable support for Prism devices in orinoco driver which disabled the IDs for the PCMCIA module and creates a
Kconfigdependency for the Prism PCI modules.NAK.
Nortel cards consist of a bridge and a PCMCIA card with Symbol firmware. Their PCI IDs (0x126c:0x8030 and 0x1562:0x0001) are in
hostap_plx, but I really doubt thathostap_plxwould even be able to initialize those cards properly, given the fact that it lacks Nortel specific code (look for "118" inorinoco_nortelandhostap_plx).
Quoted 3 lines
And even if
hostap_plxcould initialize the hardware, it would not be able to use it. Support for Agere and Symbol firmware in Hostap is rudimentary at best. It would not even be able to set WEP.
OK.
I merely compared the PCI IDs. If you're right, hostap claims that it can support devices it can't. We should remove these...
Quoted 35 lines
In any case, since your changes are meant to cut support for Prism to firmware from Orinoco, it's wrong deceive users and cut support for Symbol firmware based devices instead.
If you want to pursue this approach, it would be logical to also have an option for hostap to remove support for non-Prism devices. Better yet, it should be removed unconditionally, since it's known to be broken, unlike support for Prism devices in Orinoco.
Now let's consider PLX bridges. There is a great variety of them, and some of them were sold to be used with Orinoco branded cards, i.e. with Agere firmware. Some were sold with Prism based cards. 3com branded cards were likely shipped with cards using Symbol firmware.
It is possible to classify the PCMCIA card by using the PCMCIA configuration space available through the PLX bridge, but the driver would be loaded by then.
In case of TMD cards, even PCMCIA configuration space is not available, so the firmware can only be identified by its version.
Only in case of true PCI cards,
orinoco_pcisupports the same cards arehostap_pci.I think we should consider other approaches:
1) Be careful and only cut the IDs for the devices definitely known to have been sold with Prism based cards. In the came time, cut support for Agere and Symbol based devices from hostap.
2) Add code to Orinoco to hand over the devices found to have Prism firmware to hostap. The device would be deinitialized and the bus specific hostap driver (e.g.
hostap_plx) would be called the way it's called by the kernel then the device ID matches.
Quoted 7 lines
3) Make Orinoco use hostap backend for the cards found to have Prism firmware, i.e. bypass hostap's bus specific modules. That would require quite a lot of impedance matching, but it should be possible.
The later approach is perhaps the most ambitious, but I think it's in the Linux spirit of integrating the drivers rather than keeping them as separate blobs.
To be honest, I can't imagine people actively working on either of the two drivers. The hardware isn't being sold anymore and the technology (.11b) is two generations behind. And it's not like the drivers aren't working. OTOH, I'm not watching closely, so may be I'm far off. You know better :)
So, I'll sent, if you agree, a patch that only disables orinoco_pci and the PCMCIA IDs. If you know more (a specific ID of a PLX that can definitely work with hostap) please say so. I'll let Jouni comment on the Agere and Symbol rip from hostap.
As for the other solutions, I have none of good knowledge of the drivers, time or motivation for something like that.
I think we should find a solution for now and leave the big plans for when/if they happen.
Regards,
Faidon
Quoted 5 lines · Faidon Liambotis
[I'm adding Jouni to Cc to help us :)]
OK.
I merely compared the PCI IDs. If you're right, hostap claims that it can support devices it can't. We should remove these...
The problem is identifying those IDs, which can require a lot of work. Direct testing would require hardware that's very hard to get.
Quoted 5 lines
To be honest, I can't imagine people actively working on either of the two drivers. The hardware isn't being sold anymore and the technology (.11b) is two generations behind. And it's not like the drivers aren't working.
OTOH, I'm not watching closely, so may be I'm far off. You know better :)
Actually, there is some activity on adding volatile firmware download support for Agere cards and WPA support in Orinoco. There is also a driver for Orinoco USB devices in the Orinoco subversion repository, which will be hopefully merged some day.
I'm working on several other drivers, and I'm already overstretched, but I hope to get back to Orinoco once I can get some other drivers into a good shape.
Quoted 3 lines
So, I'll sent, if you agree, a patch that only disables
orinoco_pciand the PCMCIA IDs. If you know more (a specific ID of a PLX that can definitely work with hostap) please say so.
I'm sorry, but considering your original patch, I just cannot be sure that you will get the PCMCIA IDs right. I cannot be sure I'll get it right myself. It requires a lot of searching and detective work.
Quoted 7 lines
I'll let Jouni comment on the Agere and Symbol rip from hostap.
As for the other solutions, I have none of good knowledge of the drivers, time or motivation for something like that.
I think we should find a solution for now and leave the big plans for when/if they happen.
The problem is that proper ID classification may be harder than the handover. I realize that it's still not trivial.
On the other hand, I haven't heard many complains about the ID clash recently. It seems to me that users learned how to deal with it. Distributions do a great job too. For instance, Fedora renames network devices based on the MAC addresses, so the same configuration will work with either orinoco of hostap.
Of course, those who want to run an 802.11b AP know that they should choose hostap, but most users don't need that.
Signature · 2 lines
Regards, Pavel Roskin
Quoted 3 lines · Pavel Roskin
I'm sorry, but considering your original patch, I just cannot be sure that you will get the PCMCIA IDs right. I cannot be sure I'll get it right myself. It requires a lot of searching and detective work.
We can always begin with the set that is common to both (PCMCIA) drivers.
You're proposing to do nothing but at the same time you say that HostAP claims it can support some cards when it actually doesn't, which is a rather important bug IMHO. I understand that you're maintaining orinoco and not hostap but this is an issue that affects your "users" too, not to mention the overall quality of the kernel.
My patch affected a douzine of PCMCIA IDs, don't you think we can safely correct these?
Quoted 8 lines
On the other hand, I haven't heard many complains about the ID clash recently. It seems to me that users learned how to deal with it. Distributions do a great job too. For instance, Fedora renames network devices based on the MAC addresses, so the same configuration will work with either orinoco of hostap.
Of course, those who want to run an 802.11b AP know that they should choose hostap, but most users don't need that.
You haven't heard many complaints recently because there aren't many users recently...
And this is not about network interface names or AP mode.
You may disagree, but IMO HostAP is a *much* better driver for Prism2 devices in all modes.
And if you have both drivers compiled as modules (as most distributions do) you have to either blacklist orinoco or manually unbind the driver from the hardware using /sys.
I'm maintaining hostap-utils for Debian and we are shipping a blacklist for orinoco for years because of the numerous reports of users who weren't be able to use HostAP. This is suboptimal though, since it breaks (= no driver loaded) when the user actually has a Lucent Orinoco card.
I understand your reluctance but I think it's way past the time you should have passed Prism2 to HostAP.
Best regards,
Faidon
Quoted 11 lines · Faidon Liambotis
Quoted 3 lines · Pavel Roskin
I'm sorry, but considering your original patch, I just cannot be sure that you will get the PCMCIA IDs right. I cannot be sure I'll get it right myself. It requires a lot of searching and detective work.
We can always begin with the set that is common to both (PCMCIA) drivers. You're proposing to do nothing but at the same time you say that HostAP claims it can support some cards when it actually doesn't, which is a rather important bug IMHO.
I understand that you're maintaining orinoco and not hostap but this is an issue that affects your "users" too, not to mention the overall quality of the kernel.
I understand, but I don't have all possible cards, and I depend on what users are reporting. In absence of reports, I prefer to work on things I can actually test.
Quoted 2 lines
My patch affected a douzine of PCMCIA IDs, don't you think we can safely correct these?
0156:0002 alone is going to be a big headache. Basically, you would need to replace it with textual IDs for all Lucent cards and remove the numeric ID.
Quoted 6 lines
Quoted 6 lines
On the other hand, I haven't heard many complains about the ID clash recently. It seems to me that users learned how to deal with it. Distributions do a great job too. For instance, Fedora renames network devices based on the MAC addresses, so the same configuration will work with either orinoco of hostap.
Quoted 8 lines
Quoted 2 lines
Of course, those who want to run an 802.11b AP know that they should choose hostap, but most users don't need that.
You haven't heard many complaints recently because there aren't many users recently...
And this is not about network interface names or AP mode. You may disagree, but IMO HostAP is a *much* better driver for Prism2 devices in all modes.
Well, I agree that there are many things in hostap that are not in orinoco, such as firmware download and WPA.
Quoted 3 lines
And if you have both drivers compiled as modules (as most distributions do) you have to either blacklist orinoco or manually unbind the driver from the hardware using /sys.
The later is true for the drivers compiled into the kernel as well.
Quoted 5 lines
I'm maintaining hostap-utils for Debian and we are shipping a blacklist for orinoco for years because of the numerous reports of users who weren't be able to use HostAP.
This is suboptimal though, since it breaks (= no driver loaded) when the user actually has a Lucent Orinoco card.
I agree, that's suboptimal.
Quoted 2 lines
I understand your reluctance but I think it's way past the time you should have passed Prism2 to HostAP.
I actually hoped that some userspace solution would appear that would make it unnecessary to handle it in the drive.
Signature · 2 lines
Regards, Pavel Roskin
Quoted 1 line · Faidon Liambotis
[I'm adding Jouni to Cc to help us :)]
I may have missed some details from the thread, but couple of comments here anyway..
Quoted 7 lines
Quoted 6 lines · Pavel Roskin
Quoted 5 lines · Faidon Liambotis
Since v2.6.14, Prism 2/2.5/3 devices are better supported using the HostAP driver, which was made to work with these exclusively.
Having the same IDs supported by orinoco too confuses users who have both drivers compiled in or as modules who expect hostap to drive the device.
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Telling users to echo to
/sys/bus/pci/drivers/*/unbindand bind is not exactly user-friendly.Create an option to disable support for Prism devices in orinoco driver which
disabled the IDs for the PCMCIA module and creates aKconfigdependency for
the Prism PCI modules.
This may not be a desirable change from number of reasons if it is likely to get enabled by default in builds.
Quoted 5 lines
Quoted 5 lines
Nortel cards consist of a bridge and a PCMCIA card with Symbol firmware. Their PCI IDs (0x126c:0x8030 and 0x1562:0x0001) are in
hostap_plx, but I really doubt thathostap_plxwould even be able to initialize those cards properly, given the fact that it lacks Nortel specific code (look for "118" inorinoco_nortelandhostap_plx).
Is that special initialization needed for the PLX component or for the PC Card? Can the PC Card be replaced? In other words, if there is even a remote change of someone using that card with a Prism2/2.5/3 PC Card, there may be use for hostap_plx. If this cannot happen, I don't see any point in including the PCI ID for them in hostap_plx. Obviously, I do not have these cards and those have been added based on user reports.
Quoted 4 lines
Quoted 4 lines
If you want to pursue this approach, it would be logical to also have an option for hostap to remove support for non-Prism devices. Better yet, it should be removed unconditionally, since it's known to be broken, unlike support for Prism devices in Orinoco.
I don't think there is much interested in spending time in improving the current Host AP drivers. I certainly do not have plans on more than minimal maintenance. As such, I would object to any kind of unnecessary and risky change unless someone else can claim to have done very through testing on the end result. If someone wants to spend more time with drivers for these old cards, I would suggest looking more into porting the drivers to use net/mac80211 (and to the needed changes to mac80211 to allow this to be done).
Quoted 3 lines
Quoted 3 lines
It is possible to classify the PCMCIA card by using the PCMCIA configuration space available through the PLX bridge, but the driver would be loaded by then.
Recognizing PC Cards is somewhat complex due to re-use of the IDs between various models. This would likely end up being a major task in going through all the cards and collecting the version strings from them and using that to match the driver..
Quoted 1 line
Quoted 1 line
I think we should consider other approaches:
...
4) Implement a new driver for various hermes-like devices using net/mac80211 with support for existing functionality in Host AP and orinoco drivers
Quoted 5 lines
To be honest, I can't imagine people actively working on either of the two drivers. The hardware isn't being sold anymore and the technology (.11b) is two generations behind. And it's not like the drivers aren't working.
OTOH, I'm not watching closely, so may be I'm far off. You know better :)
I would also think it is difficult to get enough activity for any larger change.. These are just not that interesting cards anymore and people have better things to do ;-).
Quoted 4 lines
So, I'll sent, if you agree, a patch that only disables
orinoco_pciand the PCMCIA IDs. If you know more (a specific ID of a PLX that can definitely work with hostap) please say so.
I'll let Jouni comment on the Agere and Symbol rip from hostap.
I wouldn't recommend it, i.e., any patch that does not come with a test report showing no regressions is likely to get NAK'ed.. Obvious one-liner style fixes of removing incorrect IDs is of course welcome, but going much beyond that may not be reasonable at this point.
Quoted 2 lines
I think we should find a solution for now and leave the big plans for when/if they happen.
And only if someone actually shows up with enough interest, motivation, time, and skills to do this..
Signature · 1 line
Jouni Malinen PGP id EFC895FA
Hello, Jouni!
Quoted 8 lines · Jouni Malinen
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Create an option to disable support for Prism devices in orinoco driver which
disabled the IDs for the PCMCIA module and creates aKconfigdependency for
the Prism PCI modules.This may not be a desirable change from number of reasons if it is likely to get enabled by default in builds.
I'm seriously considering dropping orinoco_pci unconditionally. All other cards supported by Orinoco are 16-bit PCMCIA cards. No planned changes for Orinoco will improve orinoco_pci.
This would also solve the problem with DWL-520 rev E, which is only supported by HostAP, but which orinoco_pci matches, because it cannot match a vendor/device combination but exclude a specific subvendor/subdevice.
As for Prism IDs in orinoco_cs, that's a tough call, because there are a lot of IDs, and the probability of error is high.
I would probably keep all PCI-brigde drivers (orinoco_plx, orinoco_tmd and orinoco_nortel). That hardware is rare, and the users may want to try both Orinoco and HostAP.
Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
Nortel cards consist of a bridge and a PCMCIA card with Symbol firmware. Their PCI IDs (0x126c:0x8030 and 0x1562:0x0001) are in
hostap_plx, but I really doubt thathostap_plxwould even be able to initialize those cards properly, given the fact that it lacks Nortel specific code (look for "118" inorinoco_nortelandhostap_plx).Is that special initialization needed for the PLX component or for the PC Card?
It's needed for the bridge, but the bridge is not PLX. It's a completely different device. hostap_plx has PLX and TMD support rolled into one driver, but the Nortel bridge support is not there.
Quoted 4 lines
Can the PC Card be replaced? In other words, if there is even a remote change of someone using that card with a Prism2/2.5/3 PC Card, there may be use for
hostap_plx. If this cannot happen, I don't see any point in including the PCI ID for them inhostap_plx.
I think the cards can be replaced. That's my recollection of the Nortel emobility picture I saw on eBay. However, my point is that hostap_plx lacks the necessary code to initialize the bridge.
Quoted 2 lines
Obviously, I do
not have these cards and those have been added based on user reports.
Well, that's the hard part. I don't know why anyone would want to add the ID of a card that is not working to hostap. But it's possible that the ID came from orinoco_nortel without any testing at all, just because somebody assumed that hostap_plx would handle it. Faidon assumed it, so it's possible someone else could make the same mistake.
Quoted 5 lines
Quoted 4 lines
Quoted 4 lines
If you want to pursue this approach, it would be logical to also have an option for hostap to remove support for non-Prism devices. Better yet, it should be removed unconditionally, since it's known to be broken, unlike support for Prism devices in Orinoco.
Quoted 8 lines
I don't think there is much interested in spending time in improving the current Host AP drivers. I certainly do not have plans on more than minimal maintenance. As such, I would object to any kind of unnecessary and risky change unless someone else can claim to have done very through testing on the end result. If someone wants to spend more time with drivers for these old cards, I would suggest looking more into porting the drivers to use net/mac80211 (and to the needed changes to mac80211 to allow this to be done).
OK, I understand. The situation with Orinoco is similar, although I hope to find time to make some changes.
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
It is possible to classify the PCMCIA card by using the PCMCIA configuration space available through the PLX bridge, but the driver would be loaded by then.
Recognizing PC Cards is somewhat complex due to re-use of the IDs between various models. This would likely end up being a major task in going through all the cards and collecting the version strings from them and using that to match the driver..
I didn't really mean to do it. It was used as a background to better show the problem with TMD bridges, where CIS is not available at all.
Quoted 7 lines
Quoted 1 line
Quoted 1 line
I think we should consider other approaches:
...
4) Implement a new driver for various hermes-like devices using net/mac80211 with support for existing functionality in Host AP and orinoco drivers
That's actually a good idea. The differences between the firmwares would be rather insignificant, since the devices will have to be dumbed down to the level of softmac devices that mindlessly send and receive 802.11 frames.
But I cannot promise that I'll be able to do it myself.
Quoted 9 lines
Quoted 5 lines
To be honest, I can't imagine people actively working on either of the two drivers. The hardware isn't being sold anymore and the technology (.11b) is two generations behind. And it's not like the drivers aren't working.
OTOH, I'm not watching closely, so may be I'm far off. You know better :)I would also think it is difficult to get enough activity for any larger change.. These are just not that interesting cards anymore and people have better things to do ;-).
Exactly. Although porting the driver to mac80211 can be an interesting challenge.
Quoted 9 lines
Quoted 4 lines
So, I'll sent, if you agree, a patch that only disables
orinoco_pciand the PCMCIA IDs. If you know more (a specific ID of a PLX that can definitely work with hostap) please say so.
I'll let Jouni comment on the Agere and Symbol rip from hostap.I wouldn't recommend it, i.e., any patch that does not come with a test report showing no regressions is likely to get NAK'ed.. Obvious one-liner style fixes of removing incorrect IDs is of course welcome, but going much beyond that may not be reasonable at this point.
Agreed.
Quoted 5 lines
Quoted 2 lines
I think we should find a solution for now and leave the big plans for when/if they happen.
And only if someone actually shows up with enough interest, motivation, time, and skills to do this..
I think the handover approach is not "big plans" compared to a mac80211 rewrite. Although it's "big plans" compared to mindless disabling IDs without testing or researching the user messages.
Signature · 2 lines
Regards, Pavel Roskin
Quoted 11 lines · Faidon Liambotis
Since v2.6.14, Prism 2/2.5/3 devices are better supported using the HostAP driver, which was made to work with these exclusively.
Having the same IDs supported by orinoco too confuses users who have both drivers compiled in or as modules who expect hostap to drive the device.Telling users to echo to
/sys/bus/pci/drivers/*/unbindand bind is not exactly user-friendly.Create an option to disable support for Prism devices in orinoco driver which disabled the IDs for the PCMCIA module and creates a
Kconfigdependency for the Prism PCI modules.
I very much dislike this being a compile time only CONFIG option. A module parameter which enables or disables the device IDs would be much nicer, if possible. It can default to off (orinoco will not claim Prism cards).
Signature · 4 lines
David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Quoted 8 lines · David Gibson
Quoted 3 lines
Create an option to disable support for Prism devices in orinoco driver which disabled the IDs for the PCMCIA module and creates a
Kconfigdependency for the Prism PCI modules.I very much dislike this being a compile time only CONFIG option. A module parameter which enables or disables the device IDs would be much nicer, if possible. It can default to off (orinoco will not claim Prism cards).
I'm afraid it's not possible. There is only one device map in the driver, and it's read by depmod to generate module map tables.
If the run-time device table is different from the compile-time table, this would be really confusing. Either the module would be loaded to support the device but would refuse to do so, or the module would need to be loaded manually for some devices, even if no other module is available to support the device.
Besides, orinoco_pci would become useless by default.
Please see my message. For TMD bridges, we don't know the firmware flavor before we know the firmware version. For PLX bridges, we can read the CIS first and match the PCMCIA table, but it would need to be done manually, without the PCMCIA code.
I don't see any clear solution without some kind of the device handover from Orinoco to hostap or vice versa.
I would probably start with cutting Agere and Symbol devices from hostap, which is a much more clear-cut case than cutting working Prism support from Orinoco.
Signature · 2 lines
Regards, Pavel Roskin
Quoted 5 lines · Pavel Roskin
Quoted 4 lines · David Gibson
Quoted 3 lines
Create an option to disable support for Prism devices in orinoco driver which disabled the IDs for the PCMCIA module and creates a
Kconfigdependency for the Prism PCI modules.
Quoted 7 lines
Quoted 4 lines
I very much dislike this being a compile time only CONFIG option. A module parameter which enables or disables the device IDs would be much nicer, if possible. It can default to off (orinoco will not claim Prism cards).
I'm afraid it's not possible. There is only one device map in the driver, and it's read by depmod to generate module map tables.
Ah, yes. Bugger :(
Quoted 14 lines
If the run-time device table is different from the compile-time table, this would be really confusing. Either the module would be loaded to support the device but would refuse to do so, or the module would need to be loaded manually for some devices, even if no other module is available to support the device.
Besides,
orinoco_pciwould become useless by default.Please see my message. For TMD bridges, we don't know the firmware flavor before we know the firmware version. For PLX bridges, we can read the CIS first and match the PCMCIA table, but it would need to be done manually, without the PCMCIA code.
Quoted 6 lines
I don't see any clear solution without some kind of the device handover from Orinoco to hostap or vice versa.
I would probably start with cutting Agere and Symbol devices from hostap, which is a much more clear-cut case than cutting working Prism support from Orinoco.
Hrm. Eck.
I remember once in the distant past Jouni was talking about a possible merge of hostap and orinoco, starting with the low-level device manipulation stuff (hermes.c, basically). But nothing ever came of it.
Signature · 4 lines
David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson