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:	Thu, 3 Jan 2013 10:05:39 +0100
From:	Thierry Reding <thierry.reding@...onic-design.de>
To:	"Kim, Milo" <Milo.Kim@...com>
Cc:	Richard Purdie <rpurdie@...ys.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Samuel Ortiz <sameo@...ux.intel.com>
Subject: Re: [PATCH v2 2/2] backlight: add new lp8788 backlight driver

On Thu, Jan 03, 2013 at 08:54:27AM +0000, Kim, Milo wrote:
> Hi Thierry,
> 
> > > (Platform data)
> > > Configurable data can be defined in the platform side.
> > >  name                  : backlight driver name. (default: "lcd-
> > backlight")
> > >  initial_brightness    : initial value of backlight brightness
> > >  bl_mode               : brightness control by PWM or lp8788 register
> > >  dim_mode              : dimming mode selection
> > >  full_scale            : full scale current setting
> > >  rise_time             : brightness ramp up step time
> > >  fall_time             : brightness ramp down step time
> > >  pwm_pol               : PWM polarity setting when bl_mode is PWM
> > based
> > 
> > You might want to consider using enum pwm_polarity from linux/pwm.h
> > instead and convert to the driver representation internally.
> > 
> > I'm saying this because I'm thinking about extending the PWM framework
> > to allow PWM polarity and period to be specified in the PWM lookup
> > table
> > so that they can be treated transparently, independent of whether they
> > are obtained from DT or the lookup table.
> > 
> > That would allow the polarity and period to be retrieved with accessors
> > like pwm_get_polarity() and pwm_get_period().
> 
> OK, pwm_pol will be replaced with pwm_get_polarity() in the next patch.

No, you can't do that yet because it will only work if you get the PWM
from DT. I meant that once the pieces in the PWM framework are there we
could encode the polarity in the PWM lookup table and *then* use
pwm_get_polarity() to obtain it instead of via platform data.

For now, I think you should only convert it to enum pwm_polarity so that
at least the data type is the same as the one used in the PWM framework.

Thierry

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists