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] [day] [month] [year] [list]
Message-ID: <eobcrbxmtyxv4x5dkgxf2sssgjefqbhit3tsnzizdel2aqzynq@opsqlav5zh32>
Date: Thu, 28 Nov 2024 10:59:25 +0100
From: Uwe Kleine-König <ukleinek@...nel.org>
To: "Rafael V. Volkmer" <rafael.v.volkmer@...il.com>
Cc: linux-kernel@...r.kernel.org, linux-pwm@...r.kernel.org
Subject: Re: [PATCH v2] pwm: improve state handling in ehrpwm driver

Hello,

Subject should use "pwm: tiehrpwm:" as prefix, then drop "in ehrpwm
driver".

On Wed, Nov 27, 2024 at 07:26:49PM -0300, Rafael V. Volkmer wrote:
> Introduce ehrpwm_is_enabled() to verify the module's enable/disable state
> by checking the AQCSFRC and AQCTLA registers, instead of relying solely
> on pwm->state.enabled. This ensures a more accurate representation of
> the ePWM state in the kernel.
> 
> Previously, when performing fops operations directly in kernel space
> after retrieving the platform device (pdev)—bypassing the sysfs interface—
> pwm->state.enabled could incorrectly signal transitions between active
> and inactive states, leading to inconsistent behavior.

I don't see a problem in this driver but I wonder what you do trigger
the problem you're describing. Are you saying some other driver calls
ehrpwm_pwm_apply() directly bypassing the pwm core? If so: Don't.

Otherwise I'd claim the only place where state.enabled can get out of
sync is during .probe(). The driver might need something like:

	if (hw_is_enabled) {
		clk_enable(...)
		pm_runtime_get(...)
	}

there and an implementation of .get_state(). BTW, .free() looks wrong; a
driver isn't supposed to make up for a consumer failing to disable the
hardware before it releases the pwm handle (but that's orthogonal to
your problem I think).

Am I missing something?

> [...]
>  static void ehrpwm_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
>  {
>  	struct ehrpwm_pwm_chip *pc = to_ehrpwm_pwm_chip(chip);
> @@ -404,7 +423,9 @@ static int ehrpwm_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>  			    const struct pwm_state *state)
>  {
>  	int err;
> -	bool enabled = pwm->state.enabled;
> +	bool enabled;
> +
> +	enabled = (ehrpwm_is_enabled(chip) | pwm->state.enabled);

|| is the right operator for bools. No parenthesis are needed.

ehrpwm_is_enabled() should never return something different than
pwm->state.enabled. This is the thing you need to address. Don't paper
over this.

Best regards
Uwe

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ