Segher Boessenkool <segher(a)kernel.crashing.org> writes:
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.
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.
subsystem device id is the ambiguous one.
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
Remind me, what _is_ the current behaviour?
Have one default SSVID/SSDID per motherboard, if that default
value is not set I think we assume 0.
The proposal was to have SSVID/SSDID programmed individually for
each part on the motherboard.
I see two options:
a) Don't program it, leave it at 0.
b) Program it the same as the factory BIOS does.
c) Program it to the proper value
for a native LinuxBIOS board.
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;
Of course. This is something that lives in the
per mainboard configuration
and should be done at the time we port to a board. It should not
be something that a user specifies in Kconfig we deciding to compile
for a board.
-- Every chip is programmed differently, so we need a
driver for every
chip, even if coreboot doesn't care about any other chip specifics;
Assuming we even get the option. For anything not designed to be integrated
on a motherboard you need a mechanism that programs the SSVID/SSDID before
the firmware runs. Generally we would also need a driver if it is
possible to disable that chip. I don't believe this is unreasonable
-- OS drivers using this subsystem ID might use it to
decide the chip
is configured in a certain way.
Then they are either (a) broken if it is software configuration or
will (b) break if they are reasonably looking for hardware configuration
and we don't provide it. Which argues for properly setting the SSVID/SSDID.
What are the downsides to not programming an
The goal when the code was added was to correctly support the SSID/SSVID.
With an ultimate goal of identifying a motherboard by looking at them.
If someone is doing a quick port or a hack I agree ignoring the issue
is better than doing the wrong thing. If you are doing a production
quality port it isn't an especially hard thing to get right, and so
if we have the opportunity we should set it.