On Mon, 16 Aug 2004, David Brownell wrote:
> Maybe ... it's not a simple locking problem though.
>
> Doctoral theses have been gotten in such areas,
> though I hope none recently! (Now they just give
> spurious software patents for trivial variants of old
> schemes.)
:-)
I feel better now; we
On Monday 16 August 2004 9:56 am, Alan Stern wrote:
> [Email can sometimes be a very frustrating medium. It's fair to say
> that you and I are both very intelligent people, and yet we've been
> talking past each other in this thread to an almost comical extent. I
> bet we could have settled the w
[Email can sometimes be a very frustrating medium. It's fair to say
that you and I are both very intelligent people, and yet we've been
talking past each other in this thread to an almost comical extent. I
bet we could have settled the whole thing very simply in less than an
hour or two of face-t
On Sunday 08 August 2004 8:47 am, Alan Stern wrote:
> On Sat, 7 Aug 2004, David Brownell wrote:
> > Alan Stern wrote:
> > > In fact that can't happen; khubd can't wake up suspended devices.
> >
> > Except for its remote wakeup path... :)
>
> Forgot about that one... it didn't exist until quite re
On Sat, 7 Aug 2004, David Brownell wrote:
> > In fact that can't happen; khubd can't wake up suspended devices.
>
> Except for its remote wakeup path... :)
Forgot about that one... it didn't exist until quite recently! The
problem you outlined still can't happen, though. khubd won't see the
r
On Friday 06 August 2004 09:39, Alan Stern wrote:
> On Wed, 4 Aug 2004, David Brownell wrote:
>
> > > No, no. Preventing tasks from interfering with another is absolutely
> > > necessary. I'm saying that even if hub_events() called
> > > down(&hdev->serialize) instread of locktree(), we would st
On Wed, 4 Aug 2004, David Brownell wrote:
> > No, no. Preventing tasks from interfering with another is absolutely
> > necessary. I'm saying that even if hub_events() called
> > down(&hdev->serialize) instread of locktree(), we would still have that
> > prevention.
>
> No we wouldn't. Consider
On Wed, 4 Aug 2004, David Brownell wrote:
> > > Good question. I think that the PM core should have a routine that's
> > > responsible for suspending all of a subtree. Instead it only has code
> > > to do that for the degenerate subtree: the whole darn system!
> >
> > You're still missing my p
On Tuesday 03 August 2004 08:47, Alan Stern wrote:
>
> > I think I see what you're saying: You don't see preventing one
> > task from interfering with another as a goal. So you don't
> > draw the distinction between prevention that's necessary,
> > and prevention that's stronger than necessary
On Tuesday 03 August 2004 08:47, Alan Stern wrote:
> Non-data signalling on a port _is_ a good reason to lock the whole subtree
> below that port, I agree. What I don't agree is that locktree()
> provides the correct sort of locking for general non-data signalling.
> The way I see it, locktre
On Mon, 2 Aug 2004, David Brownell wrote:
> The reset code changes aren't critical, at least not yet. I expect
> locking arguments to continue for a while yet, regardless.
Probably. :-)
> If you don't think that issuing non-data signaling on a port
> (affecting everything downstream) shouldn't
On Monday 02 August 2004 09:36, Alan Stern wrote:
>
> My main point: There's no need to use locktree() in hub_events() or
> usb_reset_device(). (Although your latest changes didn't actually add
> locktree to usb_reset_device, there was a comment about doing it.)
I guess you didn't like my exam
David:
Your reply to my last message was so far off-base with respect to the
ideas I had intended to convey, I can only assume there's been a serious
communications failure. I'll do my best to clarify things below and show
where you went astray.
My main point: There's no need to use locktree
On Friday 30 July 2004 08:35, Alan Stern wrote:
> On Thu, 29 Jul 2004, David Brownell wrote:
> Aha! The upstream "port" wasn't locked; the entire hub was! So even if
> non-data signalling is taking place on a port/branch that is disjoint from
> your device you still have to suffer the locking de
On Thu, 29 Jul 2004, David Brownell wrote:
> Oh, those! Right now they're not in the trees because of problems
> they turned up (as I understand things).
My understanding was that they didn't get applied because Greg was too
busy preparing for OLS. It doesn't matter now.
> What I had to do:
On Thursday 29 July 2004 14:55, Alan Stern wrote:
> On Thu, 29 Jul 2004, David Brownell wrote:
>
> > > Our work on the hub driver is well on its way to getting hopelessly
> > > tangled. Should we try to coordinate the changes we've been sending in
> > > independently?
> >
> > This looked OK to
On Thu, 29 Jul 2004, David Brownell wrote:
> > Our work on the hub driver is well on its way to getting hopelessly
> > tangled. Should we try to coordinate the changes we've been sending in
> > independently?
>
> This looked OK to me with respect to RC2 and to what's in Greg's tree
> (except f
On Thursday 29 July 2004 13:18, Alan Stern wrote:
> David:
>
> Our work on the hub driver is well on its way to getting hopelessly
> tangled. Should we try to coordinate the changes we've been sending in
> independently?
This looked OK to me with respect to RC2 and to what's in Greg's tree
(ex
David:
Our work on the hub driver is well on its way to getting hopelessly
tangled. Should we try to coordinate the changes we've been sending in
independently?
With regard to your latest patch, I have some questions/comments:
There's no need to check hub->quiescing in the interrupt
Please merge; the CONFIG_USB_SUSPEND patch depends on it.
- Dave
This hub patch:
- updates internal docs about locking, matching current usage
for device state spinlock and dev->serialize semaphore
- adds locktree() to use with signaling that affect everything
downstream of a given devic
20 matches
Mail list logo
