On Fri, Nov 30, 2018 at 08:13:04AM -0600, Rob Herring wrote: > > > It's quite unusual for a backlight device to have a trivial binding. > > > > > > The driver supports fairly extensive parametrization via struct > > > lm3530a_platform_data. It is really the case that none of these > > > properties should ever be set via DT? > > > > Hi Daniel, > > > > I initially assumed that we would let user space configure these values > > once the system has booted, but you are right that these should be > > available in device tree. > > > > The driver has two different LED banks that can be configured > > independently. > > That is usually represented with child nodes which makes this anything > but trivial. Plus, given that we have bindings for LEDs/backlights, no > LED/backlight controller is a trivial device. Hi Rob, I agree and I'm not going to use a trivial binding for v2. See below for some questions that I have from my last email. > > How do you feel about having a single property in > > device tree populate the initial values for both banks? I propose that > > we could use the property default-brightness-level for leda_init_brt > > and ledb_init_brt in struct lm3630a_platform_data. The max-brightness > > property can populate leda_max_brt and ledb_max_brt. > > > > I need to look at other bindings this weekend to see if there are any > > standard properties that I can use for leda_ctrl/ledb_ctrl, pwm_ctrl, > > and pwm_period. > > > > Brian > >
