Just in case someone wants this as plain text...
Regards, Carl-Daniel
On 15.07.2008 17:00, coreboot tracker wrote:
Ticket Owner Status Description #110 http://tracker.coreboot.org/trac/coreboot/ticket/110 somebody new Allow for per-device subsystem IDs #109 http://tracker.coreboot.org/trac/coreboot/ticket/109 stepan new flash base autodetection on AMD SC520 #108 http://tracker.coreboot.org/trac/coreboot/ticket/108 somebody new Add int 10 VESA video driver to libpayload #107 http://tracker.coreboot.org/trac/coreboot/ticket/107 somebody new flashrom: Display test status in -L chip listing #106 http://tracker.coreboot.org/trac/coreboot/ticket/106 somebody new flashrom: Add -T to automatically test all flash chip operations #105 http://tracker.coreboot.org/trac/coreboot/ticket/105 somebody new flashrom: add documentation files (ChangeLog etc) that need to be in the release #104 http://tracker.coreboot.org/trac/coreboot/ticket/104 somebody new flashrom: Change flash drivers to never erase data before writing #102 http://tracker.coreboot.org/trac/coreboot/ticket/102 stuge new flashrom: coreboot ROM image file identification heuristic is broken #101 http://tracker.coreboot.org/trac/coreboot/ticket/101 stuge new flashrom: Remove pciutils check from Makefile #100 http://tracker.coreboot.org/trac/coreboot/ticket/100 somebody new flashrom: Change start/end -s and -e to -S and -E, and change erase -E to -e. #98 http://tracker.coreboot.org/trac/coreboot/ticket/98 somebody new Eliminate false positive "unknown .. SPI chip" matches #95 http://tracker.coreboot.org/trac/coreboot/ticket/95 somebody new Run coreboot in VirtualBox #88 http://tracker.coreboot.org/trac/coreboot/ticket/88 oxygene new Add UHCI/OHCI/EHCI support to GRUB2 #85 http://tracker.coreboot.org/trac/coreboot/ticket/85 somebody new fix milli/mega and 1000/1024 ambiguities #82 http://tracker.coreboot.org/trac/coreboot/ticket/82 oxygene new Fix the memory map in coreboot v3 #77 http://tracker.coreboot.org/trac/coreboot/ticket/77 somebody new hang on the "Jumping to coreboot" step on via epia-m with 4-chip 128Mbyte DDR module #76 http://tracker.coreboot.org/trac/coreboot/ticket/76 rminnich new coreboot messages should be accessible in dmesg #65 http://tracker.coreboot.org/trac/coreboot/ticket/65 uwe new Unify SuperIO code? #49 http://tracker.coreboot.org/trac/coreboot/ticket/49 somebody new TPM support for LinuxBIOS #45 http://tracker.coreboot.org/trac/coreboot/ticket/45 somebody new Enforce consistent coding style #43 http://tracker.coreboot.org/trac/coreboot/ticket/43 somebody new Add graphics memory hole to e820 map #35 http://tracker.coreboot.org/trac/coreboot/ticket/35 new Make it possible to boot Windows using coreboot #28 http://tracker.coreboot.org/trac/coreboot/ticket/28 somebody new Finish Intel 440BX port #25 http://tracker.coreboot.org/trac/coreboot/ticket/25 somebody new Clean up x86 emulator in the tree? #24 http://tracker.coreboot.org/trac/coreboot/ticket/24 somebody new Remove all files which have a GPL-incompatible license #23 http://tracker.coreboot.org/trac/coreboot/ticket/23 somebody new Use Doxygen-style comments #18 http://tracker.coreboot.org/trac/coreboot/ticket/18 somebody new autoprobe apic cluster and application processors on K8 systems #17 http://tracker.coreboot.org/trac/coreboot/ticket/17 stepan new clean up coreboot table handling #16 http://tracker.coreboot.org/trac/coreboot/ticket/16 ollie new I2C driver and mainboard Config.lb #12 http://tracker.coreboot.org/trac/coreboot/ticket/12 stepan new Make coreboot work on a laptop #11 http://tracker.coreboot.org/trac/coreboot/ticket/11 yhlu new pirq table automation #8 http://tracker.coreboot.org/trac/coreboot/ticket/8 uwe new Fully support all components of the ITE Super I/Os #5 http://tracker.coreboot.org/trac/coreboot/ticket/5 uwe new Add license header to all source files #2 http://tracker.coreboot.org/trac/coreboot/ticket/2 somebody new Complete tables of supported motherboards
coreboot tracker svn@coreboot.org writes:
#110 Allow for per-device subsystem IDs
What is the proper procedure for saying per-device subsystem IDs is a dumb idea.
The subsystem IDs roughly identify the PCB a component sits on. So unless you have multiple pluggable boards in a system there should only be one subsystem vendor and one subsystem device id.
Eric
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Eric W. Biederman Sent: Tuesday, July 15, 2008 1:38 PM To: coreboot tracker Cc: coreboot@coreboot.org Subject: Re: [coreboot] Trac reminder: list of new ticket(s)
coreboot tracker svn@coreboot.org writes:
#110 Allow for per-device subsystem IDs
What is the proper procedure for saying per-device subsystem IDs is a dumb idea.
The subsystem IDs roughly identify the PCB a component sits on. So unless you have multiple pluggable boards in a system there should only be one subsystem vendor and one subsystem device id.
I agree with Eric here. I question the need for subsystem IDs in the first place. Is there a particular OS that requires this info???
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
The subsystem IDs roughly identify the PCB a component sits on. So unless you have multiple pluggable boards in a system there should only be one subsystem vendor and one subsystem device id.
I agree with Eric here. I question the need for subsystem IDs in the first place. Is there a particular OS that requires this info???
Yes, Linux for example, for certain devices.
I agree subsystem IDs are useless in most cases. But for certain devices there is the established practice to mark certain hardware configurations (or device firmware type/version) with these IDs, so coreboot will have to follow.
Segher
Eric W. Biederman wrote:
coreboot tracker svn@coreboot.org writes:
#110 Allow for per-device subsystem IDs
What is the proper procedure for saying per-device subsystem IDs is a dumb idea.
The subsystem IDs roughly identify the PCB a component sits on. So unless you have multiple pluggable boards in a system there should only be one subsystem vendor and one subsystem device id.
Is this the official definition? Where does this originate from?
In practice the subsystem vendor IDs are quite arbitrary and definitely not the same for all PCI devices per mainboard on any of the mainboards we have here. In fact, what I have seen quite often is that every PCI device has it's device/vendor ID set as subsystem IDs.
The subsystem information is used by lspci to correctly identify some devices. Plus, more importantly, we use it in flashrom to identify mainboards. Using a unique device ID per board will require us to have two sets of information, one for legacy bios and one for coreboot.
While using per-board subsystem ids sounds the right thing as per your reasoning, I vote to not enforce that behavior, but make it configurable.
Stefan
On 15/07/08 23:06 +0200, Stefan Reinauer wrote:
The subsystem information is used by lspci to correctly identify some devices. Plus, more importantly, we use it in flashrom to identify mainboards. Using a unique device ID per board will require us to have two sets of information, one for legacy bios and one for coreboot.
The kernel also uses it rarely to implement quirks for specific bugs on individual PCBs.
Jordan
In practice the subsystem vendor IDs are quite arbitrary and definitely not the same for all PCI devices per mainboard
They aren't even allowed to be the same for all devices on a mainboard: the subsystem IDs should uniquely identify the device, without having to look at the "regular" IDs as well.
Some legacy BIOSes break this rule, of course.
Segher
Segher Boessenkool wrote:
In practice the subsystem vendor IDs are quite arbitrary and definitely not the same for all PCI devices per mainboard
They aren't even allowed to be the same for all devices on a mainboard: the subsystem IDs should uniquely identify the device, without having to look at the "regular" IDs as well.
Again, mind me asking. Where did you find this definition?
Stefan Reinauer stepan@coresystems.de writes:
Segher Boessenkool wrote:
In practice the subsystem vendor IDs are quite arbitrary and definitely not the same for all PCI devices per mainboard
They aren't even allowed to be the same for all devices on a mainboard: the subsystem IDs should uniquely identify the device, without having to look at the "regular" IDs as well.
Again, mind me asking. Where did you find this definition?
Section 6.2.4 of the PCI specification states:
These registers are used to uniquely identify the add-in card or subsystem where the PCI device resides. The provide a mechanism for add-in card vendors to distinguish their add-in cards from one another even though the add-in cards may have the same PCI controller on them (and therefore the same Vendor ID and Device ID).
Or in paraphrase they identify the PCB the IC sits on.
Eric
Section 6.2.4 of the PCI specification states:
These registers are used to uniquely identify the add-in card or subsystem where the PCI device resides. The provide a mechanism for add-in card vendors to distinguish their add-in cards from one another even though the add-in cards may have the same PCI controller on them (and therefore the same Vendor ID and Device ID).
Or in paraphrase they identify the PCB the IC sits on.
"... add-in card *or subsystem* ..."
I agree the spec could be more clear, and that it doesn't at all give guidance on how these IDs should be used; but it certainly does not say that completely unrelated devices should be assigned the same subsystem ID, just because they are soldered to the same board.
Segher
In practice the subsystem vendor IDs are quite arbitrary and definitely not the same for all PCI devices per mainboard
They aren't even allowed to be the same for all devices on a mainboard: the subsystem IDs should uniquely identify the device, without having to look at the "regular" IDs as well.
Again, mind me asking. Where did you find this definition?
In my memory, of course. It turns out that the actual PCI spec isn't so very precise, sigh. Must be hardware engineers who wrote that thing ;-)
Anyway, it turns out this problem isn't new (well obviously, duh), I found this (accepted) proposal for the Open Firmware PCI binding:
http://playground.sun.com/1275/proposals/Closed/Accepted/430-it.txt
It describes the situation nicely, I think (search for "poll" if you're in a hurry and want to skip to the juicy bits).
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!)
Segher
Segher Boessenkool segher@kernel.crashing.org writes:
In practice the subsystem vendor IDs are quite arbitrary and definitely not the same for all PCI devices per mainboard
They aren't even allowed to be the same for all devices on a mainboard: the subsystem IDs should uniquely identify the device, without having to look at the "regular" IDs as well.
Again, mind me asking. Where did you find this definition?
In my memory, of course. It turns out that the actual PCI spec isn't so very precise, sigh. Must be hardware engineers who wrote that thing ;-)
Anyway, it turns out this problem isn't new (well obviously, duh), I found this (accepted) proposal for the Open Firmware PCI binding:
http://playground.sun.com/1275/proposals/Closed/Accepted/430-it.txt
It describes the situation nicely, I think (search for "poll" if you're in a hurry and want to skip to the juicy bits).
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. 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 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.
I just figure the default should be the current behavior.
Eric
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
Segher Boessenkool segher@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
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).
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.
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?
-- 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.
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.
Regards, Carl-Daniel
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
On 16.07.2008 19:35, Segher Boessenkool wrote:
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.
Agreed. For my laptop, the Intel Pro/Wireless 2200BG is the one onboard(?) device which has a different subsystem vendor ID from all the others. That probably means it is on a different PCB.
The subsystem device id is the ambiguous one.
Indeed.
Yes. I have seen both: - one common subsystem device ID for all onboard devices (my laptop board) - completely different subsystem device IDs for each onboard device (my desktop board)
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;
We already do that. v2 and v3 targets are per-mainboard because SuperI/O settings have to be tweaked individually anyway, sometimes even per board revision due to different fan cabling etc.
-- Every chip is programmed differently, so we need a driver for every chip, even if coreboot doesn't care about any other chip specifics;
Hm. I don't understand that. Why can't a generic PCI device handle the setting of the subsystem IDs?
-- OS drivers using this subsystem ID might use it to decide the chip is configured in a certain way.
We need to be bug-for-bug compatible in most cases anyway.
What are the downsides to not programming an SSID/SSVID?
Except non-matching drivers and non-matching flashrom entries? I think some vendor tools use subsystem IDs as a way to verify they are running on hardware of a specific vendor.
Regards, Carl-Daniel
Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net writes:
-- Every chip is programmed differently, so we need a driver for every chip, even if coreboot doesn't care about any other chip specifics;
Hm. I don't understand that. Why can't a generic PCI device handle the setting of the subsystem IDs?
Because the pci spec doesn't allow for it to be set in software. I coded up some common idioms, when I implemented the support. But there is a lot of variation of where you have to write to set those values.
Except non-matching drivers and non-matching flashrom entries? I think some vendor tools use subsystem IDs as a way to verify they are running on hardware of a specific vendor.
Which is what they are there for.
Eric
Segher Boessenkool wrote:
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!)
Some, like PCIe bridges, have a BAR at that place. The subsystem IDs are kept elsewhere.
Segher Boessenkool segher@kernel.crashing.org writes:
In practice the subsystem vendor IDs are quite arbitrary and definitely not the same for all PCI devices per mainboard
They aren't even allowed to be the same for all devices on a mainboard: the subsystem IDs should uniquely identify the device, without having to look at the "regular" IDs as well.
I suppose. The device in this case is the MOTHERBOARD.
Eric
Stefan Reinauer stepan@coresystems.de writes:
Eric W. Biederman wrote:
coreboot tracker svn@coreboot.org writes:
#110 Allow for per-device subsystem IDs
What is the proper procedure for saying per-device subsystem IDs is a dumb idea.
The subsystem IDs roughly identify the PCB a component sits on. So unless you have multiple pluggable boards in a system there should only be one subsystem vendor and one subsystem device id.
Is this the official definition? Where does this originate from?
A Paraphrased version of the official definition. It comes from the PCI SIG as I recall. I haven't rechecked this since I added support years ago.
In practice the subsystem vendor IDs are quite arbitrary and definitely not the same for all PCI devices per mainboard on any of the mainboards we have here. In fact, what I have seen quite often is that every PCI device has it's device/vendor ID set as subsystem IDs.
Which is probably a default, giving you no board information. Quite likely a bug. The subsystem vendor is not supposed to be the ASIC vendor.
The subsystem information is used by lspci to correctly identify some devices.
Yes. You need to know which board they are on, to identify them.
Plus, more importantly, we use it in flashrom to identify mainboards. Using a unique device ID per board will require us to have two sets of information, one for legacy bios and one for coreboot.
That sounds weird.
While using per-board subsystem ids sounds the right thing as per your reasoning, I vote to not enforce that behavior, but make it configurable.
I can understand overriding it for compatibility, or in other weird cases. The default should still be global to the mainboard.
Eric
On 15.07.2008 19:38, Eric W. Biederman wrote:
coreboot tracker svn@coreboot.org writes:
#110 Allow for per-device subsystem IDs
What is the proper procedure for saying per-device subsystem IDs is a dumb idea.
The subsystem IDs roughly identify the PCB a component sits on. So unless you have multiple pluggable boards in a system there should only be one subsystem vendor and one subsystem device id.
The problem is that almost all x86 mainboards have multiple different subsystem IDs on the same board. If we want to match the vendor BIOS, we have to make them per-device. Some kernel drivers and other software (flashrom) rely on them for specific quirks.
Regards Carl-Daniel
-
Carl-Daniel Hailfinger -
coreboot tracker -
ebiederm＠xmission.com -
Jordan Crouse -
Joseph Smith -
Segher Boessenkool -
Stefan Reinauer