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: <20241104130753.GA14681@debian>
Date: Mon, 4 Nov 2024 14:07:53 +0100
From: Dimitri Fedrau <dima.fedrau@...il.com>
To: Uwe Kleine-König <u.kleine-koenig@...libre.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

Am Mon, Nov 04, 2024 at 09:52:51AM +0100 schrieb Uwe Kleine-König:
> 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?
>
Yes.

> `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.
>
Yes, as you explained. But the warning is shown.

> Where is the misunderstanding?
>

if (state->enabled && state->duty_cycle < s2.duty_cycle)
	dev_warn(pwmchip_parent(chip),
		".apply is supposed to round down duty_cycle (requested: %llu/%llu, applied: %llu/%llu)\n",
		state->duty_cycle, state->period,
		s2.duty_cycle, s2.period);

state has previously applied settings and is parameter of pwm_apply_debug,
in that case s2=s1, and s1 is returned by get_state:

state->enabled=true
state->duty_cycle=0
s2.enabled=false
s2.duty_cycle=1908

Due to the code the warning should be raised. If it shouldn't the check
should be different, something like if (state->enabled && s2.enabled &&
...)

Best regards,
Dimitri

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ