| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20220705121541.t7jjcjp4hkqprsdo@pali>
Date: Tue, 5 Jul 2022 14:15:41 +0200
From: Pali Rohár <pali@...nel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Pavel Machek <pavel@....cz>, Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Marek Behún <kabel@...nel.org>,
linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: leds: Add cznic,turris1x-leds.yaml
binding
On Tuesday 05 July 2022 13:51:12 Krzysztof Kozlowski wrote:
> On 05/07/2022 13:42, Pali Rohár wrote:
> > On Tuesday 05 July 2022 13:36:54 Krzysztof Kozlowski wrote:
> >> On 05/07/2022 02:04, Pali Rohár wrote:
> >>> Add device-tree bindings documentation for Turris 1.x RGB LEDs.
> >>>
> >>> Signed-off-by: Pali Rohár <pali@...nel.org>
> >>> ---
> >>> .../bindings/leds/cznic,turris1x-leds.yaml | 116 ++++++++++++++++++
> >>> 1 file changed, 116 insertions(+)
> >>> create mode 100644 Documentation/devicetree/bindings/leds/cznic,turris1x-leds.yaml
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/leds/cznic,turris1x-leds.yaml b/Documentation/devicetree/bindings/leds/cznic,turris1x-leds.yaml
> >>> new file mode 100644
> >>> index 000000000000..fd09613c8d2d
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/leds/cznic,turris1x-leds.yaml
> >>> @@ -0,0 +1,116 @@
> >>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> >>> +%YAML 1.2
> >>> +---
> >>> +$id: http://devicetree.org/schemas/leds/cznic,turris1x-leds.yaml#
> >>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>> +
> >>> +title: CZ.NIC's Turris 1.x LEDs driver
> >>> +
> >>> +maintainers:
> >>> + - Pali Rohár <pali@...nel.org>
> >>> +
> >>> +description:
> >>> + This module adds support for the RGB LEDs found on the front panel of the
> >>> + Turris 1.x routers. There are 8 RGB LEDs that are controlled by CZ.NIC CPLD
> >>> + firmware running on Lattice FPGA. Firmware is open source and available at
> >>> + https://gitlab.nic.cz/turris/hw/turris_cpld/-/blob/master/CZ_NIC_Router_CPLD.v
> >>> +
> >>> +properties:
> >>> + compatible:
> >>> + const: cznic,turris1x-leds
> >>> +
> >>> + reg:
> >>> + maxItems: 2
> >>
> >> You need to describe the items, if it is really two items. However your
> >> example has only one item, so this was not tested and won't work.
> >
> > Ehm? Example has two items in the reg.
>
> No, you have exactly one item.
> <0x13 0x1d>
>
> Two items are for example:
> <0x13 0x1d>, <0x23 0x1d>
Ok. So I should change maxItems to 1 in this case?
And how you want to describe those items?
> >
> >> You'll get warning from Rob's robot soon... but you should test the
> >> bindings instead.
> >
> > I have tested bindings on the real hardware and it is working fine
> > together with the driver from patch 2/2.
>
> Bindings cannot be tested on real hardware. Bindings are tested with
> dt_binding_check, as explained in writing-schema.rst
Ou... this is something which I was not able to run, it just does not
work, throws lot of python dependency hell errors and it spend more than
hour with it. So sorry, I really cannot run it. Maybe it would be a wise
to provide web service for these checks for those who cannot run them
locally?
> >
> >>> +
> >>> + "#address-cells":
> >>> + const: 1
> >>> +
> >>> + "#size-cells":
> >>> + const: 0
> >>> +
> >>> +patternProperties:
> >>> + "^multi-led@[0-7]$":
> >>> + type: object
> >>> + $ref: leds-class-multicolor.yaml#
> >>
> >> This looks incorrect, unless you rebased on my patchset?
> >
> > So what is the correct? (I used inspiration from
> > cznic,turris-omnia-leds.yaml file)
>
> Which according to current multicolor bindings is not correct. Correct
> is pwm-multicolor. However if you rebase on [1], it looks fine, except
> missing unevaluatedProperties.
Ok. So does it mean that I should just add
"unevaluatedProperties: false"?
> [1]
> https://lore.kernel.org/all/20220624112106.111351-1-krzysztof.kozlowski@linaro.org/
>
> >
> >>> +
> >>> + properties:
> >>> + reg:
> >>> + minimum: 0
> >>> + maximum: 7
> >>> +
> >>> + required:
> >>> + - reg
> >>> +
> >>> +additionalProperties: false
> >>> +
> >>> +examples:
> >>> + - |
> >>> +
> >>
> >> No blank line.
> >
> > Ok.
> >
> >>> + #include <dt-bindings/leds/common.h>
> >>> +
> >>> + cpld@3,0 {
> >>
> >> Generic node name.
> >
> > Is not cpld name generic enough?
>
> No, it means nothing to me. Just like "a", "ashjd" or "wrls".
If you never heard about it, I would suggest to read something about
Programmable logic devices. It is interesting category of hardware with
which you can play. CPLD and FPGA are very often used in lot of products
and FPGA is very easy for playing and programming custom logic.
For example on wikipedia is list of different technologies of
programmable logic devices:
https://en.wikipedia.org/wiki/Programmable_logic_device
So if you want more generic name, just name it "pld"? But as it is CPLD
device I would suggest to name it really as "cpld". It does not matter
from which manufactor you have CPLD, just like it does not matter from
which manufactor you have NAND.
>From bus point of view, cpld is like nand or nor nodes in DTS. All of
them refers to specific memory map of chip selects on the local bus.
> "The name of a node should be somewhat generic, reflecting the function
> of the device and not its precise programming
> model. If appropriate, the name should be one of the following choices:"
Hm... You forgot to send what are those "choices:"?
> Best regards,
> Krzysztof
Powered by blists - more mailing lists