On Tue, Oct 8, 2019 at 7:51 AM Jean-Jacques Hiblot <jjhiblot@xxxxxx> wrote: > > Hi Rob, > > On 07/10/2019 18:15, Rob Herring wrote: > > Please send DT bindings to DT list or it's never in my queue. IOW, > > send patches to the lists that get_maintainers.pl tells you to. > > > > On Mon, Oct 7, 2019 at 7:45 AM Jean-Jacques Hiblot <jjhiblot@xxxxxx> wrote: > >> Add DT binding for led-backlight. > >> > >> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@xxxxxx> > >> Reviewed-by: Daniel Thompson <daniel.thompson@xxxxxxxxxx> > >> Reviewed-by: Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxx> > >> --- > >> .../bindings/leds/backlight/led-backlight.txt | 28 +++++++++++++++++++ > >> 1 file changed, 28 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/leds/backlight/led-backlight.txt > > Please make this a DT schema. > > OK. > > BTW I used "make dt_binding_check" but had to fix a couple of YAMLs file > to get it to work. Do you have a kernel tree with already all the YAML > files in good shape ? Or do you want me to post the changes to > devicetree@xxxxxxxxxxxxxxx ? linux-next is fixed now. > >> diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt > >> new file mode 100644 > >> index 000000000000..4c7dfbe7f67a > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt > >> @@ -0,0 +1,28 @@ > >> +led-backlight bindings > >> + > >> +This binding is used to describe a basic backlight device made of LEDs. > >> +It can also be used to describe a backlight device controlled by the output of > >> +a LED driver. > >> + > >> +Required properties: > >> + - compatible: "led-backlight" > >> + - leds: a list of LEDs > > 'leds' is already used as a node name and mixing is not ideal. > > > > We already have 'flash-leds' in use and with the same definition, so > > lets continue that and use 'backlight-leds'. > OK > > > >> + > >> +Optional properties: > >> + - brightness-levels: Array of distinct brightness levels. The levels must be > >> + in the range accepted by the underlying LED devices. > >> + This is used to translate a backlight brightness level > >> + into a LED brightness level. If it is not provided, the > >> + identity mapping is used. > >> + > >> + - default-brightness-level: The default brightness level. > > You can just assume these 2 get a common schema at some point. So just > > need to define any additional constraints if possible. > > Maybe we should keep them until such a common schema is written ? I'm not saying to remove them, but you can just have a description if there are no other constraints. Rob