Re: [linux-usb-devel] Re: Commit "[PATCH] USB: Always do usb-handoff" breaks my powerbook

[David Brownell <david-b@pacbell.net>]

On Monday 31 October 2005 6:41 pm, Benjamin Herrenschmidt wrote:
> 
> > No PCI quirk code has ever called pci_enable_device() AFAICT.
> 
> Most PCI quirks only do config space accesses

Some do I/O space access.  Few do memory space access (ioremap_nocache).


> > Of course the _need_ to do such a thing might be another PPC-specific
> > (or OpenFirmware-specific?) PCI thing ... we've hit other cases where
> > PPC breaks things that work on other PCI systems (and vice versa).
> 
> "ppc" doens't do anything fancy that other archs don't do too, please
> stop with your "ppc specific" thing all over the place.

When the only problem reports come from PPC hardware, it sure looks
PPC-specific to me.  If such issues get reported on non-PPC hardware
(with those unique-to-ppc changes to PCI enumeration) then I'll stop
thinking of it as PPC-specific.  Until then ... ;)


> It is illegal, whatever the platform is, to tap a PCI device MMIO like
> that without calling pci_enable_device(), requesting resources etc... or
> at the very least, testing if MMIO decoding is enabled on the chip.
> Period. It has nothing to do with PPC and all to do with correctness.

I could easily believe that all that quirk code has been buggy since
day one, yes.  Certainly it's always had bugs in how it dealt with the
USB functionality; so why shouldn't it have bugs in how it deals with
the PCI functionality too?  Even if it was being maintained by the
PCI maintainers!


> > > I'm not sure it's legal to do pci_enable_device() from within a pci
> > > quirk anyway. I really wonder what that code is doing in the quirks, I
> > > don't think it's the right place, but I may be wrong.
> > 
> > Erm, what "code is doing" what, that you mean ??
> 
> What _That_ code is doing in the quirks... shouldn't it be in the
> {U,O,E}HCI drivers instead ?

Not for PCI.  Vojtech, this is your cue to explain some of how late handoff
borks the input layer, as observed by SuSE on way too many BIOS/hardware combos
for me to remember ... :)


> > > What is the logic supposed to be there ?
> > 
> > Which logic?  The fundamental thing those USB handoff functions do
> > is make sure that BIOS code lets go of the host controllers.  The
> > main reason it'd be using a controller is because of USB keyboards,
> > mice, or maybe boot disks.  Secondarily, that code needs to make
> > sure the controller is really quiesced before Linux starts using it.
> 
> So you rant about "ppc specific" whatever while the entire point of this
> code is to workaround x86 specific BIOS junk ...

Actually any "sophisticated" boot loader nowadays will know something
about USB, to handle keyboards, mice, or maybe boot disks.  (Didn't I
just write that?)  On some platforms, u-Boot understands OHCI ... so that's
not just x86 BIOS or other closed-source firmware.  (Though to be sure,
that u-Boot code acts more like Linux 2.4 than anything else; it doesn't
follow the standard firmare-uses-USB rules.)  And I sure thought some of
the OpenFirmware systems had USB support too.  (Written in FORTH?)

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/