5.4-REL && pcmcia card Option N.V. Fusion UMTS Quad-GPRS

[Andrew Gordon]

On Fri, 30 Sep 2005 guru at Sisis.de wrote:
>
> one thing remains; with Linux I used an UMTS PCMCIA card which Linux
> attaches without any problems to some 'usbserial' module with the
> commands:
>
>     # /sbin/modprobe -r usbserial
>     # /sbin/insmod usbserial vendor=0xaf0 product=0x6300

I have a rather similar device (again supplied by Vodafone), only mine has
product ID 0x5000 compared to the 0x6300 on yours (both have vendor
0xaf0).

Note that these cards are internally organized as a Cardbus->USB hub, and
then the actual radio as a USB device 'plugged' into that hub.
Your dmesg shows that the Cardbus side of things is working fine, but
there's no driver for the USB device: it's getting the default 'ugen'
device rather than anything more specific.

> I saw that FreeBSD comes with a kernel module ucom.ko, but it
> does not help to load it;

You will want ucom, but that's not the whole story.  ucom itself is a
meta-driver supporting the common aspects of USB->serial adapters in
general, with an additional module needed for each of the tediously
not-quite-the-same devices that different manufacturers have come up with.

Fortunately, most of these differences relate to things like setting the
baud rate, which aren't important here.

I hacked up a crude driver to make my card work by making a copy of the
'uftdi' driver and ripping the guts out of it (not because this card has
anything in common with the FTDI chips, just that I happen to know a lot
about them and hence know my way around the uftdi driver - any of the
other ucom sub-drivers would work equally well).

The resulting driver works reasonably well; the one flaw is that it
doesn't know how to drive DTR, which causes PPP to complain and means that
it can't forcibly reset things - this isn't a serious problem in practice.

The other problem area is the fact that you can't eject this card: this is
a generic problem for USB hubs on cardbus cards - they are always active
(polling) even when not 'in use', and there's no mechanism to shut down
the ohci driver before ejecting.


Unfortunately, my hack was done back on about FreeBSD 5.2, and I believe
there was some problem when I attempted to upgrade to something marginally
more recent (about a year ago); to get to something more modern it's
probably better to start again from scratch with a contemporary uftdi (or
other ucom subdriver).