From: Xuyang Dong <dongxuyang@eswincomputing.com>

Add the optional resets property.

Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
---
 .../devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml       | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
index 7523a89a1773..fd9f73c75121 100644
--- a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
+++ b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
@@ -43,6 +43,9 @@ properties:
       - const: bus
       - const: timer
 
+  resets:
+    maxItems: 1
+
   snps,pwm-number:
     $ref: /schemas/types.yaml#/definitions/uint32
     description: The number of PWM channels configured for this instance
-- 
2.34.1

On Fri, Mar 06, 2026 at 05:30:58PM +0800, dongxuyang@eswincomputing.com wrote:
> From: Xuyang Dong <dongxuyang@eswincomputing.com>
> 
> Add the optional resets property.

Why?

> 
> Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>

Best regards,
Krzysztof

> > 
> > Add the optional resets property.
> 
> Why?
> 

Hi Krzysztof,

The DesignWare PWM controller provides separate reset signals dedicated 
to each clock domain, as specified in the hardware documentation. 
Without asserting and deasserting these resets during probe, the PWM 
output may remain in an undefined state after system reboot.

Add optional reset control handling to ensure the controller is
properly initialized.

We will update the commit message in the next version.

Best regards,
Xuyang Dong

> > 
> > Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
> 
> Best regards,
> Krzysztof

Hello,

On Mon, Mar 09, 2026 at 05:23:45PM +0800, Xuyang Dong wrote:
> The DesignWare PWM controller provides separate reset signals dedicated 
> to each clock domain, as specified in the hardware documentation. 
> Without asserting and deasserting these resets during probe, the PWM 
> output may remain in an undefined state after system reboot.

Note there is an additional difficulty: A usual wish for machines with a
display is that the bootloader sets up a splash screen that is smoothly
taken over by Linux during boot. A reset of the PWM driving the
backlight then most probably results in a short dark display which
doesn't qualify for smooth.

So if you have a way to distinguish between "random state after
power-on" and "already programmed by the bootloader" this would be
great.

Best regards
Uwe