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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 03098C43441 for ; Thu, 22 Nov 2018 13:44:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C34E420672 for ; Thu, 22 Nov 2018 13:44:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C34E420672 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 S2437002AbeKWAX0 (ORCPT ); Thu, 22 Nov 2018 19:23:26 -0500 Received: from mx2.suse.de ([195.135.220.15]:55288 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727723AbeKWAX0 (ORCPT ); Thu, 22 Nov 2018 19:23:26 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 332F4AD36; Thu, 22 Nov 2018 13:43:59 +0000 (UTC) Date: Thu, 22 Nov 2018 14:43:58 +0100 Message-ID: From: Takashi Iwai To: Pavel Machek Cc: Andy Shevchenko , Ayman Bagabas , ALSA Development Mailing List , Hui Wang , Andy Shevchenko , Darren Hart , Jaroslav Kysela , Kailang Yang , Linux Kernel Mailing List , Platform Driver Subject: Re: [PATCH v3 3/3] ALSA: hda: add support for Huawei WMI micmute LED In-Reply-To: <20181122131802.GB13339@amd> References: <20181108171701.4444-4-ayman.bagabas@gmail.com> <20181119235713.GB7367@amd> <20181120091039.GA16916@amd> <20181120093610.GF16916@amd> <20181120115159.GG16916@amd> <20181122131802.GB13339@amd> 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/26 (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=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 22 Nov 2018 14:18:02 +0100, Pavel Machek wrote: > > On Thu 2018-11-22 13:36:43, Andy Shevchenko wrote: > > On Tue, Nov 20, 2018 at 2:19 PM Takashi Iwai wrote: > > > > > > On Tue, 20 Nov 2018 12:51:59 +0100, > > > Pavel Machek wrote: > > > > > > > > Hi! > > > > > > > > > > You have general-purpose LED, yet you are treating it as "something > > > > > > special". That means ugly code (quoted above) and lack of flexibility. > > > > > > > > > > > > For example, if my notebook lacks HDD LED, I can use scrollock LED for > > > > > > that instead. Or, in reverse way, maybe "mic mute" LED is not useful > > > > > > for me, and I'd like to use it for notifications instead. > > > > > > > > > > I'm not against adding the LEDs device implementation for any exotic > > > > > usage. > > > > > > > > > > But for the audio mute LED features, you'll need really lots of other > > > > > works if it were implemented via leds device. That's the hardest > > > > > part, and a few lines of hooks solves it easily in the kernel side. > > > > > That's all about it. > > > > > > > > > > If you are ready for submitting the real solutions in user-space side > > > > > (patching PulseAudio and whatever all existing sound daemons, and > > > > > creating yet another daemon for non-PA systems (another footprint, > > > > > lovely), and so on), we can happily delete such in-kernel hooks :) > > > > > > > > I'm not saying we should move it to the userspace. > > > > > > > > I'm saying this should be "normal" led. drivers/leds/led-huawei-acpi.c, > > > > or something. Perhaps this acpi stuff is so similar you don't really > > > > need .c code. > > > > > > > > And then there should be a "mic muted" trigger. Similar to > > > > drivers/leds/trigger/ledtrig-disk.c. > > > > > > And who will trigger this, e.g. when the mixer is muted? > > > > Is this settled? I'm encouraged to promote this series to our for-next branch. > > I'd prefer this to be normal LED and "mic muted" to become normal > trigger. But how would you solve the existing problem? As already mentioned, you'll need to hook the LED trigger and the actual mixer value change. This is the biggest missing piece, and it's the very reason we have the exported symbol from the platform driver side. So, if you prefer in that way, please implement that for the existing driver (thinkpad_acpi and dell-laptop) at first. I'll be really happy to get rid of the present ugly solution! But it's been there just because it's not so trivial at all. FWIW, this must be all done inside the kernel; otherwise you'll hit a regression. If the path via leds class can't be achieved quickly, I'd prefer taking the current approach at first. Once after it's done for those above, we can apply the same for huawei-wmi later, too. thanks, Takashi