[coreboot] Trac reminder: list of new ticket(s)

Carl-Daniel Hailfinger 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.
> 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.

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

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
desktop board)

>> 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 mailing list