linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ron <ron@debian.org>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: RFC: Code to snatch a device from a generic driver
Date: Fri, 14 Jan 2005 13:23:11 +1030	[thread overview]
Message-ID: <20050114025310.GA6447@hank.shelbyville.oz> (raw)
In-Reply-To: <20050111193455.GE4623@kroah.com>

On Tue, Jan 11, 2005 at 11:34:56AM -0800, Greg KH wrote:
> No, try something like the following.  It creates a sysfs file that you
> can write to to unbind the device manually.

Thanks!  That's a potentially treacherous little toy to add to my
system, but it does work as advertised and it took me on a very nice
tour of appropriate internals.

> The binding a driver to a device manually is left as an exercise to the
> reader :)
> 
> Seriously, I'm working on adding this to the driver core so you don't
> have to do stuff like this in drivers.

Yes, I didn't seriously intend people should paste such goop into their
modules, right now I'm just digging my way through to the desired
functionality -- armed only with some rusty memories of 2.4, a broken
hacksaw blade, and grep ...  This should certainly be a core library
function of some form by the time we are through.

My next candidate is shown below.  Aside from the (relatively) minor
things commented there (and any that I still don't see), it seems to
have one major deficiency still, which I'll call 'warmplug' support,
(being somewhere between the increasingly ill-named hot and 'cold' plug
problems)

It will correctly snatch a device from a generic driver when the module
is loaded.  This covers 'first time users' installing the module into a
running kernel, and likewise subsequent hotplug operations when the module
is not installed at the time the device is plugged in.  But it fails
when both the generic module and the specialised module are already
loaded and the generic module was registered with the usbcore first.

In that case the generic module will ack the probe and the more
specialised module will never be queried about the device (and hence
have no opportunity to steal it).  The user must force a module reload
for the later module to get a chance to grab it.  In the case of the
wacom device, it appears to be able to lose this race from a cold boot
on a UP machine.  If the device is discovered during boot both modules
will be probed and installed but all modules fail to initialise it at
that time, since other required things are still cycling up.  Once
everyone is on the same page and the device is ready to be bound,
the modules are already loaded and so the problem above plays out.

Which I think takes us back to a more basic problem...  that I need
to register this intention to want a device more than some generic
driver does with the usb core itself -- so it can dispatch the probe
calls in a more ordered fashion from most specialised to most generic
candidates for a particular device, rather than just stopping with the
first driver that says it can handle it in some form.

I'm going to look at this more today.  All thoughts welcome.  Code below
is for vanilla 2.6.10 and still using the subsys.rwsem for now.

cheers,
Ron


/* Module side boilerplate
*/
static int __init cpad_init(void)
{
	int result = usb_register(&cpad_driver);
	if (result == 0) {
		info(DRIVER_DESC " " DRIVER_VERSION);
		repossess_devices(&cpad_driver, cpad_idtable);
	} else
		err("usb_register failed, error number: %d", result);

	return result;
}

/* Snatch all devices listed by @id from (hopefully) more generic drivers
   and bind them to @driver.  @id may be the same list passed to
   MODULE_DEVICE_TABLE, or a separate list subject to this more aggressive
   binding.
*/
static void repossess_devices(struct usb_driver *udrv,
                              struct usb_device_id *id)
{
	while (id->idVendor)
	{
		// XXX Not enough, we need to find ALL devices, not just the
		//     first of any particular model.  Messy to try and fix
		//     here in the module though, so don't yet.

		struct usb_device *udev = usb_find_device(id->idVendor,
							  id->idProduct);

		if (udev)
		{
			down_write(&udev->dev.bus->subsys.rwsem);
			usb_lock_device(udev);

			// see above
			struct usb_interface *interface = usb_ifnum_to_if(udev,0);

			if (interface->dev.driver &&
			    interface->dev.driver->owner != udrv->driver.owner)
			{
			    if (interface && usb_interface_claimed(interface))
				    device_release_driver(&interface->dev);

			    driver_probe_device(&udrv->driver, &interface->dev);
			}

			usb_unlock_device(udev);
			up_write(&udev->dev.bus->subsys.rwsem);

			usb_put_dev(udev);
		}
		++id;
	}
}



      reply	other threads:[~2005-01-14  2:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-11  2:40 RFC: Code to snatch a device from a generic driver Ron
2005-01-11 19:34 ` Greg KH
2005-01-14  2:53   ` Ron [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050114025310.GA6447@hank.shelbyville.oz \
    --to=ron@debian.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).