Using the "best available" driver

[Jean Tourrilhes]

On Wed, Dec 07, 2005 at 09:31:22PM +0100, Dominik Brodowski wrote:
> Hi,
> 
> On Wed, Dec 07, 2005 at 12:00:43PM -0800, Jean Tourrilhes wrote:
> > 	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 :-)

	Precisely ! That's exactly why I did thank you for
implementing this feature in my previous e-mail and asked what was the
plan to expose this precise feature in a user-friendly way.

> > 	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.

	Unfortunately, both cards have the same manfid. Yuck !

> 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.

	I think the underlying infrastructure provides the necessary
hooks. I'm more worried about how this gets into hotplug/udev. I'm
having a hard time making thew udev people listen to me on various
issues, so I don't want to waste my time unless I know there is a path
to get this work into standard distro.

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

	I personally can't use udev, it doesn't support the way I work.

> > > > 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.

	Good. How do we get that into standard udev ?

> > 	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...

	Well, my point was that this was not blocking the removal of
the ioctl.

> > 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?

http://marc.theaimsgroup.com/?t=106971885300002&r=1&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=106981189506433&w=2

	Note this is why I'm still using the external Pcmcia package
on some of my boxes. For my other boxes, I just use my hackish patch,
well, when the BIOS doesn't refuse to allocate ISA regions.

> > 	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.

	I did search for pcmciautils, and found nothing for SuSE. My bad.

> 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...

	Yes, I'm perfectly aware of that, and I've never been
advocating a Pcmcia only solution. Actually, the exact same problem
occur with orinoco_pci and hostap_pci ;-)

> 	Dominik

	Have fun...

	Jean