PCMCIA Bluetooth Card (AnyCom CF - 300) on ARM

[Pavel Roskin]

Hi, Russell!

On Wed, 2005-09-28 at 17:05 +0100, Russell King wrote:
> On Tue, Sep 27, 2005 at 06:55:12PM +0200, Dominik Brodowski wrote:
> > On Tue, Sep 27, 2005 at 07:36:58PM +0300, Itzhak Ben-Akiva wrote:
> > > cardmgr[841]: error in file './config.opts' line 20: invalid port range
> > > 0x60000000-0x60ffffff
> > > cardmgr[841]: no pcmcia driver in /proc/devices
> > > 
> > > include port 0x600-0x60f, though, went ok.
> > 
> > That's a cardmgr bug. Then use this small sysfs shell script instead
> 
> Actually, it's worse than that.
> 
> Sep 28 16:48:43 cps cardmgr[2350]: watching 2 sockets
> Sep 28 16:48:43 cps cardmgr[2350]: could not get CS revision info!
> Sep 28 16:48:43 cps cardmgr[2350]: exiting

You are using old cardmgr.  The one from pcmcia-cs 3.2.8 is fine.  I
think version checking was removed in 3.1.34 series (grep -B8
"unhelpful" CHANGES).

> With 2.6.14-rc2, cardmgr can't even start up, so it can't register
> any memory or IO regions.  Effectively, this has broken the ioctl
> interface _right_ _now_.

Works for me (although I'm using the current netdev branch, it has
2.6.14-rc2 as parent).

> I also believe you are raising the bar to having working PCMCIA too
> much by deprecating the ioctl method in such a short space of time.
> Embedded folks take _years_ to adopt new ideas - some of them haven't
> even adopted things like udev or hotplug yet.

Actually, upgrading the kernel for an embedded system is the hardest
thing by far.  Recompiling userspace application is easy as long that
the cross compiling environment is not messed up.

> You can't force them to do so either - they'll stick with some random
> old kernel version in preference to upgrading to something new.

I do work with embedded systems, and having to upgrade the userspace is
one of the last things holding kernel upgrades, the first thing being
the need to upgrade custom drivers, especially if they are binary-only.

> Can pcmciautils at least work without udev?

I think so, but we should test it.  I'm a bit concerned that
allow_func_id_match is only referenced in hotplug and udev scripts,
which may disallow matching some (admittedly obsolete) devices.

-- 
Regards,
Pavel Roskin