Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
MIME-Version: 1.0
References: <20231002141020.2403652-1-jbrunet@baylibre.com>
 <20231002141020.2403652-3-jbrunet@baylibre.com> <2248b34e-d755-4142-986c-0ead80796e13@linaro.org>
 <1jleciyahv.fsf@starbuckisacylon.baylibre.com>
In-Reply-To: <1jleciyahv.fsf@starbuckisacylon.baylibre.com>
From:   Da Xue <da@lessconfused.com>
Date:   Wed, 4 Oct 2023 21:33:00 +0800
Message-ID: <CACdvmAhVODCikHMVpX91kBRxZi=7hgrR2Q-_71mFf9OVdptTWQ@mail.gmail.com>
Subject: Re: [PATCH 2/2] arm64: dts: amlogic: add libretech cottonwood support
To:     Jerome Brunet <jbrunet@baylibre.com>
Cc:     Neil Armstrong <neil.armstrong@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        Kevin Hilman <khilman@baylibre.com>,
        Da Xue <da.xue@libretech.co>, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-amlogic@lists.infradead.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Oct 4, 2023 at 5:59=E2=80=AFPM Jerome Brunet <jbrunet@baylibre.com>=
 wrote:
>
>
> On Wed 04 Oct 2023 at 11:20, Neil Armstrong <neil.armstrong@linaro.org> w=
rote:
>
> > On 02/10/2023 16:10, Jerome Brunet wrote:
> >> Add support for the Libretech cottonwood board family.
> >> These 2 boards are based on the same PCB, with an RPi B form factor.
> >> The "Alta" board uses an a311d while the "Solitude" variant uses an
> >> s905d3.
> >> Co-developed-by: Da Xue <da.xue@libretech.co>
> >> Signed-off-by: Da Xue <da.xue@libretech.co>
> >> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> >> ---
> >>   arch/arm64/boot/dts/amlogic/Makefile          |   2 +
> >>   .../amlogic/meson-g12b-a311d-libretech-cc.dts | 133 ++++
> >>   .../amlogic/meson-libretech-cottonwood.dtsi   | 610 ++++++++++++++++=
++
> >>   .../amlogic/meson-sm1-s905d3-libretech-cc.dts |  89 +++
> >>   4 files changed, 834 insertions(+)
> >>   create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-a311d-libr=
etech-cc.dts
> >>   create mode 100644 arch/arm64/boot/dts/amlogic/meson-libretech-cotto=
nwood.dtsi
> >>   create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-s905d3-libr=
etech-cc.dts
> >>
> >
> > <snip>
> >
> >> +
> >> +    leds-pwm {
> >> +            compatible =3D "pwm-leds";
> >> +
> >> +            led-green {
> >> +                    color =3D <LED_COLOR_ID_GREEN>;
> >> +                    function =3D LED_FUNCTION_STATUS;
> >> +                    linux,default-trigger =3D "default-on";
> >> +                    panic-indicator;
> >> +                    max-brightness =3D <255>;
> >> +                    pwms =3D <&pwm_cd 1 1250 0>;
> >> +                    active-low;
> >> +            };
> >> +
> >> +            led-blue {
> >> +                    color =3D <LED_COLOR_ID_BLUE>;
> >> +                    function =3D LED_FUNCTION_ACTIVITY;
> >> +                    linux,default-trigger =3D "activity";
> >
> > "activity" isn't documented, perhaps heartbeat instead ?
> >
>
> The trigger does exist though. The other way is to extend the DT doc.
> I don't really care one way or the other

We can and should use heartbeat to both be consistent and also show
Linux has started for developers.

>
> I'll defer to Da on this one
>
> >> +                    max-brightness =3D <255>;
> >> +                    pwms =3D <&pwm_ab 1 1250 0>;
> >> +                    active-low;
> >> +            };
> >
> > leds subnodes should be named as led(-[0-9a-f]+)
> >
> > see Documentation/devicetree/bindings/leds/leds-pwm.yaml
>
> That I do care. The schematics refer to the leds by name. There is no
> number assigned, much less hex. Making one up makes no sense.
>
> User should be able to quickly (and easily) link  what they see in the
> schematics with DT.
>
> So I'd prefer to submit a change for the regex rather than changing this

I don't get why the LEDs should be hex either. It's contradictory to
https://www.kernel.org/doc/html/latest/leds/leds-class.html

I did a simple grep and didn't find any references to
LED_COLOR_ID_ORANGE. We can debug this later.

>
> >
> >> +    };
> >> +
> >> +    leds-gpio {
> >> +            compatible =3D "gpio-leds";
> >> +
> >> +            led-orange {
> >> +                    color =3D <LED_COLOR_ID_AMBER>;
> >> +                    function =3D LED_FUNCTION_STANDBY;
> >> +                    gpios =3D <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
> >> +            };
> >
> > Ditto, but you can simply use "led" since it's the only one.
> >
> > See Documentation/devicetree/bindings/leds/leds-gpio.yaml
> >
> > Neil
> >
> >
> > <snip>
>
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic