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 sim
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
-
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 call
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, the
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 happe
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
> >
>
> > 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
> 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.)
> > 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
> curr
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
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 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 e
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
> > resp
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 because it was never clearly defined or enforced.
I just want to point out
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 t
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
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 shutdow
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 n
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 d
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:
Do you get the same oops if you just try to rmmod the
On Sat, Feb 22, 2003, Greg KH <[EMAIL PROTECTED]> 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 d
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 handle
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 specifi
> 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
> the device after you return from disconnect(),
Duncan Sands wrote:
disconnect called
(still have the reference)
If you still hold it after your disconnect() returned, the
bug is in your driver ...
...time passes...
final driver shutdown: I drop the reference using usb_dec_dev_use, which
oopses.
Hi Dave, why is it a bug? I hold a reference
On Saturday 22 February 2003 21:04, David Brownell wrote:
> 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 - shutd
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 called
(still have the reference)
If you still hold
On Fri, Feb 21, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> 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.
It
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 S
> 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
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)
>
> disco
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 shut
32 matches
Mail list logo