[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <crcfskukqifse6gqrydx2iezargv5frv6dguj3iqdkfm7xxbqh@4v2dvo4zcmbz>
Date: Wed, 28 May 2025 12:21:45 +0200
From: Uwe Kleine-König <ukleinek@...nel.org>
To: Nylon Chen <nylon.chen@...ive.com>, Conor Dooley <conor@...nel.org>,
Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>
Cc: devicetree@...r.kernel.org, linux-pwm@...r.kernel.org,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org, robh@...nel.org,
krzk+dt@...nel.org, paul.walmsley@...ive.com, samuel.holland@...ive.com
Subject: Re: [PATCH v14 0/5] Change PWM-controlled LED pin active mode and
algorithm
Hello,
patches 1 and 2 ideally go in together, right? @Conor, does your Ack
mean that you're OK with me taking the dts change via my pwm tree?
On Fri, May 09, 2025 at 05:52:29PM +0800, Nylon Chen wrote:
> Nylon Chen (5):
> riscv: dts: sifive: unleashed/unmatched: Remove PWM controlled LED's
> active-low properties
> pwm: sifive: change the PWM algorithm
> pwm: sifive: Fix the error in the idempotent test within the
> pwm_apply_state_debug function
> pwm: sifive: Fix rounding issues in apply and get_state functions
> pwm: sifive: clarify inverted compare logic in comments
The objective of patches #3 and #4 is the same, right? Both prevent that
.apply ∘ .get_state is idempotent, right?
And I'd also squash patches #2 and #5 to have the comments updated
together with the respective code changes.
I think the algorithm implemented in this driver is more complicated
than it should be, but this is not this series's fault, so I tend to
apply it with the above mentioned squashes.
Best regards
Uwe
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists