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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
