From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by aws-us-west-2-korg-lkml-1.web.codeaurora.org (Postfix) with ESMTP id 0A2BFC5CFC1 for ; Fri, 15 Jun 2018 12:51:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BD9E6208B5 for ; Fri, 15 Jun 2018 12:51:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BD9E6208B5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936230AbeFOMvu (ORCPT ); Fri, 15 Jun 2018 08:51:50 -0400 Received: from mx2.suse.de ([195.135.220.15]:38990 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755897AbeFOMvt (ORCPT ); Fri, 15 Jun 2018 08:51:49 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D7692AC55; Fri, 15 Jun 2018 12:51:47 +0000 (UTC) Date: Fri, 15 Jun 2018 14:51:47 +0200 Message-ID: From: Takashi Iwai To: Pali =?UTF-8?B?Um9ow6Fy?= Cc: Henrique de Moraes Holschuh , ibm-acpi-devel@lists.sourceforge.net, platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: ThinkPad T480s & LED_MUTE, LED_MICMUTE In-Reply-To: <20180608111057.4wxpg7m7nm7suf6n@pali> References: <20180608111057.4wxpg7m7nm7suf6n@pali> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 08 Jun 2018 13:10:57 +0200, Pali Rohár wrote: > > Hi! With up-to-date thinkpad_acpi.ko driver on ThinkPad T480s I'm seeing > a strange behavior of LEDs which are integrated into mic mute (Fn+F4) > and mute (Fn+F1) keys. > > When thinkpad_acpi.ko is not loaded, then mute key is working fine. When > pressed, it correctly generates KEY_MUTE on AT Translated Set 2 keyboard > input device and also turn on/of mute led. But when micmute key is > pressed then, nothing happen. No key event is reported and also led is > not turned on/off. > > On the other hand, when thinkpad_acpi.ko is loaded, then both buttons > mute and micmute correctly generates input events; mute via AT keyboard > and micmute via ThinkPad Extra Buttons. But led is not changed. When > thinkpad_acpi.ko is loaded it turn off both leds (mute and micmute) and > leds after pressing any of those buttons, leds are not turned on again. > > When thinkpad_acpi.ko is unloaded, then pressing mute button again start > switching led on/off. > > So it seems that some init sequence of thinkpad_acpi.ko breaks mute led. > And fini sequence of thinkpad_acpi.ko makes mute led working again. Usually the mute LED on Thinkpad is triggered from HD-audio driver (sound/pci/hda/thinkpad_helper.c), and it's a soft-bound via symbol_request(tpacpi_led_set). I thought thinkpad_acpi is auto-loaded when the module gets bound. A possible explanation would be that TPT480s has neither IBM0068, LEN0068 nor LEN0268 ACPI HIDs, hence the driver is not auto-loaded. (In HD-audio driver side, the ACPI ID is checked and the mute LED control is applied only to these three IDs, too.) Meanwhile, when you load thinkpad_acpi, it does still recognize some device and initialize it. By the initialization, it goes out of BIOS control, and the OS control is expected... This is my wild guess. BTW, the reason we have no LED class for these is that we don't want to confuse users by providing multiple ways to access to the single stuff. We've had already the mute LED control from the audio driver since long time ago, we don't want to drop and enforce the user-space solution (that is anyway flakier than in kernel in most cases). thanks, Takashi