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

[Eric W. Biederman]

Segher Boessenkool <segher at 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.
>
> 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?

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

> -- 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 SSID/SSVID?

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.

Eric