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, HEADER_FROM_DIFFERENT_DOMAINS,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 3DED9C433DB for ; Sat, 19 Sep 2020 22:28:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F1C6720E65 for ; Sat, 19 Sep 2020 22:28:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726626AbgISW2u (ORCPT ); Sat, 19 Sep 2020 18:28:50 -0400 Received: from mail.nic.cz ([217.31.204.67]:56206 "EHLO mail.nic.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726617AbgISW2u (ORCPT ); Sat, 19 Sep 2020 18:28:50 -0400 Received: from localhost (unknown [IPv6:2a0e:b107:ae1:0:3e97:eff:fe61:c680]) by mail.nic.cz (Postfix) with ESMTPSA id CBEF0140A46; Sun, 20 Sep 2020 00:28:47 +0200 (CEST) Date: Sun, 20 Sep 2020 00:28:46 +0200 From: Marek Behun To: "Adrian Schmutzler" Cc: Subject: Re: [PATCH v2 1/2] dt-bindings: leds: add LED_FUNCTION for wlan2g/wlan5g Message-ID: <20200920002846.22a76e03@nic.cz> In-Reply-To: <00b201d68ecd$8af46280$a0dd2780$@adrianschmutzler.de> References: <20200919192427.57033-1-freifunk@adrianschmutzler.de> <20200919223134.2371459c@nic.cz> <00b201d68ecd$8af46280$a0dd2780$@adrianschmutzler.de> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.102.2 at mail X-Virus-Status: Clean Precedence: bulk List-ID: X-Mailing-List: linux-leds@vger.kernel.org On Sat, 19 Sep 2020 23:40:50 +0200 "Adrian Schmutzler" wrote: > > -----Original Message----- > > From: Marek Behun [mailto:marek.behun@nic.cz] > > Sent: Samstag, 19. September 2020 22:32 > > To: Adrian Schmutzler > > Cc: linux-leds@vger.kernel.org > > Subject: Re: [PATCH v2 1/2] dt-bindings: leds: add LED_FUNCTION for > > wlan2g/wlan5g > > > > On Sat, 19 Sep 2020 21:24:26 +0200 > > Adrian Schmutzler wrote: > > > > > Many consumer "routers" have dedicated LEDs for specific WiFi bands, > > > e.g. one for 2.4 GHz and one for 5 GHz. These LEDs specifically > > > indicate the state of the relevant band, so the latter should be > > > included in the function name. LED_FUNCTION_WLAN will remain for > > > general cases or when the LED is used for more than one band. > > > > > > This essentially is equivalent to how we use LED_FUNCTION_LAN and > > > LED_FUNCTION_WAN instead of just having LED_FUNCTION_ETHERNET. > > > > Dont. If you want the LED name to inform the user about the WiFi device it is > > being triggered on, it instead should come from the devicename part: > > "wlan0:blue:activity" > > > > In fact the function should not be "wlan" (nor "wlan2g" or "wlan5g", but > > "activity". > > > > I am going to try to work on this subsystem so that if trigger source of the LED > > is set to a WiFi device and function is set to activity, the LED shall blink on wifi > > activity. > > > > This way we can also avoid using the `linux,default-trigger` property in favour > > of `function`, i.e. if I have: > > > > wlan0: wifi@12300 { > > compatible = "some-wifi"; > > #trigger-source-cells = <0>; > > } > > > > led { > > color = ; > > function = LED_FUNCTION_ACTIVITY; > > trigger-sources = <&wlan0>; > > }; > > > > Than this will automatically name the LED as > > wlan0:blue:activity > > and if the corresponding trigger is available, it should set the trigger even if > > no `linux,default-trigger` property is present. > > Thanks for the explanation, I understand why this makes sense conceptually. > > However, I assume your use of the word "will" indicates that I won't be able to build a solution like this with kernel 5.4? > So, easiest surrogate there would be to just stick to label property for the moment ...? Yes. > How is the "device" part determined? Can I just change the DT label from wlan0 to wlan2g to get a more descriptive name, which will be translated into the led name like wlan2g:blue:activity? The label "wlan0" in the example above (wlan0: wifi@12300) is not stored is DT binary. It is just a name for phandle reference. The actual name of the DT node is "wifi@12300". Currently the devicename part is given by the LED driver. Some drivers do this, some do not. Those who do set it differently, for example they give name of the parent device of the LED (which is often name of the LED controller). This should be changed by the core so that if trigger-source is given, then the devicename part is taken from the trigger-source. But currently this is not implemented. > And finally, though partly off-topic: > Is there any way to determine the full "led name" from device-tree? We currently have aliases for certain leds, like > led-upgrade = &led_somename; > > The allowed us to construct the /sys/class/leds/