On Sat, Apr 28, 2012 at 01:30:53AM +0200, Stefan Tauner wrote:
The PCI IDs are generic VIA IDs. Only Biostar IDs are those of the LOM, but that would not be a good choice for ID. Accept the generic IDs (+ DMI string) for now because this will be generic soonish(tm) anyway.
- {0x1106, 0x3177, 0x1106, 0x3177, 0x1106, 0x3116, 0x1106, 0x3116, "^KM266-8235$", NULL, NULL, P3, "Biostar", "M7VIQ", 0, OK, w83697xx_memw_enable_2e},
"KM266-8235" is "VIA Northbridge marketing name"-"VIA Southbridge marketing name with VT removed".
This DMI string is not unique at all.
Luc Verhaegen.
On Sat, 28 Apr 2012 01:42:37 +0200 Luc Verhaegen libv@skynet.be wrote:
On Sat, Apr 28, 2012 at 01:30:53AM +0200, Stefan Tauner wrote:
The PCI IDs are generic VIA IDs. Only Biostar IDs are those of the LOM, but that would not be a good choice for ID. Accept the generic IDs (+ DMI string) for now because this will be generic soonish(tm) anyway.
- {0x1106, 0x3177, 0x1106, 0x3177, 0x1106, 0x3116, 0x1106, 0x3116, "^KM266-8235$", NULL, NULL, P3, "Biostar", "M7VIQ", 0, OK, w83697xx_memw_enable_2e},
"KM266-8235" is "VIA Northbridge marketing name"-"VIA Southbridge marketing name with VT removed".
This DMI string is not unique at all.
true, yet there is no real alternative and a rationale was given to why it does not really matter much anyway. just ranting does not really help in this case :)
On Sat, Apr 28, 2012 at 02:06:48AM +0200, Stefan Tauner wrote:
On Sat, 28 Apr 2012 01:42:37 +0200 Luc Verhaegen libv@skynet.be wrote:
On Sat, Apr 28, 2012 at 01:30:53AM +0200, Stefan Tauner wrote:
The PCI IDs are generic VIA IDs. Only Biostar IDs are those of the LOM, but that would not be a good choice for ID. Accept the generic IDs (+ DMI string) for now because this will be generic soonish(tm) anyway.
- {0x1106, 0x3177, 0x1106, 0x3177, 0x1106, 0x3116, 0x1106, 0x3116, "^KM266-8235$", NULL, NULL, P3, "Biostar", "M7VIQ", 0, OK, w83697xx_memw_enable_2e},
"KM266-8235" is "VIA Northbridge marketing name"-"VIA Southbridge marketing name with VT removed".
This DMI string is not unique at all.
true, yet there is no real alternative and a rationale was given to why it does not really matter much anyway. just ranting does not really help in this case :)
Surely a specific board name can still be provided on the command line for horribly broken bioses like this?
Luc Verhaegen.
On Sat, 28 Apr 2012 02:25:02 +0200 Luc Verhaegen libv@skynet.be wrote:
Surely a specific board name can still be provided on the command line for horribly broken bioses like this?
yes, thanks for the suggestion. apparently i forgot that alternative.
On Sat, Apr 28, 2012 at 12:50:19PM +0200, Stefan Tauner wrote:
On Sat, 28 Apr 2012 02:25:02 +0200 Luc Verhaegen libv@skynet.be wrote:
Surely a specific board name can still be provided on the command line for horribly broken bioses like this?
yes, thanks for the suggestion. apparently i forgot that alternative.
I am not sure anymore how much information one has to provide still though, it's been quite a while. I think pci device ids only, no board ids, so that not every command line provided board name is accepted.
Luc Verhaegen.
On Sat, 28 Apr 2012 12:59:59 +0200 Luc Verhaegen libv@skynet.be wrote:
On Sat, Apr 28, 2012 at 12:50:19PM +0200, Stefan Tauner wrote:
On Sat, 28 Apr 2012 02:25:02 +0200 Luc Verhaegen libv@skynet.be wrote:
Surely a specific board name can still be provided on the command line for horribly broken bioses like this?
yes, thanks for the suggestion. apparently i forgot that alternative.
i have committed the resulting board enable patch in r1566.
I am not sure anymore how much information one has to provide still though, it's been quite a while. I think pci device ids only, no board ids, so that not every command line provided board name is accepted.
device ids are mandatory, subsystem ids are not checked atm (for non-autodetected boards), but i have left them in anyway. the dmi string is also not checked at all in this case... ill take a look at refactoring the involved functions and the looooong comment explaining all that soon-ish.