On Friday 15 Jan 2010 6:51:30 pm Takashi Iwai wrote:
At Fri, 15 Jan 2010 18:35:19 +0530, Kunal Gangakhedkar wrote:
On my laptop (HP dv6-1110ax), there are no OEM strings in SMBIOS of type "HP_Mute_LED*". Hence, the GPIO for the mute button LED doesn't get set properly. I didn't find the strings in my cousin's laptop (HP dv9500t CTO) either.
As per the documentation of find_mute_led_gpio(), these strings occur in HP B-series systems - so, before scanning the SMBIOS strings, we need to check if we're dealing with a B-series system. Need to get confirmation from HP if this logic takes care of all the systems. I'm trying to poke a friend there.
Please let me know if this looks OK or needs changes.
Well, the open switch() for blike-system should be replaced with set_hp_led_gpio(). That's the very purpose I proposed to create a function.
I don't think you can do that since both cases (b-like and non-b-like) have different ways of setting the gpio.
Thinking the logic again, however, it might be safer to check DMI entries no matter which model is. Then set statically if it's DV series (i.e. !hp_blike_system()) as fallback. I suppose HP will implement the DMI entry for their new BIOS on other models in future, too, so the chance is high that the right setup is detected through DMI check instead of blindly fixed setup.
They're notorious to discontinue models really fast. For example, my laptop model is already discontinued in less than 6 months. So, I don't think I'll be getting updates for my BIOS at all. What do you propose for such cases?
I agree with your approach that we should be checking for DMI string unconditionally and use the fixed setup as fallback - I can send the patch with those fixes too. Let me know if that's what you'd prefer.
Thanks, Kunal
thanks,
Takashi