Segher Boessenkool <[EMAIL PROTECTED]> 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 -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
