[coreboot] Trac reminder: list of new ticket(s)
c-d.hailfinger.devel.2006 at gmx.net
Thu Jul 17 01:50:26 CEST 2008
On 16.07.2008 19:35, Segher Boessenkool wrote:
>> When the field is implemented the question
>> is what should it be.
>> 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.
Agreed. For my laptop, the Intel Pro/Wireless 2200BG is the one
onboard(?) device which has a different subsystem vendor ID from all the
others. That probably means it is on a different PCB.
>> The subsystem device id is the ambiguous one.
Yes. I have seen both:
- one common subsystem device ID for all onboard devices (my laptop board)
- completely different subsystem device IDs for each onboard device (my
>> 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;
We already do that. v2 and v3 targets are per-mainboard because SuperI/O
settings have to be tweaked individually anyway, sometimes even per
board revision due to different fan cabling etc.
> -- Every chip is programmed differently, so we need a driver for every
> chip, even if coreboot doesn't care about any other chip specifics;
Hm. I don't understand that. Why can't a generic PCI device handle the
setting of the subsystem IDs?
> -- OS drivers using this subsystem ID might use it to decide the chip
> is configured in a certain way.
We need to be bug-for-bug compatible in most cases anyway.
> What are the downsides to not programming an SSID/SSVID?
Except non-matching drivers and non-matching flashrom entries?
I think some vendor tools use subsystem IDs as a way to verify they are
running on hardware of a specific vendor.
More information about the coreboot