Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net writes:
On 16.07.2008 20:12, Eric W. Biederman wrote:
Segher Boessenkool segher@kernel.crashing.org writes:
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.
The big problem with that is that we either have to get subsystem device IDs from the board vendor (unlikely) or we allocate a vendor ID for coreboot and start our own numbering (painful).
We just copy the vendor id and the subsys id that the board vendor uses. Or if it a pure LinuxBIOS board then ask the board maker for a pci vendor id, and device id for the board. I don't expect that to be too difficult for a company that is making it's own boards.
Indeed. The place for this is in the dts.
-- 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.
I think doing this exactly the same way as a vendor BIOS is important. Does the vendor BIOS really set the subsystem IDs before the option ROM is run or does this happen afterwards?
It is a PCI requirement that the SSVID/SSDID are set before software can read them, as running the option rom is optional. For onboard devices there is enough wiggle room they can ask firmware to program it.
-- 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.
We need to mirror that sonftware configuration anyway if we don't want to change the drivers in every possible OS as well. And "proper" values are very difficult to define if our device configuration doesn't match what the drivers expect.
Yep.
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.
What about a global default which can be overridden per device? Most boards I have use the same subsystem device ID for over 50% of the devices on a given board, so this proposal would reduce the effort to zero for reasonable motherboards.
That is what I would implement. A global default. And if we don't specify the global default the global default is 0.
Eric