linux-kernel - Re: [PATCH v6 2/2] pwm: add support for NXPs high-side switch MC33XS2410

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dy5abepkqhkmbgirwjkblbmw6vwb56vaqgazluyt675qflzioz@glp4djy6fhuo>
Date: Mon, 4 Nov 2024 09:52:51 +0100
From: Uwe Kleine-König <u.kleine-koenig@...libre.com>
To: Dimitri Fedrau <dima.fedrau@...il.com>
Cc: Rob Herring <robh+dt@...nel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, linux-pwm@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 2/2] pwm: add support for NXPs high-side switch
 MC33XS2410

On Sun, Nov 03, 2024 at 09:52:15PM +0100, Dimitri Fedrau wrote:
> Hello Uwe,
> 
> Am Sun, Nov 03, 2024 at 09:19:36PM +0100 schrieb Uwe Kleine-König:
> > Hello Dimitri,
> > 
> > On Sun, Nov 03, 2024 at 08:07:09PM +0100, Dimitri Fedrau wrote:
> > > Am Thu, Oct 24, 2024 at 11:19:16PM +0200 schrieb Uwe Kleine-König:
> > > > What breaks if you drop the check for state->enabled?
> > > >  
> > > The device is unable to generate a 0% duty cycle, to support this you
> > > proposed in an earlier review to disable the output. Without checking if
> > > the output is disabled, the mc33xs2410_pwm_get_state function returns the
> > > wrong duty cycle for a previously setted 0% duty cycle. A "0" value in the
> > > MC33XS2410_PWM_DC register means that the relative duty cylce is 1/256. As
> > > a result there are complaints if PWM_DEBUG is enabled.
> > 
> > I fail to follow. If .enabled=true + .duty_cycle=0 is requested you
> > disable. That's fine. However it shouldn't be necessary to use
> > state->enabled in .get_state(). I didn't look at the actual code, but if
> > you provide a sequence of writes to /sys that trigger a PWM_DEBUG
> > output, I'll take another look.
> > 
> Apply 0% duty cycle: .enabled=false + .duty_cycle=0
> Below some writes triggering PWM_DEBUG output:
> 
> # echo 488282 > /sys/class/pwm/pwmchip3/pwm0/period
> # echo 244140 > /sys/class/pwm/pwmchip3/pwm0/duty_cycle
> # echo 0 > /sys/class/pwm/pwmchip3/pwm0/duty_cycle
> [   91.813513] mc33xs2410-pwm spi0.0: .apply is supposed to round down duty_cycle (requested: 0/488282, applied: 1908/488282)

I don't understand that. We're talking about 

diff --git a/drivers/pwm/pwm-mc33xs2410.c b/drivers/pwm/pwm-mc33xs2410.c
index f9a334a5e69b..14f5f7312d0a 100644
--- a/drivers/pwm/pwm-mc33xs2410.c
+++ b/drivers/pwm/pwm-mc33xs2410.c
@@ -244,15 +244,6 @@ static int mc33xs2410_pwm_get_relative_duty_cycle(u64 period, u64 duty_cycle)
 	return duty_cycle - 1;
 }
 
-static void mc33xs2410_pwm_set_relative_duty_cycle(struct pwm_state *state,
-						   u16 duty_cycle)
-{
-	if (!state->enabled)
-		state->duty_cycle = 0;
-	else
-		state->duty_cycle = DIV_ROUND_UP_ULL((duty_cycle + 1) * state->period, 256);
-}
-
 static int mc33xs2410_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
 				const struct pwm_state *state)
 {
@@ -325,7 +316,7 @@ static int mc33xs2410_pwm_get_state(struct pwm_chip *chip,
 	state->polarity = (val[2] & MC33XS2410_PWM_CTRL1_POL_INV(pwm->hwpwm)) ?
 			  PWM_POLARITY_INVERSED : PWM_POLARITY_NORMAL;
 	state->enabled = !!(val[3] & MC33XS2410_PWM_CTRL3_EN(pwm->hwpwm));
-	mc33xs2410_pwm_set_relative_duty_cycle(state, val[1]);
+	state->duty_cycle = DIV_ROUND_UP_ULL((duty_cycle + 1) * state->period, 256);
 	return 0;
 }
 
on top of your patch, right?

`echo 0 > /sys/class/pwm/pwmchip3/pwm0/duty_cycle` should result in
MC33XS2410_PWM_CTRL3 having MC33XS2410_PWM_CTRL3_EN(pwm->hwpwm) cleared.
When mc33xs2410_pwm_get_state() is called then it returns state->enabled
= false and in that case the above mentioned warning doesn't trigger.

Where is the misunderstanding?

Best regards
Uwe

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)