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  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]
Date:	Tue, 14 Oct 2014 15:54:47 +0200
From:	Thierry Reding <>
To:	Bart Tanghe <>
Subject: Re: [PATCH v7]pwm: add BCM2835 PWM driver

On Wed, Oct 08, 2014 at 12:14:32PM +0200, Bart Tanghe wrote:
> diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
> +static void bcm2835_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> +	struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
> +	u32 value;
> +
> +	value = readl(pc->base);
> +	value &= (~DEFAULT_PWM_MODE << (PWM_CONTROL_STRIDE * pwm->hwpwm));

While applying I noticed this oddity. Is this meant to be:

	value &= ~(DEFAULT_PWM_MODE << (PWM_CONTROL_STRIDE * pwm->hwpwm));

? That would match what's in bcm2835_pwm_request(). If so, what's the
difference between DEFAULT_PWM_MODE and PWM_CONTROL_MASK? Is the value
of a channel's field 0xff or 0x00 in the default mode?

The above indicates that it would be 0x00, in which case it might be
better to just do...

	value &= ~(PWM_CONTROL_MASK << (PWM_CONTROL_STRIDE * pwm->hwpwm));

... and get rid of DEFAULT_PWM_MODE.

No need to respin, I can fix this up when applying. Just let me know if
that's actually the right thing to do.


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists