Using the "best available" driver

[Dominik Brodowski]

Hi,

On Wed, Dec 07, 2005 at 12:00:43PM -0800, Jean Tourrilhes wrote:
> 	A blacklist is clearly not good enough. I already told you that.
> 	Example :
> 	The Orinoco driver support both Orinoco, Symbol and Prism2 cards
> 	The HostAP driver support only Prism2 cards. It has more
> features than the Orinoco driver, by is twice as large (footprint).
> 	I have 2 Pcmcia slot, I insert both a Orinoco and a Prism2
> cards (yes, I can really do that on my PC). I usually want the Orinoco
> card to be driver by the Orinoco driver, and the Prism2 card driven
> with the HostAP driver. For debugging the Orinoco driver, sometimes I
> want to bind the Orinoco driver to the Orinoco driver.
> 	Obviously, on my Gumstix, I want to use the Orinoco driver
> with my CF card.
> 	As you can see, this kind of stuff is clearly not doable with
> a dumb blacklist. And it's also not doable with a module
> removal/reinsertion.

But it's doable with that sysfs unbind/bind magic :-)

> 	Note that with kernel 2.6.15, the above setup does not work
> with cardmgr, while it was working before (2.4.X). Whichever driver
> was loaded first try to manage both card, which most often does not
> work (HostAP can not drive an Orinoco card).

Uh, what IDs in the list in 
linux-2.6/drivers/net/wireless/hostap/hostap_cs.c reflect to Orinoco cards
which hostap cannot "drive"? Then these entries are invalid and must be
removed ASAP.

> 	Please acknowledge the people are trying to use your code in
> way that may not make sense to you, but it's not because we are being
> pedantic, it's because we *NEED* it. Thanks.

I acknowledge it, and I try to show them how it's possible to manage it --
and there are various ways (for those running just one card, module
blacklist, and for those running multiple cards with different requirements,
unbind/bind) to solve this issue. I'm open to other ideas or even patches to
add additional ways.

> > > 	The sysfs commands are fine, but they are rather obscure, and
> > > are not persistent. What would be nice is to have a list associating
> > > cards IDs with the driver needed. Not an axhaustive list, but just the
> > > user override. Then, each time the card is loaded, the hotplug script
							     ^^^^^^^

First of all, hotplug is going away -- but let's assume udev:

> > > would do the necessary magic to get the right driver binded (and
> > > potentially unload the uncessary driver).

You can add udev rules to do the unbind/bind for you - untested:

ACTION=="add", RUN+="/sbin/check_blacklist $devpath $env{BUS}"


#/bin/bash
$drivername = basename $(readlink /sys/$1/driver)
$device = basename $1
$wrong_driver = "some_driver"
$right_driver = "new_driver"

if [ $2 == "pcmcia" ]; then
	if [ $device == "1.0" ]; then
		if [ $drivername == $wrong_driver ]; then
			echo -n "$device" > /sys/$devpath/driver/unbind
			echo -n "$device" > /sys/bus/$2/$right_driver/driver/bind
		fi;
	fi;
fi;


Untested, and of course only valid for one device, but easily extendable.


> > The actual removal will take a few months more, I suspect, but that's the
> > plan yes. And with the easy /etc/modprobe.conf blacklisting method as well
> > as the "rmmod X && sleep 1 && modprobe Y" being available immediately after
> > the IOCTL is gone I don't think that this is a blocking issue. Do you agree?
> 
> 	Well, because it's already broken in 2.6.15, this issue
> obviously does not block the removal of the ioctl.

There are many ways to achieve what you want, so I wouldn't consider it
"broken". Maybe it's not perfect -- but pcmcia-cs wasn't perfect either...

> I'm already not very happy that the new Pcmcia stack does no
> longer support desktop PCI-Pcmcia bridge properly, so I'll just add
> that to my list.

Huh? What's broken there? That's news to me. Could you provide me with a
full bug report, please?

> 	With respect to the removal of the ioctl, you may want to
> contact the various people supporting Pcmcia in the various distro and
> asking them about how far they are supporting the new utilities. They
> are the people that are going to be impacted the most.

At least Fedora, Redhat, Ubuntu, Novell/SUSE and gentoo have switched (you
searched for pcmcia, not pcmciautils ;-) ), Debian is on its way.

Also, I want to point out again that this is _not_ a PCMCIA-specific
problem, and therefore should _not_ be handled at the PCMCIA layer but at
the driver core layer.
But all sorts of issues tend to be noted on the PCMCIA side first -- be it
breakage of IRQ routing, misallocation of resources, PCI bus numbering
changes...


	Dominik