Alan Stern wrote:
On Tue, 24 Feb 2004, David Brownell wrote:
On the other hand, maybe it'd just be simpler to make the root hub
registration code set the state to RUNNING? That would solve your
issue of wanting that state change out of the HCDs.
That's a very good idea. Non-PCI HCDs will stil
On Tue, 24 Feb 2004, David Brownell wrote:
> On the other hand, maybe it'd just be simpler to make the root hub
> registration code set the state to RUNNING? That would solve your
> issue of wanting that state change out of the HCDs.
That's a very good idea. Non-PCI HCDs will still have to cope
Alan Stern wrote:
Okay, let's go back to an earlier point in the discussion. You said that
setting state to RUNNING before calling start() might lead to problems
with other calls being passed through too early, before the hardware was
running properly. So what other calls might get sent through?
On Mon, 23 Feb 2004, David Brownell wrote:
> > There's no reason they couldn't be allowed during the STARTING state.
> > The real problem seems to be that the start() method does two things: turn
> > on the controller hardware and register the root hub. It becomes tricky
> > to change the sta
Alan Stern wrote:
On Mon, 23 Feb 2004, David Brownell wrote:
The UHCI notion of a suspended controller
seems to be more like the notion of an "empty schedule", where only
the root hub status polling is active.
Or a little more accurately, the schedule is allowed to be nonempty but
the controll
On Mon, 23 Feb 2004, David Brownell wrote:
> The UHCI notion of a suspended controller
> seems to be more like the notion of an "empty schedule", where only
> the root hub status polling is active.
Or a little more accurately, the schedule is allowed to be nonempty but
the controller doesn't ex
Alan Stern wrote:
Those three are part of the root hub life-cycle. Note that we
still haven't moved all "restart controller" logic into usbcore;
the UHCI code still has its own mechanism (which seems to fire
during routine operation), as does OHCI (during certain PM resume
scenarios, only).
I d
Alan Stern wrote:
For instance, is it guaranteed that
probe and remove will never run simultaneously? Is it guaranteed that
neither suspend nor resume will be called during either probe or remove?
Is it guaranteed that suspend and resume will not overlap? These are all
things I would expec
On Sun, 22 Feb 2004, David Brownell wrote:
> Alan Stern wrote:
> >> If an HCD needs
> >>mutual exclusion for any purpose, it must handle that itself.
> >
> >
> > Does the PCI layer at least guarantee that it won't call through any of
> > the other routines while either probe or remove is ru
On Sun, 22 Feb 2004, David Brownell wrote:
> >>That state model isn't as clean as it might be, but so
> >>far that hasn't been an issue ... and it was better than
> >>what went before, where there was no notion of what sorts
> >>of operations made sense. (Queuing urbs to disabled HCDs,
> >>for ex
Alan Stern wrote:
If an HCD needs
mutual exclusion for any purpose, it must handle that itself.
Does the PCI layer at least guarantee that it won't call through any of
the other routines while either probe or remove is running?
Nope. It's common to start getting IRQs during probe, for
That state model isn't as clean as it might be, but so
far that hasn't been an issue ... and it was better than
what went before, where there was no notion of what sorts
of operations made sense. (Queuing urbs to disabled HCDs,
for example, never makes sense.)
Is the main point then to keep trac
On Sat, 21 Feb 2004, David Brownell wrote:
> Alan Stern wrote:
> >
> > Is it true that the various callbacks emanating from hcd-pci.c have
> > guaranteed mutual exclusion?
>
> Not entirely. Ones initiated by "rmmod" or power management have
> to go right in, no matter what else is going on. If
Alan Stern wrote:
Is it true that the various callbacks emanating from hcd-pci.c have
guaranteed mutual exclusion?
Not entirely. Ones initiated by "rmmod" or power management have
to go right in, no matter what else is going on. If an HCD needs
mutual exclusion for any purpose, it must handle tha
14 matches
Mail list logo
