Comment # 11 on bug 1019316 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.