On Tue, Feb 25, 2003 at 08:42:10AM +0100, Duncan Sands wrote:
The other way is to follow Dave's contract.
Heh, or we could make lives easier for driver writers by not requiring
such a complicated contract that almost none of the current drivers
follow :)
thanks,
greg k-h
Greg KH wrote:
On Tue, Feb 25, 2003 at 08:42:10AM +0100, Duncan Sands wrote:
The other way is to follow Dave's contract.
Heh, or we could make lives easier for driver writers by not requiring
such a complicated contract that almost none of the current drivers
follow :)
Actually, I'd say it's
On Friday 21 February 2003 17:21, Greg KH wrote:
On Fri, Feb 21, 2003 at 12:34:13PM +0100, Duncan Sands wrote:
I get an oops on shutdown with 2.4.20 (speedtouch driver). Here is what
happens:
probe method called: I take a reference to the usb device with
usb_inc_dev_use
(machine
I just want to point out that from a pragmatic perspective, those
changes (bug fixes if you insist) won't break drivers that have
already been adhering to the stricter contract I described.
Yes and no.
The OHCI fix I sent was necessary even with your stricter contract.
And how could that
On Mon, Feb 24, 2003 at 12:26:30PM +0100, Duncan Sands wrote:
Hi Greg, I went and got a new one for your debugging pleasure! It is
the dev-bus-op-deallocate(dev) that kills things. What happens
seems to be this: disconnect is called on the speedtch driver, then
uhci is unloaded, then
On Tuesday 25 February 2003 02:21, Greg KH wrote:
On Mon, Feb 24, 2003 at 12:26:30PM +0100, Duncan Sands wrote:
Hi Greg, I went and got a new one for your debugging pleasure! It is
the dev-bus-op-deallocate(dev) that kills things. What happens
seems to be this: disconnect is called on the
A better way to say it may be: if that's not what disconnect()
means, than what the heck _does_ it mean? There are a whole LOT
of answers in current use. Clearly the idea is to prohibit some
kinds of behavior. Which ones? And why _not_ all of them?
It means that the device is physically gone,
On Sun, 23 Feb 2003, David Brownell wrote:
A better way to say it may be: if that's not what disconnect()
means, than what the heck _does_ it mean? There are a whole LOT
of answers in current use. Clearly the idea is to prohibit some
kinds of behavior. Which ones? And why _not_ all of
It means that the device is physically gone, that's it. What the driver
wants to do with this information is up to it. But the core has to
handle attempts to use this device after it is gone, like it now does.
That's an interesting model, but it doesn't seem to handle some
current
While the subject is in the air, how about device resets? They can be
initiated by a driver bound to any interface, but they affect the whole
device.
A sore spot.
I don't know enough about how the core handles resets... the device needs
to be re-configured (USB address assigned, etc.),
A better way to say it may be: if that's not what disconnect()
means, than what the heck _does_ it mean? There are a whole LOT
of answers in current use. Clearly the idea is to prohibit some
kinds of behavior. Which ones? And why _not_ all of them?
It means that the device is
On Sun, Feb 23, 2003 at 12:36:02AM +0100, Duncan Sands wrote:
The philosophy is often called programming by contract.
And the contract is: usbcore agrees to work with your driver
and do everything right, if your driver agrees to do a few
specific things. One of those specific things is
Present for you, Greg! I moved usb_put_dev to the disconnect routine
(of course, there is a usb_get_dev in probe). Now I get the following oops
on 2.5 during system shutdown:
uhci-hcd 00:0b.0: remove, state 3
usb usb1: USB disconnect, address 1
usb 1-2: USB disconnect, address 2
Unable to
On Sat, Feb 22, 2003 at 07:13:26PM -0500, Johannes Erdfelt wrote:
The intent was for 2.4 to have this same contract. Having a reference count
on the device structure is pointless if that weren't the case.
Yes, and because of this, the driver model changes in 2.5 were very
easy, thanks for
On Sat, 2003-02-22 at 23:36, Duncan Sands wrote:
The philosophy is often called programming by contract.
And the contract is: usbcore agrees to work with your driver
and do everything right, if your driver agrees to do a few
specific things. One of those specific things is never using
On Sunday 23 February 2003 01:05, Greg KH wrote:
On Sun, Feb 23, 2003 at 01:03:31AM +0100, Duncan Sands wrote:
Present for you, Greg! I moved usb_put_dev to the disconnect routine
(of course, there is a usb_get_dev in probe). Now I get the following
oops on 2.5 during system shutdown:
On Sunday 23 February 2003 01:03, Duncan Sands wrote:
Present for you, Greg! I moved usb_put_dev to the disconnect routine
(of course, there is a usb_get_dev in probe). Now I get the following oops
on 2.5 during system shutdown:
Mea culpa - I was borking the system just before the call to
Greg KH wrote:
On Sun, Feb 23, 2003 at 12:36:02AM +0100, Duncan Sands wrote:
The philosophy is often called programming by contract.
And the contract is: usbcore agrees to work with your driver
and do everything right, if your driver agrees to do a few
specific things. One of those specific
On Sat, Feb 22, 2003, David Brownell [EMAIL PROTECTED] wrote:
The intent was for 2.4 to have this same contract. Having a reference count
on the device structure is pointless if that weren't the case.
However, there may be bugs there in HCDs, the core, or drivers with
respect to this
On Sat, Feb 22, 2003 at 06:59:54PM -0800, David Brownell wrote:
Greg KH wrote:
On Sun, Feb 23, 2003 at 12:36:02AM +0100, Duncan Sands wrote:
The philosophy is often called programming by contract.
And the contract is: usbcore agrees to work with your driver
and do everything right, if
I get an oops on shutdown with 2.4.20 (speedtouch driver). Here is what
happens:
probe method called: I take a reference to the usb device with usb_inc_dev_use
(machine shutting down - shutdown of usb subsystem)
disconnect called
(still have the reference)
...time passes...
final driver
On Fri, Feb 21, 2003 at 12:34:13PM +0100, Duncan Sands wrote:
I get an oops on shutdown with 2.4.20 (speedtouch driver). Here is what
happens:
probe method called: I take a reference to the usb device with usb_inc_dev_use
(machine shutting down - shutdown of usb subsystem)
disconnect
What's the backtrace from the oops?
usb_free_dev+19/3c
The rest has gone to join the great penguin in the sky.
Personally I wouldn't trust the reference counting logic in 2.4, it just
doesn't seem right, but I haven't spent the time in looking too deeply
at it, unlike 2.5.
I've decided not
On Fri, Feb 21, 2003 at 05:53:24PM +0100, Duncan Sands wrote:
What's the backtrace from the oops?
usb_free_dev+19/3c
Hm, wonder if the bus has been cleaned up by the shutdown sequence
first. That might cause this.
greg k-h
---
This
24 matches
Mail list logo
