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=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=unavailable 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 B12D8C433DB for ; Fri, 12 Mar 2021 09:27:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8C22064FEA for ; Fri, 12 Mar 2021 09:27:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232844AbhCLJ0v convert rfc822-to-8bit (ORCPT ); Fri, 12 Mar 2021 04:26:51 -0500 Received: from lists.nic.cz ([217.31.204.67]:53382 "EHLO mail.nic.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232933AbhCLJ0X (ORCPT ); Fri, 12 Mar 2021 04:26:23 -0500 Received: from localhost (unknown [IPv6:2a0e:b107:ae1:0:3e97:eff:fe61:c680]) by mail.nic.cz (Postfix) with ESMTPSA id 5CBFE1408E5; Fri, 12 Mar 2021 10:26:21 +0100 (CET) Date: Fri, 12 Mar 2021 10:26:20 +0100 From: Marek Behun To: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= Cc: Pavel Machek , Dan Murphy , Rob Herring , Jacek Anaszewski , linux-leds@vger.kernel.org, devicetree@vger.kernel.org, Florian Fainelli , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= Subject: Re: [PATCH] dt-bindings: leds: leds-gpio: fix & extend node regex Message-ID: <20210312102620.1307e7de@nic.cz> In-Reply-To: References: <20210310070025.9150-1-zajec5@gmail.com> <20210312084414.7e4822bb@nic.cz> <62b556d5-0ebd-0923-69c6-a2fa3ede73b2@gmail.com> <20210312092336.5cbd10cb@nic.cz> X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT 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 Fri, 12 Mar 2021 10:12:26 +0100 Rafał Miłecki wrote: > On 12.03.2021 09:23, Marek Behun wrote: > > On Fri, 12 Mar 2021 08:52:16 +0100 > > Rafał Miłecki wrote: > > > >> On 12.03.2021 08:44, Marek Behun wrote: > >>> On Wed, 10 Mar 2021 08:00:25 +0100 > >>> Rafał Miłecki wrote: > >>> > >>>> From: Rafał Miłecki > >>>> > >>>> The old regex allowed only 1 character to follow the "led-" prefix which > >>>> was most likely just an overlook. Fix it and while at it allow dashes in > >>>> node names. It allows more meaningful names and it helpful e.g. when > >>>> having the same function name with 2 different colors. For example: > >>>> 1. led-power-white > >>>> 2. led-power-blue > >>>> > >>>> Signed-off-by: Rafał Miłecki > >>>> --- > >>>> Documentation/devicetree/bindings/leds/leds-gpio.yaml | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.yaml b/Documentation/devicetree/bindings/leds/leds-gpio.yaml > >>>> index 7ad2baeda0b0..ae46a43e480f 100644 > >>>> --- a/Documentation/devicetree/bindings/leds/leds-gpio.yaml > >>>> +++ b/Documentation/devicetree/bindings/leds/leds-gpio.yaml > >>>> @@ -21,7 +21,7 @@ properties: > >>>> patternProperties: > >>>> # The first form is preferred, but fall back to just 'led' anywhere in the > >>>> # node name to at least catch some child nodes. > >>>> - "(^led-[0-9a-f]$|led)": > >>>> + "(^led-[0-9a-f][0-9a-f-]*$|led)": > >>> > >>> Why not use +, like everywhere else? > >>> "(^led-[0-9a-f]+$|led)" > >> > >> 1. Your regex doesn't allow dashes. I described that in commit message. > > > > Ah, I confess I did not read the commit message. My fault. > > > >> 2. If I use one range and +, that will allow unwanted names like "led--power" > > > > But this can happen anyway. Your regex will match for example > > "led-deaf------beef". > > You're right. I probably was overthinking that ;) > > > > Moreover you give as an example names > > led-power-white > > led-power-blue > > but the regex only allows hexadecimal characters, ie > > led-dead-beef > > led-1f-3 > > > > The idea is that the string after "led-" is a hexadecimal address. > > Names like > > led-power-white > > shouldn't be used, as far as I understand. > > Oops! > 1. My regex was meant to be [0-9][a-z-][0-9][a-z-]+ > 2. I totally missed that nodename should contain hex num and not a name > > My patch is based on bad binding understanding. > > > So as I understand it now, the point of led hex number is to enumerate > nodes. That way we avoid: > ERROR (duplicate_node_names): /leds/led: Duplicate node name > > > I'm just wondering if there is some cleaner solution than using those > led-0, led-1, led-2, led-3, led-4 (...) names. > > Would that be acceptable to use address with GPIO number? Example: > > leds { > compatible = "gpio-leds"; > led@6 { > gpios = <&mpc8572 6 GPIO_ACTIVE_HIGH>; > color = ; > }; > led@7 { > gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>; > color = ; > }; > }; I don't know. This is a question for Rob Herring. But why is led-0, led-1, led-2 not good enough? You can still define function via the function property: led-7 { gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>; color = ; function = LED_FUNCTION_POWER; };