[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