> > > (BTW, is there any possibility of changing things so that downstream
> > > devices really _are_ children of the hub interface instead of children of
> > > the hub device? This would have repercussions for userspace, since the
> > > sysfs pathnames would change -- which makes me suspect it's not feasible
> > > politically.)
> >
> > This is what I was alluding to when I pointed out that the pm_parent
> > mechanism "should" eventually be able to solve problems for us. One
> > logical structure would have devices' pm_parents be some facet of the
> > hub interface, with PM suspend/resume operations using that information
> > through some TBS calls ... without making such sysfs name changes.
>
> We shouldn't need to use the pm_parent mechanism for this. It's not a
> very good mechanism anyway, because it only allows one extra parent per
> device. A small amount of coding around the illogical device links should
> suffice here.
Actually the real issue is that pm_parent has never been usable for
anything **at all** ... have you seen anything in the kernel that so much
as _tests_ for pm_parent, much less tries to use it? To repeat: that
mechanism "should" solve problems. The subtext being that it needs to
be (re)designed so that it can ... i.e. it needs replacing. If it were
removed today, NOBODY would miss it. But the problems it was supposed
to solve would still exist.
I sent by a proposal sketch a while ago that repurposed it as the
manager for a set of devices. To suspend or resume a device X, the
pmcore calls would replace x->bus->suspend(x) calls with something
accessing a facet of some other object that knows about X and the
other related devices in that set:
x->pm_parent->suspend(x)
x->pm_parent->resume(x)
That would allow the notion of "parenting" to be whatever it needs
to be, and would directly support managers for the sort of "cluster
of interrelated devices" that generally make up the problem cases.
And handling of hubs -- without sysfs structure changes breaking
userspace -- would be a simple task for such a scheme. Necessarily,
since it's a degenerate case of the funkier cases.
> ... skipping to a different topic ...
> To put it more explicitly: I would consider a host controller to comprise
> a part (A) that manages the connection to the PCI (or other system-level)
> bus, plus a part that manages the connection to the USB bus and which acts
> like a hub. This second part includes both the upstream (B) and
> downstream (C) halves of the root hub, as laid out in Chapter 11. That's
> in contrast to what you have written; you essentially said that you viewed
> the (A) part as the upstream half of the root hub.
Because there **IS** no (B) ... there is no upstream USB link. If you
look at the external signals, all you'll see is (A) and (C). Anything
else is an implementation detail of the hardware ... something that a
given HCD could know about, but usbcore shouldn't care about.
That is: HCs are black boxes with two interfaces: (A) is upstream, covered
by a spec like PCI bus or the SOC power/interconnect/clocking/...; while
(C) is a set of downstream links, covered by the USB spec. Putting any other
stuff into the core model is neither necessary nor desirable, since there will
be hardware that uses different models.
- Dave
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
