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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, T_DKIMWL_WL_HIGH 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 E0ADBC04AB1 for ; Thu, 9 May 2019 21:44:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AA8C6217D7 for ; Thu, 9 May 2019 21:44:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="bmIfRFy/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726962AbfEIVod (ORCPT ); Thu, 9 May 2019 17:44:33 -0400 Received: from fllv0016.ext.ti.com ([198.47.19.142]:36514 "EHLO fllv0016.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726219AbfEIVoc (ORCPT ); Thu, 9 May 2019 17:44:32 -0400 Received: from fllv0035.itg.ti.com ([10.64.41.0]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id x49LiG3a106503; Thu, 9 May 2019 16:44:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1557438256; bh=Q9Z3Cdxba9fPA3W2vhRBY2VSHgjkNI6BHfKusWm8Mp4=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=bmIfRFy/ovPoRVIcnoCf8Y7JxDQqH7kkbi3CNdJjibENrV1yMOGIflHaS34rFdcI6 TnHtORV+qV6HC0PilD9ix7uV/TfWyYCXC9Vh/sJXbaohhJsp0RnFTTvXkXrvIvd3VG 8R/WiuMfVtuOEcq0cqGHo6B3xUhBL/6aFwF8goho= Received: from DFLE114.ent.ti.com (dfle114.ent.ti.com [10.64.6.35]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x49LiG2J124075 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 9 May 2019 16:44:16 -0500 Received: from DFLE113.ent.ti.com (10.64.6.34) by DFLE114.ent.ti.com (10.64.6.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 9 May 2019 16:44:16 -0500 Received: from lelv0326.itg.ti.com (10.180.67.84) by DFLE113.ent.ti.com (10.64.6.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Thu, 9 May 2019 16:44:16 -0500 Received: from [10.250.146.137] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id x49LiBmv083926; Thu, 9 May 2019 16:44:12 -0500 Subject: Re: [PATCH v3 09/11] platform/x86: asus-wmi: Control RGB keyboard backlight To: Andy Shevchenko CC: Yurii Pavlovskyi , Pavel Machek , Jacek Anaszewski , Linux LED Subsystem , Corentin Chary , Darren Hart , Andy Shevchenko , Daniel Drake , acpi4asus-user , Platform Driver , Linux Kernel Mailing List , References: <7acd57fe-604a-a96a-4ca2-a25bc88d6405@gmail.com> <20190508171229.GA22024@amd> <52e73640-9fbf-437b-537a-7b3dc167052f@gmail.com> <2f26dd9e-ada7-8e20-c810-a647854c338c@ti.com> From: Dan Murphy Message-ID: <962ec05e-b4ca-89b7-405c-f8a76f19427c@ti.com> Date: Thu, 9 May 2019 16:44:20 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andy On 5/9/19 4:06 PM, Andy Shevchenko wrote: > On Thu, May 9, 2019 at 11:45 PM Dan Murphy wrote: >> On 5/9/19 2:04 PM, Yurii Pavlovskyi wrote: >> We are working on a framework for this. >> >> Please see this series >> https://lore.kernel.org/patchwork/project/lkml/list/?series=390141 >> >> It is still a work in progress > > Side question: > Have you considered to convert existing color LED controllers? (It > seems to me that your proposal lacks of the idea to keep back > compatibility with the existing controllers whre user may create a > sysfs node based on the arbitrary label, while it's good to have > multicolor infrastructure like in your proposal. Did I miss > something?) > > Yes that is part of the work that is in progress. The LED driver should be able to register either a single color LED or a group of colored LEDs. This can be based on a firmware entry and which LED framework the driver chooses to register to. Either the multicolor framework or the base LED framework. Of course we can put this in code and keep it out of the firmware nodes again thats why it is wip. I have convert a couple of drivers over in my testing that support RGB modules or have a RGB cluter used to mix colors. If the product wants to expose a single red LED via the label then they use legacy registration. If the product wants to expose RGBW as a single group then the multicolor framework should be registered too. Dan