Developer Forum

No PCI quirk code has ever called pci_enable_device() AFAICT.

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).



If quirk code can't rely on BARs, then the PCI system needs some
basic overhauls ... yes? I mean, how could quirk code ever work
if it can't access the relevant chip registers??



Erm, what "code is doing" what, that you mean ??



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.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

n Monday 31 October 2005 6:41 pm, Benjamin Herrenschmidt wrote:

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



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 ... ;)



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!



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 ... :)



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 XXXX@XXXXX.COM
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Not Vojtech, but here is goes... Not everyone has USB compiled in and
even then I think USB is registered after serio. So when we probe for
i8042 BIOS still has its dirty hands on USB controllers and pretends
that they are in fact PS/2 devices. Crazy stuff like that... That's
why we can't keep that code in HCI drivers.

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

OpenFirmware is quite knowledgeable about USB devices, both disks,
mice, keyboards, and IIRC there's even a USB<=>serial bridge useable
as an OpenFirmware console.


On other platforms, OpenFirmware supports direct ELF loading without
any extra code. If you want initrd support, you need a little Forth
script (IE: yaboot) to load it into some RAM first.

The difference is, OpenFirmware is nice and clean and stops messing
with hardware before handing off to the new kernel. If you ever try
to boot from an invalid ELF file on an OpenFirmware machine, you'll
see that's fairly obvious, because the screen flashes and changes
state slightly during the failed boot attempt (after which it
reconnects to the hardware again to display messages).

Why should x86-specific-BIOS-USB-handoff-specific-crap-PCI-quirks be
even _compiled_ on PowerPC systems that have nothing remotely like
the affected hardware (BIOS & PS/2 serio chip)?

Cheers,
Kyle Moffett



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

Maybe you should first pay attention to what I pointed out: that
the problem reports I've seen have ONLY been on PPC systems.

Like the powerbook in $SUBJECT ... people without PPCs are unlikely
to hit such issues, judging by the evidence so far. (Though of course
it'd be possible...)




I guess one point to be made is that although x86 gets the most testing
right away, PPC lately isn't far behind. Latent bugs in usb-handoff
logic got surfaced by this patch ... there could be others. I suspect
nobody except x86 users have been running that code much at all.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

For starters, none of the controller specs say that the handshaking
is x86-specific. There's a certain amount of "x86 Linux gets the
most testing" going on here. Plus a lot of "nobody really used that
usb-handoff code before, except to fix semi-broken x86 systems".

One requirement coming from x86/DOS legacy support though is that the
system probably expects to "work like DOS" at various boot stages.
Hence the way some systems take kbd/mouse input from USB and jam it
through PS2 serio hardware, so DOS will see it. Which is why x86
hardware generally _does_ need to use these handhaking mechanisms,
to kick the BIOS off the hardware. (And why the USB folk have been
very used to telling folk to disable BIOS support for USB. That's
fine advice unless you've got a USB keyboard or mouse.)



That's a nice design policy (IMO) but sometimes folk also like to
draw the firmware/OS boundary in different ways.

In any case ... let's all just blame this on DOS, and move on to
something that's not as twentieth-century. :)

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

David Brownell writes:


Well, there is a problem in the code which is clearly visible just by
inspection: that it is touching a pci device without having called
pci_enable_device on it. That is well known to cause problems on many
platforms, and it is not guaranteed to work on any platform.

With a clearly visible bug like that in there, it doesn't matter what
platform(s) the problem is reported on.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

"Illegal" means "prohibited"; not necessarily "by law", though that's the
most common use. It's valid in other contexts, such as "prohibited by
the API". "int *p = 1.5f" is illegal C code. Google for "illegal chess
moves".

There may be political reasons to prefer "invalid" to "illegal", but that
doesn't make it incorrect.

--
Glenn Maynard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

It is even worse in some cases, especially when USB host controller shares
interrupt with other PCI devices. I've seen systems which have just been
swamped by interrupts if shared device driver enables IRQ before HCD starts...

Aleks.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/