Brian Norris <briannorris@xxxxxxxxxxxx> writes: Hello Brian, > On Thu, Mar 30, 2023 at 3:03 PM Javier Martinez Canillas > <javierm@xxxxxxxxxx> wrote: >> >> There is no neither a driver that parses this nor a DT binding schema that Ups, I noticed now that there's an unnecessary "no" and it should be instead: "There is neither a driver..." >> documents it so let's remove it from the DTS files that make use of this. >> >> The properties that exist are post-pwm-on-delay-ms and pwm-off-delay-ms, >> defined in the pwm-backlight DT binding. So probably what these DTS want >> is something like following: >> >> backlight: backlight { >> compatible = "pwm-backlight"; >> enable-gpios = <&gpio4 21 GPIO_ACTIVE_HIGH>; >> pinctrl-names = "default"; >> pinctrl-0 = <&bl_en>; >> pwms = <&pwm1 0 1000000 0>; >> post-pwm-on-delay-ms = <10>; >> pwm-off-delay-ms = <10>; >> }; >> >> But that should be follow-up change if that is the case. Because otherwise >> it would be change in behaviour, since currently pwm-delay-us is a no-op. >> >> Signed-off-by: Javier Martinez Canillas <javierm@xxxxxxxxxx> > > pwm-delay-us seems to have been a downstream-only ("CHROMIUM", if > you're familiar with ChromiumOS kernel parlance) change that seems > like a combination of the two now-upstream properties you point at. I Yes, that's what I found too. So it seems that this was an oversight when the DTS for these Chromebooks were upstreamed. > looked through the first use of pwm-delay-us on RK3399 Gru systems, > and I can't find a spec reference that said it was needed; perhaps it > was needless copy/paste imitation? > > So, simple deletion is probably fine: > > Reviewed-by: Brian Norris <briannorris@xxxxxxxxxxxx> > Thanks for the confirmation and review! -- Best regards, Javier Martinez Canillas Core Platforms Red Hat