linux-kernel - Re: [PATCH v2 2/2] backlight: add new lp8788 backlight driver

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]

Message-ID: <20130103090538.GB1845@avionic-0098.adnet.avionic-design.de>
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