linux-kernel - Re: [PATCH v7 3/5] pwm: kona: Fix incorrect config, disable, and polarity procedures

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]

Date:	Sun, 17 May 2015 21:53:30 -0700
From:	Tim Kryger <tim.kryger@...il.com>
To:	Jonathan Richardson <jonathar@...adcom.com>
Cc:	Dmitry Torokhov <dtor@...gle.com>,
	Anatol Pomazau <anatol@...gle.com>,
	Arun Ramamurthy <arun.ramamurthy@...adcom.com>,
	Thierry Reding <thierry.reding@...il.com>,
	Scott Branden <sbranden@...adcom.com>,
	bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux PWM <linux-pwm@...r.kernel.org>
Subject: Re: [PATCH v7 3/5] pwm: kona: Fix incorrect config, disable, and
 polarity procedures

On Tue, May 12, 2015 at 4:28 PM, Jonathan Richardson
<jonathar@...adcom.com> wrote:

> The polarity procedure no longer applies the settings to change the
> output signal because it can't be called when the pwm is enabled anyway.
> The polarity is only updated in the control register. The correct
> polarity will be applied on enable. The old method of applying changes
> would result in no signal when the polarity was changed. The new
> apply_settings function would fix this problem but it isn't required
> anyway.

Thanks for incorporating some of my suggestions in your latest version.

I'm still concerned about delaying when polarity changes take effect.

Since backlight is a common use of PWM, consider the following situation.

backlight {
        compatible = "pwm-backlight";
        pwms = <&pwm 0 5000000 PWM_POLARITY_NORMAL>;
        brightness-levels = <0 4 8 16 32 64 128 255>;
        default-brightness-level = <0>;
};

The Kona PWM hardware starts in inversed mode so it will drive output high
once its clock is enabled during the probe.

Polarity is not adjusted during probe so it stays high and it registers with
the PWM core using the new pwmchip_add_inversed() function.

Next, the pwm-backlight driver probe executes and it calls devm_pwm_get()
which then calls pwm_set_period() and most importantly pwm_set_polarity().

The output would change to constant low at this point in the original driver
but with your proposed change it will remain high.

The driver sets bl->props.brightness and calls backlight_update_status() but,
since in this case the default brightness is zero, it assumes it doesn't need
to enable the PWM.

The backlight driver probe then returns and the PWM output is incorrect.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/