From: Marek Behun <marek.behun@nic.cz>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "Pavel Machek" <pavel@ucw.cz>, "Dan Murphy" <dmurphy@ti.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Jacek Anaszewski" <jacek.anaszewski@gmail.com>,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
"Florian Fainelli" <f.fainelli@gmail.com>,
"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH] dt-bindings: leds: leds-gpio: fix & extend node regex
Date: Fri, 12 Mar 2021 10:26:20 +0100 [thread overview]
Message-ID: <20210312102620.1307e7de@nic.cz> (raw)
In-Reply-To: <f9fc4dce-5b9c-5aff-e317-f2daabb73931@gmail.com>
On Fri, 12 Mar 2021 10:12:26 +0100
Rafał Miłecki <zajec5@gmail.com> wrote:
> On 12.03.2021 09:23, Marek Behun wrote:
> > On Fri, 12 Mar 2021 08:52:16 +0100
> > Rafał Miłecki <zajec5@gmail.com> wrote:
> >
> >> On 12.03.2021 08:44, Marek Behun wrote:
> >>> On Wed, 10 Mar 2021 08:00:25 +0100
> >>> Rafał Miłecki <zajec5@gmail.com> wrote:
> >>>
> >>>> From: Rafał Miłecki <rafal@milecki.pl>
> >>>>
> >>>> 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 <rafal@milecki.pl>
> >>>> ---
> >>>> 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_COLOR_ID_RED>;
> };
> led@7 {
> gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>;
> color = <LED_COLOR_ID_GREEN>;
> };
> };
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 = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_POWER;
};
next prev parent reply other threads:[~2021-03-12 9:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-10 7:00 [PATCH] dt-bindings: leds: leds-gpio: fix & extend node regex Rafał Miłecki
2021-03-12 7:44 ` Marek Behun
2021-03-12 7:52 ` Rafał Miłecki
2021-03-12 8:23 ` Marek Behun
2021-03-12 9:12 ` Rafał Miłecki
2021-03-12 9:26 ` Marek Behun [this message]
2021-03-12 9:42 ` Rafał Miłecki
2021-03-16 22:31 ` Rob Herring
2021-03-16 22:44 ` Rafał Miłecki
2021-03-23 22:02 ` Rob Herring
2021-03-23 22:07 ` Rafał Miłecki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210312102620.1307e7de@nic.cz \
--to=marek.behun@nic.cz \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=f.fainelli@gmail.com \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rafal@milecki.pl \
--cc=robh+dt@kernel.org \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.