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: <20140409071614.GA9886@ulmo>
Date:	Wed, 9 Apr 2014 09:16:16 +0200
From:	Thierry Reding <thierry.reding@...il.com>
To:	Lothar Waßmann <LW@...O-electronics.de>
Cc:	Tim Kryger <tim.kryger@...aro.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux PWM List <linux-pwm@...r.kernel.org>,
	Shawn Guo <shawn.guo@...aro.org>,
	Sascha Hauer <kernel@...gutronix.de>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCHv3 1/3] pwm: make the PWM_POLARITY flag in DTB optional

On Wed, Apr 09, 2014 at 08:04:50AM +0200, Lothar Waßmann wrote:
> Hi,
> 
> Tim Kryger wrote:
> > On Mon, Apr 7, 2014 at 10:02 PM, Lothar Waßmann <LW@...o-electronics.de>wrote:
> > >
> > >
> > > Thierry Reding wrote:
> > >
> > > > No. You cannot emulate polarity inversion in software.
> > > >
> > > Why not?
> > >
> > > duty_ns = period_ns - duty_ns;
> > >
> > 
> > Since I made the same mistake, I will pass along the pointer Thierry gave
> > me.
> > 
> > In include/linux/pwm.h the second difference for an inverted signal is
> > described.
> > 
> > /**
> >  * enum pwm_polarity - polarity of a PWM signal
> >  * @PWM_POLARITY_NORMAL: a high signal for the duration of the duty-
> >  * cycle, followed by a low signal for the remainder of the pulse
> >  * period
> >  * @PWM_POLARITY_INVERSED: a low signal for the duration of the duty-
> >  * cycle, followed by a high signal for the remainder of the pulse
> >  * period
> >  */
> > enum pwm_polarity {
> > PWM_POLARITY_NORMAL,
> > PWM_POLARITY_INVERSED,
> > };
> > 
> > Of course, I suspect not all PWM hardware respects this definition of
> > inverted output.
> > 
> > Either way, hacking the duty in software certainly would get the high/low
> > order wrong.
> > 
> OK. But for a periodic signal this doesn't make any difference. It's
> just a matter of where you set your reference point.
> Only if you program the PWM to create a single cycle you would see the
> difference. I wonder if this is a real life usecase though.

It doesn't make a difference if all you're concerned about is the signal
power (which happens to be the case for LED and backlight use-cases).

Currently any in-kernel users only care about the signal power, but
there's no guarantee that it will stay that way. Furthermore, PWM
channels are exposed to userspace via sysfs, so code that we don't
actually see may rely on this behaviour.

Thierry

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ