http://bugzilla.suse.com/show_bug.cgi?id=1019316 http://bugzilla.suse.com/show_bug.cgi?id=1019316#c11 --- Comment #11 from Hans de Goede --- (In reply to Takashi Iwai from comment #10)

(In reply to Hans de Goede from comment #9)

...

(In reply to Takashi Iwai from comment #8)

...

(In reply to Hans de Goede from comment #7)

...

Hi,

(In reply to Takashi Iwai from comment #6)

...

Unfortunately it can't work:

Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Default string Product Name: Default string Version: Default string Serial Number: Default string

BIOS must fill the right strings to DMI entries. Do you have a BIOS update? Or inform/ask to the manufacturer about this.

I'm not sure which BIOS Adrien has, but I've the latest version of the BIOS (where they removed almost all settings, which in a way is a good thing as before you could break the system in many interesting ways), but this is still unfixed.

I also noticed this problem, as we really need a quirk for the wrongly enabled sdio-wifi node in ACPI too, which causes the actually used pci-e wifi to not work when probed by the sdhci driver (likely the enable gpio gets set to disabled by the sdhci-acpi code)...

I was thinking that maybe we need some other way to uniquely identify machines, like doing a sha256sum over the entire BIOS image, or some such ?

Alternatively since without a way to apply quirks we're going to need a dsdt overlay (see bug 1019337) would it be possible to fix this in an updated dstd ?

Well, I'm not sure whether DSDT may overwrite DMI things.

The idea was not to override the DMI strings (which it indeed cannot do AFAICT) but rather to put the right info directly into the DSDT, that is I'm assuming that the rt5645 looks for some info in the ACPI tables to determine to use jack detection and instead of adding a quirk to make the kernel override the ACPI based detection I suggest we add the right info to the DSDT so that the acpi based detection finds what it expects. I hope that makes sense.

Well, rt5645 driver uses the DMI match to determine which platform data to set. The platform data can be passed from the machine driver side, but in anyway, we need a proper way to identify GPD Win. Currently there is no good way...

So the platform data never comes from the ACPI for the codec ? Now a days a lot of devices have info in ACPI, like how info about this would be in devicetree on ARM.

...

...

Looking through the whole h/w info, the only reasonable unique id is PCI SSID of the Broadcom chip, 17f9:0036. I guess this is specific to GPD Win.

179f as vendor appears to be: http://www.gemtek.com.tw/products.html which is a generic vendor of wifi modules :|

...

But the best would be to have a fixed BIOS with a correct DMI string...

That would require all users with a GPD win to flash their BIOS, so although I would love for the DMI strings to have been correct from the start, I'm afraid that getting them fixed now is not really a good solution.

The machine doesn't let identified as GPD Win. That's a fundamental problem

Agreed, if you can find a way to contact GPD and ask for a BIOS update that certainly would be a good idea regardless.

If any, rather a generic module option would be better, IMO.

Agreed that a generic module option would be good, also potentially for other boards. -- You are receiving this mail because: You are on the CC list for the bug.