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.
Signed-off-by: Faidon Liambotis <[email protected]>
---
drivers/net/wireless/Kconfig | 31 ++++++++++++++++--
drivers/net/wireless/orinoco_cs.c | 60 +++++++++++++++++++------------------
2 files changed, 58 insertions(+), 33 deletions(-)
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index cfcaf5c..54c0568 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -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
diff --git a/drivers/net/wireless/orinoco_cs.c b/drivers/net/wireless/orinoco_cs.c
index d1e5022..78688f3 100644
--- a/drivers/net/wireless/orinoco_cs.c
+++ b/drivers/net/wireless/orinoco_cs.c
@@ -442,76 +442,80 @@ static char version[] __initdata = DRIVER_NAME " " DRIVER_VERSION
"Pavel Roskin <[email protected]>, et al)";
static struct pcmcia_device_id orinoco_cs_ids[] = {
+#ifdef CONFIG_PCMCIA_HERMES_PRISM
PCMCIA_DEVICE_MANF_CARD(0x000b, 0x7100), /* SonicWALL Long Range Wireless Card */
PCMCIA_DEVICE_MANF_CARD(0x000b, 0x7300), /* Sohoware NCP110, Philips 802.11b */
- PCMCIA_DEVICE_MANF_CARD(0x0089, 0x0002), /* AnyPoint(TM) Wireless II PC Card */
PCMCIA_DEVICE_MANF_CARD(0x0101, 0x0777), /* 3Com AirConnect PCI 777A */
PCMCIA_DEVICE_MANF_CARD(0x0126, 0x8000), /* PROXIM RangeLAN-DS/LAN PC CARD */
PCMCIA_DEVICE_MANF_CARD(0x0138, 0x0002), /* Compaq WL100 11 Mbps Wireless Adapter */
+ PCMCIA_DEVICE_MANF_CARD(0x0250, 0x0002), /* Samsung SWL2000-N 11Mb/s WLAN Card */
+ PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1612), /* Linksys WPC11 Version 2.5 */
+ PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1613), /* Linksys WPC11 Version 3 */
+ PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0002), /* Compaq HNW-100 11 Mbps Wireless Adapter */
+ PCMCIA_DEVICE_MANF_CARD(0x02aa, 0x0002), /* ASUS SpaceLink WL-100 */
+ PCMCIA_DEVICE_MANF_CARD(0x50c2, 0x7300), /* Airvast WN-100 */
+ PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0002), /* Safeway 802.11b, ZCOMAX AirRunner/XI-300 */
+ PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0005), /* D-Link DCF660, Sandisk Connect SDWCFB-000 */
+ PCMCIA_DEVICE_PROD_ID12("ACTIONTEC", "PRISM Wireless LAN PC Card", 0x393089da, 0xa71e69d5),
+ PCMCIA_DEVICE_PROD_ID12("Allied Telesyn", "AT-WCL452 Wireless PCMCIA Radio", 0x5cd01705, 0x4271660f),
+ PCMCIA_DEVICE_PROD_ID12("BUFFALO", "WLI-CF-S11G", 0x2decece3, 0x82067c18),
+ PCMCIA_DEVICE_PROD_ID12("Compaq", "WL200_11Mbps_Wireless_PCI_Card", 0x54f7c49c, 0x15a75e5b),
+ PCMCIA_DEVICE_PROD_ID123("corega", "WL PCCL-11", "ISL37300P", 0x0a21501a, 0x59868926, 0xc9049a39),
+ PCMCIA_DEVICE_PROD_ID12("D", "Link DWL-650 11Mbps WLAN Card", 0x71b18589, 0xb6f1b0ab),
+ PCMCIA_DEVICE_PROD_ID123("Instant Wireless ", " Network PC CARD", "Version 01.02", 0x11d901af, 0x6e9bd926, 0x4b74baa0),
+ PCMCIA_DEVICE_PROD_ID12("Intel", "PRO/Wireless 2011 LAN PC Card", 0x816cc815, 0x07f58077),
+ PCMCIA_DEVICE_PROD_ID12("INTERSIL", "HFA384x/IEEE", 0x74c5e40d, 0xdb472a18),
+ PCMCIA_DEVICE_PROD_ID12("INTERSIL", "I-GATE 11M PC Card / PC Card plus", 0x74c5e40d, 0x8304ff77),
+ PCMCIA_DEVICE_PROD_ID12("Intersil", "PRISM 2_5 PCMCIA ADAPTER", 0x4b801a17, 0x6345a0bf),
+ PCMCIA_DEVICE_PROD_ID123("Intersil", "PRISM Freedom PCMCIA Adapter", "ISL37100P", 0x4b801a17, 0xf222ec2d, 0x630d52b2),
+ PCMCIA_DEVICE_PROD_ID12("Linksys", "Wireless CompactFlash Card", 0x0733cc81, 0x0c52f395),
+ PCMCIA_DEVICE_PROD_ID12("NETGEAR MA401 Wireless PC", "Card", 0xa37434e9, 0x9762e8f1),
+ PCMCIA_DEVICE_PROD_ID12("NETGEAR MA401RA Wireless PC", "Card", 0x0306467f, 0x9762e8f1),
+ PCMCIA_DEVICE_PROD_ID12("Nortel Networks", "emobility 802.11 Wireless LAN PC Card", 0x2d617ea0, 0x88cd5767),
+ PCMCIA_DEVICE_PROD_ID12("OEM", "PRISM2 IEEE 802.11 PC-Card", 0xfea54c90, 0x48f2bdd6),
+ PCMCIA_DEVICE_PROD_ID123("PCMCIA", "11M WLAN Card v2.5", "ISL37300P", 0x281f1c5d, 0x6e440487, 0xc9049a39),
+ PCMCIA_DEVICE_PROD_ID123("The Linksys Group, Inc.", "Instant Wireless Network PC Card", "ISL37300P", 0xa5f472c2, 0x590eb502, 0xc9049a39),
+ PCMCIA_DEVICE_PROD_ID12("ZoomAir 11Mbps High", "Rate wireless Networking", 0x273fe3db, 0x32a1eaee),
+#endif
+ PCMCIA_DEVICE_MANF_CARD(0x0089, 0x0002), /* AnyPoint(TM) Wireless II PC Card */
PCMCIA_DEVICE_MANF_CARD(0x0156, 0x0002), /* Lucent Orinoco and old Intersil */
PCMCIA_DEVICE_MANF_CARD(0x016b, 0x0001), /* Ericsson WLAN Card C11 */
PCMCIA_DEVICE_MANF_CARD(0x01eb, 0x080a), /* Nortel Networks eMobility 802.11 Wireless Adapter */
PCMCIA_DEVICE_MANF_CARD(0x01ff, 0x0008), /* Intermec MobileLAN 11Mbps 802.11b WLAN Card */
- PCMCIA_DEVICE_MANF_CARD(0x0250, 0x0002), /* Samsung SWL2000-N 11Mb/s WLAN Card */
PCMCIA_DEVICE_MANF_CARD(0x0261, 0x0002), /* AirWay 802.11 Adapter (PCMCIA) */
PCMCIA_DEVICE_MANF_CARD(0x0268, 0x0001), /* ARtem Onair */
PCMCIA_DEVICE_MANF_CARD(0x026f, 0x0305), /* Buffalo WLI-PCM-S11 */
- PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1612), /* Linksys WPC11 Version 2.5 */
- PCMCIA_DEVICE_MANF_CARD(0x0274, 0x1613), /* Linksys WPC11 Version 3 */
- PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0002), /* Compaq HNW-100 11 Mbps Wireless Adapter */
PCMCIA_DEVICE_MANF_CARD(0x028a, 0x0673), /* Linksys WCF12 Wireless CompactFlash Card */
- PCMCIA_DEVICE_MANF_CARD(0x02aa, 0x0002), /* ASUS SpaceLink WL-100 */
PCMCIA_DEVICE_MANF_CARD(0x02ac, 0x0002), /* SpeedStream SS1021 Wireless Adapter */
PCMCIA_DEVICE_MANF_CARD(0x14ea, 0xb001), /* PLANEX RoadLannerWave GW-NS11H */
- PCMCIA_DEVICE_MANF_CARD(0x50c2, 0x7300), /* Airvast WN-100 */
PCMCIA_DEVICE_MANF_CARD(0x9005, 0x0021), /* Adaptec Ultra Wireless ANW-8030 */
PCMCIA_DEVICE_MANF_CARD(0xc001, 0x0008), /* CONTEC FLEXSCAN/FX-DDS110-PCC */
PCMCIA_DEVICE_MANF_CARD(0xc250, 0x0002), /* Conceptronic CON11Cpro, EMTAC A2424i */
- PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0002), /* Safeway 802.11b, ZCOMAX AirRunner/XI-300 */
- PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0005), /* D-Link DCF660, Sandisk Connect SDWCFB-000 */
PCMCIA_DEVICE_PROD_ID12(" ", "IEEE 802.11 Wireless LAN/PC Card", 0x3b6e20c8, 0xefccafe9),
PCMCIA_DEVICE_PROD_ID12("3Com", "3CRWE737A AirConnect Wireless LAN PC Card", 0x41240e5b, 0x56010af3),
- PCMCIA_DEVICE_PROD_ID12("ACTIONTEC", "PRISM Wireless LAN PC Card", 0x393089da, 0xa71e69d5),
PCMCIA_DEVICE_PROD_ID12("Addtron", "AWP-100 Wireless PCMCIA", 0xe6ec52ce, 0x08649af2),
PCMCIA_DEVICE_PROD_ID123("AIRVAST", "IEEE 802.11b Wireless PCMCIA Card", "HFA3863", 0xea569531, 0x4bcb9645, 0x355cb092),
- PCMCIA_DEVICE_PROD_ID12("Allied Telesyn", "AT-WCL452 Wireless PCMCIA Radio", 0x5cd01705, 0x4271660f),
PCMCIA_DEVICE_PROD_ID12("ASUS", "802_11b_PC_CARD_25", 0x78fc06ee, 0xdb9aa842),
PCMCIA_DEVICE_PROD_ID12("ASUS", "802_11B_CF_CARD_25", 0x78fc06ee, 0x45a50c1e),
PCMCIA_DEVICE_PROD_ID12("Avaya Communication", "Avaya Wireless PC Card", 0xd8a43b78, 0x0d341169),
PCMCIA_DEVICE_PROD_ID12("BENQ", "AWL100 PCMCIA ADAPTER", 0x35dadc74, 0x01f7fedb),
PCMCIA_DEVICE_PROD_ID12("BUFFALO", "WLI-PCM-L11G", 0x2decece3, 0xf57ca4b3),
- PCMCIA_DEVICE_PROD_ID12("BUFFALO", "WLI-CF-S11G", 0x2decece3, 0x82067c18),
PCMCIA_DEVICE_PROD_ID12("Cabletron", "RoamAbout 802.11 DS", 0x32d445f5, 0xedeffd90),
- PCMCIA_DEVICE_PROD_ID12("Compaq", "WL200_11Mbps_Wireless_PCI_Card", 0x54f7c49c, 0x15a75e5b),
- PCMCIA_DEVICE_PROD_ID123("corega", "WL PCCL-11", "ISL37300P", 0x0a21501a, 0x59868926, 0xc9049a39),
PCMCIA_DEVICE_PROD_ID12("corega K.K.", "Wireless LAN PCC-11", 0x5261440f, 0xa6405584),
PCMCIA_DEVICE_PROD_ID12("corega K.K.", "Wireless LAN PCCA-11", 0x5261440f, 0xdf6115f9),
PCMCIA_DEVICE_PROD_ID12("corega_K.K.", "Wireless_LAN_PCCB-11", 0x29e33311, 0xee7a27ae),
PCMCIA_DEVICE_PROD_ID12("D", "Link DRC-650 11Mbps WLAN Card", 0x71b18589, 0xf144e3ac),
- PCMCIA_DEVICE_PROD_ID12("D", "Link DWL-650 11Mbps WLAN Card", 0x71b18589, 0xb6f1b0ab),
PCMCIA_DEVICE_PROD_ID12("D-Link Corporation", "D-Link DWL-650H 11Mbps WLAN Adapter", 0xef544d24, 0xcd8ea916),
PCMCIA_DEVICE_PROD_ID12("Digital Data Communications", "WPC-0100", 0xfdd73470, 0xe0b6f146),
PCMCIA_DEVICE_PROD_ID12("ELSA", "AirLancer MC-11", 0x4507a33a, 0xef54f0e3),
PCMCIA_DEVICE_PROD_ID12("HyperLink", "Wireless PC Card 11Mbps", 0x56cc3f1a, 0x0bcf220c),
- PCMCIA_DEVICE_PROD_ID123("Instant Wireless ", " Network PC CARD", "Version 01.02", 0x11d901af, 0x6e9bd926, 0x4b74baa0),
- PCMCIA_DEVICE_PROD_ID12("Intel", "PRO/Wireless 2011 LAN PC Card", 0x816cc815, 0x07f58077),
- PCMCIA_DEVICE_PROD_ID12("INTERSIL", "HFA384x/IEEE", 0x74c5e40d, 0xdb472a18),
- PCMCIA_DEVICE_PROD_ID12("INTERSIL", "I-GATE 11M PC Card / PC Card plus", 0x74c5e40d, 0x8304ff77),
- PCMCIA_DEVICE_PROD_ID12("Intersil", "PRISM 2_5 PCMCIA ADAPTER", 0x4b801a17, 0x6345a0bf),
- PCMCIA_DEVICE_PROD_ID123("Intersil", "PRISM Freedom PCMCIA Adapter", "ISL37100P", 0x4b801a17, 0xf222ec2d, 0x630d52b2),
PCMCIA_DEVICE_PROD_ID12("LeArtery", "SYNCBYAIR 11Mbps Wireless LAN PC Card", 0x7e3b326a, 0x49893e92),
- PCMCIA_DEVICE_PROD_ID12("Linksys", "Wireless CompactFlash Card", 0x0733cc81, 0x0c52f395),
PCMCIA_DEVICE_PROD_ID12("Lucent Technologies", "WaveLAN/IEEE", 0x23eb9949, 0xc562e72a),
PCMCIA_DEVICE_PROD_ID12("MELCO", "WLI-PCM-L11", 0x481e0094, 0x7360e410),
PCMCIA_DEVICE_PROD_ID12("MELCO", "WLI-PCM-L11G", 0x481e0094, 0xf57ca4b3),
PCMCIA_DEVICE_PROD_ID12("Microsoft", "Wireless Notebook Adapter MN-520", 0x5961bf85, 0x6eec8c01),
PCMCIA_DEVICE_PROD_ID12("NCR", "WaveLAN/IEEE", 0x24358cd4, 0xc562e72a),
- PCMCIA_DEVICE_PROD_ID12("NETGEAR MA401 Wireless PC", "Card", 0xa37434e9, 0x9762e8f1),
- PCMCIA_DEVICE_PROD_ID12("NETGEAR MA401RA Wireless PC", "Card", 0x0306467f, 0x9762e8f1),
- PCMCIA_DEVICE_PROD_ID12("Nortel Networks", "emobility 802.11 Wireless LAN PC Card", 0x2d617ea0, 0x88cd5767),
- PCMCIA_DEVICE_PROD_ID12("OEM", "PRISM2 IEEE 802.11 PC-Card", 0xfea54c90, 0x48f2bdd6),
PCMCIA_DEVICE_PROD_ID12("OTC", "Wireless AirEZY 2411-PCC WLAN Card", 0x4ac44287, 0x235a6bed),
- PCMCIA_DEVICE_PROD_ID123("PCMCIA", "11M WLAN Card v2.5", "ISL37300P", 0x281f1c5d, 0x6e440487, 0xc9049a39),
PCMCIA_DEVICE_PROD_ID12("PLANEX", "GeoWave/GW-CF110", 0x209f40ab, 0xd9715264),
PCMCIA_DEVICE_PROD_ID12("PLANEX", "GeoWave/GW-NS110", 0x209f40ab, 0x46263178),
PCMCIA_DEVICE_PROD_ID12("PROXIM", "LAN PC CARD HARMONY 80211B", 0xc6536a5e, 0x090c3cd9),
@@ -520,8 +524,6 @@ static struct pcmcia_device_id orinoco_cs_ids[] = {
PCMCIA_DEVICE_PROD_ID12("SMC", "SMC2532W-B EliteConnect Wireless Adapter", 0xc4f8b18b, 0x196bd757),
PCMCIA_DEVICE_PROD_ID12("SMC", "SMC2632W", 0xc4f8b18b, 0x474a1f2a),
PCMCIA_DEVICE_PROD_ID12("Symbol Technologies", "LA4111 Spectrum24 Wireless LAN PC Card", 0x3f02b4d6, 0x3663cb0e),
- PCMCIA_DEVICE_PROD_ID123("The Linksys Group, Inc.", "Instant Wireless Network PC Card", "ISL37300P", 0xa5f472c2, 0x590eb502, 0xc9049a39),
- PCMCIA_DEVICE_PROD_ID12("ZoomAir 11Mbps High", "Rate wireless Networking", 0x273fe3db, 0x32a1eaee),
PCMCIA_DEVICE_NULL,
};
MODULE_DEVICE_TABLE(pcmcia, orinoco_cs_ids);
--
1.5.2.4
On Wed, 2007-07-25 at 09:19 +0300, Faidon Liambotis wrote:
> Pavel Roskin wrote:
> > 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.
> 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.
> > 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.
Well, I agree that there are many things in hostap that are not in
orinoco, such as firmware download and WPA.
> 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.
> 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.
> 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.
--
Regards,
Pavel Roskin
On Mon, 2007-07-23 at 11:42 +1000, David Gibson wrote:
> > 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.
>
> 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.
--
Regards,
Pavel Roskin
On Sun, 2007-07-22 at 16:17 +0300, Faidon Liambotis wrote:
> 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.
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.
--
Regards,
Pavel Roskin
On Sun, Jul 22, 2007 at 04:17:51PM +0300, Faidon Liambotis wrote:
> 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.
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).
--
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
On Mon, Jul 23, 2007 at 02:10:40AM -0400, Pavel Roskin wrote:
> On Mon, 2007-07-23 at 11:42 +1000, David Gibson wrote:
> > > 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.
> >
> > 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 :(
>
> 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.
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.
--
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
[I'm adding Jouni to Cc to help us :)]
Pavel Roskin wrote:
> On Sun, 2007-07-22 at 16:17 +0300, Faidon Liambotis wrote:
>> 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.
>
> 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.
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...
> 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.
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
Pavel Roskin wrote:
> 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?
> 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
On Tue, 2007-07-24 at 01:07 +0300, Faidon Liambotis wrote:
> [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.
> 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.
> 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'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.
> 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.
--
Regards,
Pavel Roskin
Hello, Jouni!
On Tue, 2007-07-31 at 20:33 -0700, Jouni Malinen wrote:
> > >>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.
>
> 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.
> > >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).
>
> 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.
> 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.
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.
> 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.
> > >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).
OK, I understand. The situation with Orinoco is similar, although I
hope to find time to make some changes.
> > >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.
> > >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.
> > 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.
> > 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.
>
> 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.
> > 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.
--
Regards,
Pavel Roskin
On Tue, Jul 24, 2007 at 01:07:27AM +0300, Faidon Liambotis wrote:
> [I'm adding Jouni to Cc to help us :)]
I may have missed some details from the thread, but couple of comments
here anyway..
> Pavel Roskin wrote:
> >On Sun, 2007-07-22 at 16:17 +0300, Faidon Liambotis wrote:
> >>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.
This may not be a desirable change from number of reasons if it is
likely to get enabled by default in builds.
> >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).
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.
> >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).
> >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 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
> 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 ;-).
> 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.
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.
> 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..
--
Jouni Malinen PGP id EFC895FA