[coreboot] Trac reminder: list of new ticket(s)
Segher Boessenkool
segher at kernel.crashing.org
Wed Jul 16 19:35:47 CEST 2008
>> In any case, I hope we can all agree that certainly nothing in the PCI
>> spec requires all devices on a mainboard to have the same subsystem
>> (vendor) ID (some might not even have that register implmented!)
>
> Yes it is an optional field.
Since version 2.2 of the PCI spec, it is required on most classes
of devices (the exceptions are host bridges, ISA/EISA/MCA bridges,
PCI-PCI bridges, and some PICs, DMACs, timers, RTCs).
> When the field is implemented the question
> is what should it be.
Yes.
> The wording is pretty clear elsewhere that the subsystem vendor id
> should equal your normal pci vendor id of the manufacturer.
The ID of the manufacturer of the subsystem, yes; or zero.
> The
> subsystem device id is the ambiguous one.
Indeed.
> It seems clear from that proposal that subsys vendor id subsys device
> id
> is not unique enough to identify a driver in general.
Unfortunate, but true.
> I just figure the default should be the current behavior.
Remind me, what _is_ the current behaviour?
I see two options:
a) Don't program it, leave it at 0.
b) Program it the same as the factory BIOS does.
There is a bunch of problems with b):
-- We have to keep a list of mainboards, and the user has to configure
for that mainboard, even if that board is essentially identical to
a whole host of other boards;
-- Every chip is programmed differently, so we need a driver for every
chip, even if coreboot doesn't care about any other chip specifics;
-- OS drivers using this subsystem ID might use it to decide the chip
is configured in a certain way.
What are the downsides to not programming an SSID/SSVID?
Segher
More information about the coreboot
mailing list