> >Hmm, could you share a brief update on PowerMac and 2.4?
>
> The developement of the PowerMac kernel is a bit... weird ;)
Thanks for the update. Briefly, it seems there are enough
different PPC trees to be confusing ... and that may be some
of the reason we don't always see kernel 2.4 PowerMac problems
reported as much as I might expect. (Alternatively, current
PPC versions are stable enough to be worth switching! ;-)
> Paul is the maintainer for the PowerMac port.
> Cort is the maintainer for the PPC port as a whole (includes much more
> than PowerMacs).
> Paul maintains a couple of rsync trees with his own developements and
> gets them regulary merged in Cort's bitkeeper tree (or he sends them
> directly to linus and they end up in the bk tree this way, or I merge his
> stuffs in bk, etc...)
>
> ...
>
> So basically, your best source of PowerMac 2.4 kernels currently is the
> bitkeeper tree on hq.fsmlabs.com. ...
>
> >As you know, I'm curious when I can rip out the PMAC_PBOOK
> >stuff in the OHCI driver and just use the normal 2.4 PCI
> >interfaces for that functionality (no platform-specific stuff).
>
> The problem is that the powerbook sleep process is a bit sensitive to the
> order in which things are done, and I don't think we have implemented PCI
> power management yet on pmac.
I understand pci_set_power_state () doesn't wholly work on
x86 either (doesn't restore some PCI state that can change
over suspend), but at this point I'd be more concerned that the
PCI drivers be able to remove the PMAC-specific PM processing
code. It'd seem like it should be straightforward to have the
PCI code use the PMAC_PBOOK APIs in one place, rather than have
every driver use them.
Perhaps the downside of that approach is that it couples
to the 2.4 PCI driver framework, and PPC still seem rather
reliant on the 2.2 framework. At some point not too far
into the 2.4 series, I'd hope such reliance disappears
(and not just for PPC :-).
> >I'd actually rather just see sohci_unlink_urb() report EWOULDBLOCK,
> >with a single err() to report that USB device driver bug. Then at
> >least the failure report is in the hands of the driver that caused it,
> >and it can maybe resolve it. (I've yet to send around such a patch,
> >but it's in the queue while I track down a different bug.)
>
> Did you see a lot of drivers test for the result of sohci_unlink_urb() ?
> I would also add a printk...
The err() is a printk; I was planning to add the builtin return
address, just to make the diagnostics ID the guilty as well as
possible! Now, to disentangle that from the other patches ...
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
