[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lvi75asit3ati7wwnyae6rowycr3veodswu7blbnzbrq646fgi@iksn4qas3dwt>
Date: Tue, 4 Mar 2025 07:29:46 +0100
From: Uwe Kleine-König <ukleinek@...nel.org>
To: Abel Vesa <abel.vesa@...aro.org>
Cc: Lee Jones <lee@...nel.org>, Pavel Machek <pavel@...nel.org>,
Anjelique Melendez <anjelique.melendez@....qualcomm.com>, Kamal Wadhwa <quic_kamalw@...cinc.com>,
Jishnu Prakash <jishnu.prakash@....qualcomm.com>, Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, Johan Hovold <johan@...nel.org>,
Sebastian Reichel <sre@...nel.org>, Pavel Machek <pavel@....cz>, linux-leds@...r.kernel.org,
linux-pwm@...r.kernel.org, linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org
Subject: Re: [PATCH v3 0/3] leds: rgb: leds-qcom-lpg: PWM fixes
Hello,
On Mon, Mar 03, 2025 at 01:52:49PM +0200, Abel Vesa wrote:
> The PWM allow configuring the PWM resolution from 8 bits PWM
> values up to 15 bits values, for the Hi-Res PWMs, and then either
> 6-bit or 9-bit for the normal PWMs. The current implementation loops
> through all possible resolutions (PWM sizes), for the PWM subtype, on top
> of the already existing process of determining the prediv, exponent and
> refclk.
>
> The first and second issues are related to capping the computed PWM
> value.
I just took a very quick look. I'd say squash the first and second patch
into a single one. Splitting a change that fixes the same issue in the
two branches of an if condition has no benefit.
Other than that this patch set would also benefit from what I wrote in
the review of the other patch you send: Please mention a request where
the result becomes wrong. This considerably simplifies understanding
your changes.
Thanks
Uwe
Download attachment "signature.asc" of type "application/pgp-signature" (485 bytes)
Powered by blists - more mailing lists