From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7704370 for ; Mon, 17 May 2021 09:03:04 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 6790E610FA; Mon, 17 May 2021 09:03:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621242183; bh=gUm10dUf7/+1mJLO5+h9BYtkSzLqC7rGuCMNeD5x/QQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=eRm58A+Po82x7w95vbhr3Ay/dAexkc6TwlY75gPGqbuRRZrpuGZkidKwTTDiFrF5b 5eEJkmtOvOE3uHJ6WUk56SR1hbZPQenObObSgvwlLuYRSUHu0QghuMUiTfFDkFQJNA r4YXsSz+OIYQOp++ZTaqJJTv5KcQ37MSvtV1EIBfWg9rDYOBsU7Ss/PX3SwXw9s8Bj /p23lO1tI9QAA94oLZZObABo8oUSjQnrT79pNeLY2HFvGIaEFBebNqHm0tG8/VsfAW OyI5i3xemMd1nJD4vFavP07ZY0DrTX6B6oLrGJWvc9GDoBIs1uKl3UVpxfMKqF0M2I m84dPm3FtfPhw== Date: Mon, 17 May 2021 11:02:58 +0200 From: Mauro Carvalho Chehab To: Greg KH Cc: linuxarm@huawei.com, mauro.chehab@huawei.com, Pavel Machek , linux-leds@vger.kernel.org, Mauro Carvalho Chehab , devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev Subject: Re: [PATCH 00/17] Add an experimental driver for Intel NUC leds Message-ID: <20210517110258.341da12c@coco.lan> In-Reply-To: References: X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Em Mon, 17 May 2021 10:18:57 +0200 Greg KH escreveu: > On Sun, May 16, 2021 at 12:53:28PM +0200, Mauro Carvalho Chehab wrote: > > Hi Greg, > > > > This series add support for the LEDs found at Intel NUCs since > > NUC version 6. > > > > On several NUC models, the function of the LEDs are programmable, > > which allow them to indicate several different hardware events. > > > > They can even be programmed to represent an userspace-driven event. > > > > Some models come with single colored or dual-colored LEDs, but > > high end models have RGB LEDs. > > > > Programming them can ether be done via BIOS or by the OS. > > > > There are 3 different API types, and there is already some OOT > > drivers that were written to support them, using procfs, each > > one using a different (and IMO confusing) API. > > > > After looking at the existing drivers and not liking the uAPI > > interfaces there, I opted to write a new driver from scratch, > > unifying support for all different versions and using sysfs > > via the leds class. > > Just do this the "right way" and not add it to staging first. Just use > the existing LED class apis and all should be fine, no need for doing > anything unusual here. I'm using the standard LED class already (but not triggers), and the standard WMI support. Still, this API is complex, as it controls the LED behavior even when the machine is suspended. I would feel more comfortable if the ABI is not set into a stone at the beginning. But it is your and Pavel's call. Thanks, Mauro 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=-5.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_2 autolearn=no 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 40CC3C433B4 for ; Mon, 17 May 2021 09:03:14 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0145461184 for ; Mon, 17 May 2021 09:03:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0145461184 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id BEE21403BB; Mon, 17 May 2021 09:03:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDM0hRAnLq0Z; Mon, 17 May 2021 09:03:09 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp4.osuosl.org (Postfix) with ESMTP id 8E54A403D7; Mon, 17 May 2021 09:03:09 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by ash.osuosl.org (Postfix) with ESMTP id 165A81BF2BB for ; Mon, 17 May 2021 09:03:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 0DCBA60822 for ; Mon, 17 May 2021 09:03:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=kernel.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq1KLpE9GvAd for ; Mon, 17 May 2021 09:03:04 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp3.osuosl.org (Postfix) with ESMTPS id 1307460803 for ; Mon, 17 May 2021 09:03:04 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 6790E610FA; Mon, 17 May 2021 09:03:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621242183; bh=gUm10dUf7/+1mJLO5+h9BYtkSzLqC7rGuCMNeD5x/QQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=eRm58A+Po82x7w95vbhr3Ay/dAexkc6TwlY75gPGqbuRRZrpuGZkidKwTTDiFrF5b 5eEJkmtOvOE3uHJ6WUk56SR1hbZPQenObObSgvwlLuYRSUHu0QghuMUiTfFDkFQJNA r4YXsSz+OIYQOp++ZTaqJJTv5KcQ37MSvtV1EIBfWg9rDYOBsU7Ss/PX3SwXw9s8Bj /p23lO1tI9QAA94oLZZObABo8oUSjQnrT79pNeLY2HFvGIaEFBebNqHm0tG8/VsfAW OyI5i3xemMd1nJD4vFavP07ZY0DrTX6B6oLrGJWvc9GDoBIs1uKl3UVpxfMKqF0M2I m84dPm3FtfPhw== Date: Mon, 17 May 2021 11:02:58 +0200 From: Mauro Carvalho Chehab To: Greg KH Subject: Re: [PATCH 00/17] Add an experimental driver for Intel NUC leds Message-ID: <20210517110258.341da12c@coco.lan> In-Reply-To: References: X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devel@driverdev.osuosl.org, linux-staging@lists.linux.dev, linuxarm@huawei.com, linux-kernel@vger.kernel.org, Pavel Machek , mauro.chehab@huawei.com, Mauro Carvalho Chehab , linux-leds@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" Em Mon, 17 May 2021 10:18:57 +0200 Greg KH escreveu: > On Sun, May 16, 2021 at 12:53:28PM +0200, Mauro Carvalho Chehab wrote: > > Hi Greg, > > > > This series add support for the LEDs found at Intel NUCs since > > NUC version 6. > > > > On several NUC models, the function of the LEDs are programmable, > > which allow them to indicate several different hardware events. > > > > They can even be programmed to represent an userspace-driven event. > > > > Some models come with single colored or dual-colored LEDs, but > > high end models have RGB LEDs. > > > > Programming them can ether be done via BIOS or by the OS. > > > > There are 3 different API types, and there is already some OOT > > drivers that were written to support them, using procfs, each > > one using a different (and IMO confusing) API. > > > > After looking at the existing drivers and not liking the uAPI > > interfaces there, I opted to write a new driver from scratch, > > unifying support for all different versions and using sysfs > > via the leds class. > > Just do this the "right way" and not add it to staging first. Just use > the existing LED class apis and all should be fine, no need for doing > anything unusual here. I'm using the standard LED class already (but not triggers), and the standard WMI support. Still, this API is complex, as it controls the LED behavior even when the machine is suspended. I would feel more comfortable if the ABI is not set into a stone at the beginning. But it is your and Pavel's call. Thanks, Mauro _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel