Bleech...
> This is what I'm talking about you ignoring the points I make.
> Just because you ignore doesn't mean it doesn't matter.
However, it's perfectly OK for _you_ to ignore the points
that _I_ make, because when _you_ ignore points they
magically end up not really mattering.
But ... it'
On Wed, May 15, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > My response was that you're focus for the driver was wrong. You should
> > be targeting for a working system, not a buggy one.
>
> Which, as I repeatedly explained, WAS exactly the target.
> Not a fact you wanted to hear, I can t
I can hope this will be my last post on this topic, but you did
deserve a response to your last note ...
> My response was that you're focus for the driver was wrong. You should
> be targeting for a working system, not a buggy one.
Which, as I repeatedly explained, WAS exactly the target.
Not a
On Mon, May 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > Because I said reference counting and you went out and found one special
> > > > case which you think immediately proves your point.
> > >
> > > No, I was talking about device management. You're the one who
> > > keeps ignor
On Mon, May 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > Lots of implicit state stashed in the HCD. Not a style I like.
>
> Oh, and that "call completion into rmmodded driver" issue...
> I could highlight a few other issues too, but that's a start.
Call completion into rmmoded driver
> > > Because I said reference counting and you went out and found one special
> > > case which you think immediately proves your point.
> >
> > No, I was talking about device management. You're the one who
> > keeps ignoring such issues, and wants to talk refcounting instead.
> >
> > If you're
> > What's wrong with the solution I used?
>
> Lots of implicit state stashed in the HCD. Not a style I like.
Oh, and that "call completion into rmmodded driver" issue...
I could highlight a few other issues too, but that's a start.
> What's wrong with the solution the other drivers use?
_
> > > > I guess I don't see how what you suggest relates to anything.
> > > > In what sense is that not being done already?
> > >
> > > Because when it is done, you'll decrement the reference count and then
> > > you'll finally get your ->deallocate() callback.
> >
> > QH != dev.
>
> Yes, I rea
On Mon, May 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > Then don't decrement the reference count until the QH is fully unlinked.
> > >
> > > I guess I don't see how what you suggest relates to anything.
> > > In what sense is that not being done already?
> >
> > Because when it i
> > > > That summary _does_ assume a working system. ...
> > >
> > > I don't see what's really different? If the HC halted due to error,
> > > wouldn't the devices disappear that are on the root hub?
> >
> > What, you mean as if by magic without the HCD doing anything
> > at all? Hardly not!
On Mon, May 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > That summary _does_ assume a working system. ...
> >
> > I don't see what's really different? If the HC halted due to error,
> > wouldn't the devices disappear that are on the root hub?
>
> What, you mean as if by magic witho
> > That summary _does_ assume a working system. ...
>
> I don't see what's really different? If the HC halted due to error,
> wouldn't the devices disappear that are on the root hub?
What, you mean as if by magic without the HCD doing anything
at all? Hardly not! (Peals of laughter.) Absolu
On Mon, May 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > I'm not sure why you think that having supporting evidence for
> > > a statement I make would be "stubborn" or "difficult".
> >
> > Because I said reference counting and you went out and found one special
> > case which you thi
> You're targeting your code for the wrong system. You should be coding
> assuming a working system. You shouldn't be assuming a buggy system.
You're targetting your comments at the wrong person ... :)
That summary _does_ assume a working system. Even
the comments about TDs (or for EHCI, QTDs)
On Mon, May 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > > The HCD is most _certainly_ allowed to block when cleaning up
> > > > > device state. Every device management API I've had reason to
> > > > > look at in Linux guarantees that the the "clean up after this device"
> > > > >
> > > > The HCD is most _certainly_ allowed to block when cleaning up
> > > > device state. Every device management API I've had reason to
> > > > look at in Linux guarantees that the the "clean up after this device"
> > > > call can block.
> > >
> > > You haven't been looking hard enough. Take
On Mon, May 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > Will someone at least prevent the device management calls
> > > from being called in_interrupt() though? That is _guaranteed_
> > > to oops with driver bugs. Even Johannes admitted that he's
> > > broken the EHCI and OHCI driv
> > Will someone at least prevent the device management calls
> > from being called in_interrupt() though? That is _guaranteed_
> > to oops with driver bugs. Even Johannes admitted that he's
> > broken the EHCI and OHCI drivers.
> >
> > The simple fix is to move the call to
> >
> > dev->bu
On Mon, May 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > > >For example, device
> > > > > > drivers that hang on to references after their disconnect()
> > > > > > methods complete. (Which can make "rmmod" break, for
> > > > > > example completion callbacks going to where t
On Mon, May 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > I'll go send these patches to Linus so everyone can play with, and go
> > over, these patches in a easier format.
>
> Will someone at least prevent the device management calls
> from being called in_interrupt() though? That is _
On Mon, May 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > The HCD is most _certainly_ allowed to block when cleaning up
> > > device state. Every device management API I've had reason to
> > > look at in Linux guarantees that the the "clean up after this device"
> > > call can block.
> I'll go send these patches to Linus so everyone can play with, and go
> over, these patches in a easier format.
Will someone at least prevent the device management calls
from being called in_interrupt() though? That is _guaranteed_
to oops with driver bugs. Even Johannes admitted that he's
br
> > Johannes, your arguments have boiled down to not wanting
> > the core to detect or prevent such oopses. I really don't
> > understand why, since the cost to correctly written device
> > drivers is zero and the _value_ of detecting/preventing such
> > problems is significantly higher. (Measur
> > > > >For example, device
> > > > > drivers that hang on to references after their disconnect()
> > > > > methods complete. (Which can make "rmmod" break, for
> > > > > example completion callbacks going to where the module
> > > > > used to be loaded.)
> ...
>
> No, I think this shou
On Mon, May 13, 2002 at 04:46:25PM -0400, Johannes Erdfelt wrote:
>
> I haven't compiled the above patch, let along tested it yet. I also think
> there may be some other situations where we may need something similar.
>
> I'd like to do a code review as well as test the patch. Can I send you a
>
On Mon, May 13, 2002 at 04:26:36PM -0400, Johannes Erdfelt wrote:
>
> It's easy with the patch I sent to revert it to the 2.4 method of
> reference counting:
>
> --- linux-2.5.15/drivers/usb/core/devio.c.old Mon May 13 16:17:55 2002
> +++ linux-2.5.15/drivers/usb/core/devio.c Mon May 13 16:2
On Mon, May 13, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, May 13, 2002 at 04:26:36PM -0400, Johannes Erdfelt wrote:
> >
> > It's easy with the patch I sent to revert it to the 2.4 method of
> > reference counting:
> >
> > --- linux-2.5.15/drivers/usb/core/devio.c.old Mon May 13 16
On Mon, May 13, 2002 at 12:56:23PM -0700, David Brownell wrote:
> > > > But I'll correct a few misstatements right now about the
> > > > current 2.5 behavior. (And for what it's worth, only "uhci.c"
> > > > has any problems with that -- from what I've seen.)
> > > >
> > > > > - It made the USB c
On Mon, May 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> Simple fix: don't merge Johannes' changes.
That argument works both ways.
But since what we're doing is standard for the rest of the kernel, the
burden of proof is on you to convince everyone to change.
> > That's a device drive
> > > But I'll correct a few misstatements right now about the
> > > current 2.5 behavior. (And for what it's worth, only "uhci.c"
> > > has any problems with that -- from what I've seen.)
> > >
> > > > - It made the USB code more complicated as a whole with the introduction
> > > > of an addi
On Mon, May 13, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, May 13, 2002 at 03:29:37AM -0700, David Brownell wrote:
> > Naturally I don't like this patch, and I may comment more
> > on it a bit later when I'm not just up late and sleepless ... :)
> >
> >
> > But I'll correct a few misstat
On Mon, May 13, 2002 at 03:29:37AM -0700, David Brownell wrote:
> Naturally I don't like this patch, and I may comment more
> on it a bit later when I'm not just up late and sleepless ... :)
>
>
> But I'll correct a few misstatements right now about the
> current 2.5 behavior. (And for what it'
Naturally I don't like this patch, and I may comment more
on it a bit later when I'm not just up late and sleepless ... :)
But I'll correct a few misstatements right now about the
current 2.5 behavior. (And for what it's worth, only "uhci.c"
has any problems with that -- from what I've seen.)
33 matches
Mail list logo
