Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1664394imm; Sat, 16 Jun 2018 00:06:28 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKALtAq2yRPHdmU99anx88xskKwWjDvBSIvptX5J9e/H1qZ7KCge5obm268r6rU5rKAlDil X-Received: by 2002:a17:902:8b8c:: with SMTP id ay12-v6mr5515260plb.74.1529132788127; Sat, 16 Jun 2018 00:06:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529132788; cv=none; d=google.com; s=arc-20160816; b=H+OOorhCzsbKIqP+bcUxk+xCxNIB5OxPNNv3joGGZV4AlbLeMZ3ZC2R1fk1cD7wOMd UyT0LhGqvZqa+6Nsb9DwIuQpo7MTwJxGrvtrBwOyrXlHJ05aTVIkE8sn/6peAw/bJxeE tGvJ8OoBEvp2NAJfu1bqaQafM6BbrKSk/z/2hvlTrZc8I4c8Hc5Ri8v7/g/vlPcSwMj6 uB73br7aQ1YmQJgNlxuQILz5lFWQiLqQOkrgEJiRsvtiK4opkBAnBWW3Kw0ve4JpZXn0 WViepxgq2gyQzzDz5oSq6qTxALDcw0hT8iTlwkhWPKfQu3oTXmcKqCnb4bgolgxynl/h 6GGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:subject:cc:to:from:message-id :date:arc-authentication-results; bh=tZdQqNL1S3xSzpAeh7XfRnkxsDUnBXrAyYnE5fSnABc=; b=Pxo68n+FQIZHnkIOK5ffRsf5Y7Jz/JlfTwcM3nRnBBlh+qYK8Hw0eQxXW1yxHxgtSc NX3ZZcSFpZLfF+HVblJAk+7gbyw1k/mxUEf0f6SNX48aCrwjTm+UishKR+2njU2BeGwg Unh+xho26NqMaJiuw6H/bCPnnHp8oGqVyl9hI7WVDxDtO0nCycwNyV8OEi5Hgc13otLL PJYnPVICnKdT9YGx21zWeu6G+Jq+SpR75Kl3qBfprgkk/Sr/2fH1+bYGzTvv0WICZ/eL 1VTyGcbm34+EoYroK40QMekFk4P9oFDN7ubcn/BO6R8E8UqbCE0vT87CTU1MjAbKA+n4 C1Yw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d7-v6si7748373pgf.484.2018.06.16.00.06.12; Sat, 16 Jun 2018 00:06:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932827AbeFPHFo (ORCPT + 99 others); Sat, 16 Jun 2018 03:05:44 -0400 Received: from mx2.suse.de ([195.135.220.15]:36726 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753910AbeFPHFn (ORCPT ); Sat, 16 Jun 2018 03:05:43 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A12DAAED4; Sat, 16 Jun 2018 07:05:41 +0000 (UTC) Date: Sat, 16 Jun 2018 09:05:41 +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: <20180615190959.pqipwnm6a3tf3lxc@pali> References: <20180608111057.4wxpg7m7nm7suf6n@pali> <20180615190959.pqipwnm6a3tf3lxc@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, 15 Jun 2018 21:09:59 +0200, Pali Rohár wrote: > > On Friday 15 June 2018 14:51:47 Takashi Iwai wrote: > > 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. > > I have Debian Stretch kernel (4.9) which does not have LEN0268 alias for > thinkpad_acpi.ko. So thinkpad_acpi.ko is not loaded automatically. But I > have put thinkpad_acpi into /etc/modules and it is now automatically > loaded at boot. That's odd. It's exposed via MODULE_DEVICE_TABLE(acpi, ibm_htk_device_ids); It's been already in 4.9. At this point, something is fishy. > I also compiled upstream version of thinkpad_acpi.ko, loaded it in > Stretch kernel, but it behaves in same way. > > Maybe... there could be a problem that thinkpad_acpi.ko must be already > loaded when sound subsystem is doing initialization? If yes, this could > explain it as /etc/modules is loaded at later stage and manually loading > of new version of thinkpad_acpi.ko at runtime does not help when sound > subsystem is already running. Not really. The HD-audio driver tries to bind with tpacpi_led_set() via symbol_request(). i.e. if it's not present, it tries to load a module. Check whether hda_fixup_thinkpad_acpi() is called and the symbol gets loaded or not. But, I don't think it's worth to debug such an old kernel primarily. Could you test the latest Linus tree or 4.17.x at least as a test basis? > > (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). > > If possible... I would prefer swapped LED behavior: turn led on when > microphone is turned on AND turn led off when microphone is turned off. > Because current behavior is to have turned led off when microphone is > on which seems a bit strange. Also microphone is in majority of time not > used and when is not used it is (or should be) turned off. On the other > hand e.g. CAPSLOCK led is turned on when CAPSLOCK is enabled (and not > opposite) -- which matches uses, it is not used in majority of time. Currently the mixer control to change such LED behavior is provided only for Dell laptops. It'd be trivial to port to Thinkpad, though. I can provide a patch once after you test with the recent kernels. thanks, Takashi