Hello, Jouni!

On Tue, 2007-07-31 at 20:33 -0700, Jouni Malinen wrote:

quoted

quoted

quoted

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.

quoted

quoted

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.

quoted

quoted

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.

quoted

quoted

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

quoted

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

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

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.

quoted

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