> That demands some notion of device identity, and not all devices
> support one. Short of that, we need "stable" physical IDs ...
>
> My next patch (looks like it won't be today :) addresses the "physical ID"
> side of that problem.
Changed my mind ... it is today! See my next post.
- Dave
> > Drivers are never the first to increment a count, or last to decrement.
> > (Unless they've got significant bugs...)
>
> Today this is a requirement for drivers, but only because of the way the
> current code works.
Seems almost tautological ... :) You want to change those requirements.
I'
On Mon, Apr 08, 2002 at 03:12:26PM -0700, David Brownell wrote:
> > But why have a special case for hub/hcd use that is different from the
> > drivers? If a driver wants to grab a device, it should be able to use
> > it until it decrements the count.
>
> Yes, but drivers are also required to s
On Mon, Apr 08, 2002 at 02:12:44PM -0700, Greg KH wrote:
>
> I can try to get this to work if you don't want to do it, as it's one of
> the things I think will clean up the usb driver model a lot, and have
> been wanting for a while.
Ok, I applied this patch to the tree, but added a comment abou
> But why have a special case for hub/hcd use that is different from the
> drivers? If a driver wants to grab a device, it should be able to use
> it until it decrements the count.
Yes, but drivers are also required to stop using the device completely
when they return from disconnect() process
On Mon, Apr 08, 2002 at 01:18:47PM -0700, David Brownell wrote:
> Hi,
>
> This patch is a more complete fix for the device refcount
> sanity checking and cleanup on device disconnect.
>
> - Splits apart usb_dec_dev_use(), for driver use, and
> usb_free_dev(), for hub/hcd use. Both now
