Bug 14878 - DMI OEM string checks fail in find_mute_led_gpio() from patch_sigmatel.c
DMI OEM string checks fail in find_mute_led_gpio() from patch_sigmatel.c
Status: RESOLVED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA)
All Linux
: P1 low
Assigned To: Jaroslav Kysela
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-25 18:30 UTC by Kunal Gangakhedkar
Modified: 2010-01-15 17:43 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.33-rc2
Tree: Mainline
Regression: No


Attachments
dmidecode --dump output from HP dv6 laptop (5.14 KB, text/plain)
2009-12-25 18:30 UTC, Kunal Gangakhedkar
Details

Description Kunal Gangakhedkar 2009-12-25 18:30:45 UTC
Created attachment 24308 [details]
dmidecode --dump output from HP dv6 laptop

Recently bought HP dv6 series laptop.
The DMI table is attached taken by "dmidecode --dump".

In particular, the OEM string type as dumped by "dmidecode --dump" is:
Handle 0x0008, DMI type 11, 5 bytes
	Header and Data:
		0B 05 08 00 04
	Strings:
		24 48 50 24 00
		"$HP$"
		4C 4F 43 23 41 43 4A 00
		"LOC#ACJ"
		41 42 53 20 37 30 2F 37 31 20 37 39 20 37 41 20
		37 42 20 37 43 00
		"ABS 70/71 79 7A 7B 7C"
		43 4E 42 31 20 30 31 31 30 30 30 30 30 31 34 31
		32 31 30 30 30 30 00
		"CNB1 01100000141210000"

Cousin brother also has an HP laptop - don't know the model.
Here is the output from his machine:
Handle 0x000B, DMI type 11, 5 bytes
	Header and Data:
		0B 05 0B 00 03
	Strings:
		24 48 50 24 00
		"$HP$"
		4C 4F 43 23 41 42 41 00
		"LOC#ABA"
		41 42 53 20 37 30 2F 37 31 20 37 39 20 37 41 20
		37 42 20 37 43 00
		"ABS 70/71 79 7A 7B 7C"


Following lines have the sscanf() calls specifically checking for "HP_Mute_LED*" OEM strings:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=sound/pci/hda/patch_sigmatel.c;h=eeda7beeb57a2300fe38ed2e83b7b1d22dcfeea0;hb=HEAD#l4760

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=sound/pci/hda/patch_sigmatel.c;h=eeda7beeb57a2300fe38ed2e83b7b1d22dcfeea0;hb=HEAD#l4766

But, as can be seen from the dmidecode output, those strings do not appear on my laptop. So, is it that the smbios/dmi tables are broken or the alsa code is broken?

What I wonder from looking at the code is - there is already a check for PCI_VENDOR_ID_HP, why need to again look for SMBIOS/DMI stuff?
Comment 1 Kunal Gangakhedkar 2009-12-25 18:57:55 UTC
(In reply to comment #0)
> Created an attachment (id=24308) [details]
> dmidecode --dump output from HP dv6 laptop
> 
> Recently bought HP dv6 series laptop.
> The DMI table is attached taken by "dmidecode --dump".
> 
> In particular, the OEM string type as dumped by "dmidecode --dump" is:
> Handle 0x0008, DMI type 11, 5 bytes
>     Header and Data:
>         0B 05 08 00 04
>     Strings:
>         24 48 50 24 00
>         "$HP$"
>         4C 4F 43 23 41 43 4A 00
>         "LOC#ACJ"
>         41 42 53 20 37 30 2F 37 31 20 37 39 20 37 41 20
>         37 42 20 37 43 00
>         "ABS 70/71 79 7A 7B 7C"
>         43 4E 42 31 20 30 31 31 30 30 30 30 30 31 34 31
>         32 31 30 30 30 30 00
>         "CNB1 01100000141210000"
> 
> Cousin brother also has an HP laptop - don't know the model.

His model is dv9500t - which is pretty old, IIRC.

> Here is the output from his machine:
> Handle 0x000B, DMI type 11, 5 bytes
>     Header and Data:
>         0B 05 0B 00 03
>     Strings:
>         24 48 50 24 00
>         "$HP$"
>         4C 4F 43 23 41 42 41 00
>         "LOC#ABA"
>         41 42 53 20 37 30 2F 37 31 20 37 39 20 37 41 20
>         37 42 20 37 43 00
>         "ABS 70/71 79 7A 7B 7C"
> 
> 
> Following lines have the sscanf() calls specifically checking for
> "HP_Mute_LED*" OEM strings:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=sound/pci/hda/patch_sigmatel.c;h=eeda7beeb57a2300fe38ed2e83b7b1d22dcfeea0;hb=HEAD#l4760
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=sound/pci/hda/patch_sigmatel.c;h=eeda7beeb57a2300fe38ed2e83b7b1d22dcfeea0;hb=HEAD#l4766
> 
> But, as can be seen from the dmidecode output, those strings do not appear on
> my laptop. So, is it that the smbios/dmi tables are broken or the alsa code is
> broken?
> 
> What I wonder from looking at the code is - there is already a check for
> PCI_VENDOR_ID_HP, why need to again look for SMBIOS/DMI stuff?
Comment 2 Kunal Gangakhedkar 2010-01-15 17:43:50 UTC
Fix committed in sound-2.6 git tree:
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commit;h=d38cce7046cfd0011f69d5dcf6a22525438154f6

Note You need to log in before you can comment on or make changes to this bug.