On Wed, Aug 12, 2020 at 10:58:48AM +0200, Linus Walleij wrote: > Let's use a common.yaml include for the backlight like we do with > the LEDs. The LEDs are inherently incompatible so their bindings > cannot be reused for backlight. > > Cc: devicetree@xxxxxxxxxxxxxxx > Suggested-by: Sam Ravnborg <sam@xxxxxxxxxxxx> > Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > --- > ChangeLog v1->v2: > - New patch as suggested by Sam. > --- > .../bindings/leds/backlight/common.yaml | 42 +++++++++++++++++++ > 1 file changed, 42 insertions(+) > create mode 100644 Documentation/devicetree/bindings/leds/backlight/common.yaml > > diff --git a/Documentation/devicetree/bindings/leds/backlight/common.yaml b/Documentation/devicetree/bindings/leds/backlight/common.yaml > new file mode 100644 > index 000000000000..8ae7e3818b0d > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/backlight/common.yaml > @@ -0,0 +1,42 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/leds/backlight/common.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Common backlight properties > + > +maintainers: > + - Lee Jones <lee.jones@xxxxxxxxxx> > + - Daniel Thompson <daniel.thompson@xxxxxxxxxx> > + - Jingoo Han <jingoohan1@xxxxxxxxx> > + > +description: | > + Backlight devices provide backlight for different types of graphical > + displays. They are typically but not necessarilt implemented using a white > + LED powered by a boost converter. > + > +properties: > + default-on: > + description: > + The initial state of the backlight can be set to be on with this > + property. This is a state applied by the operating system so that the > + backlight is always turned on at boot. Is default-on really a common property? I would describe it as legacy that emerged when we added the gpio bindings and didn't spell default-brightness correctly! Currently I think this is only implemented for GPIO and it is simply not needed for most hardware. More specifically, for hardware that is capable of flicker-free handover (bootloader -> kernel) by examining the hardware state at handover then we don't want a DT property. It is duplicative and can only result in bad handovers. Daniel.
